可重入锁\不可重入锁+乐观锁\悲观锁+公平锁\非公平锁+可中断锁

爱被打了一巴掌 2024-03-31 16:37 85阅读 0赞

**可重入锁与不可重入锁**

可[重入锁][Link 1]，指的是以**线程**为单位，当一个线程获取对象锁之后，这个线程可以再次获取本对象上的锁，而其他的线程是不可以的。  
synchronized 和 ReentrantLock 都是可重入锁。

不可重入锁，与可重入锁相反，不可递归调用，递归调用就发生死锁。

**释义**

**可重入锁**

广义上的可重入锁指的是可重复可[递归调用][Link 2]的锁，在外层使用锁之后，在内层仍然可以使用，并且不发生死锁（前提得是同一个对象或者class），这样的锁就叫做可重入锁。ReentrantLock和synchronized都是可重入锁，下面是一个用synchronized实现的例子：

public class ReentrantTest implements Runnable \{

public synchronized void get() \{

System.out.println(Thread.currentThread().getName());

set();

public synchronized void set() \{

System.out.println(Thread.currentThread().getName());

public void run() \{

get();

public static void main(String\[\] args) \{

ReentrantTest rt = new ReentrantTest();

for(;;)\{

new Thread(rt).start();

又一个例子：

当一个线程执行到某个synchronized方法时，比如说method1，而在method1中会调用另外一个synchronized方法method2，此时线程不必重新去申请锁，而是可以直接执行方法method2。

class MyClass \{  
public synchronized void method1() \{  
method2();  
\}

public synchronized void method2() \{

\}  
\}

**不可重入锁**

不可重入锁，与可重入锁相反，不可递归调用，递归调用就发生死锁。看到一个经典的讲解，使用自旋锁来模拟一个不可重入锁，代码如下：

import java.util.concurrent.atomic.AtomicReference;

public class UnreentrantLock \{

//原子引用

private AtomicReference<Thread> owner = new AtomicReference<Thread>();

public void lock() \{

Thread current = Thread.currentThread();

//这句是很经典的“自旋”语法，AtomicInteger中也有

for (;;) \{

if (!owner.compareAndSet(null, current)) \{

return;

public void unlock() \{

Thread current = Thread.currentThread();

owner.compareAndSet(current, null);

上述代码中的两个方法method1和method2都用synchronized修饰了。假如某一时刻，线程A执行到了method1，此时线程A获取了这个对象的锁，而由于method2也是synchronized方法，假如synchronized不具备可重入性，此时线程A需要重新申请锁。但是，这就会造成死锁，因为线程A已经持有了该对象的锁，而又在申请获取该对象的锁，这样就会线程A一直等待永远不会获取到的锁。而由于synchronized和Lock都具备可重入性，所以不会发生上述现象。

**乐观锁与悲观锁**

1.（阻塞同步）悲观锁，顾名思义，是悲观的，觉得不锁住的资源会被别人的线程抢走，所以悲观锁每次获取和修改数据都会锁定数据。

典型的悲观锁案例：synchronized关键词和Lock接口。

2.（非阻塞同步）乐观锁，认为自己在操作资源时不会有其他线程干扰，所以不会锁定对象，只是在更新资源时会去对比一下我修改过的数据之间是否有其他线程修改过的数据。若无修改，此次修改正常，若有其他线程修改，则放弃此次修改，并选择报错或重试。这是一个基于冲突检测的并发策略，这种并发策略的实现不需要线程挂起，因此是非阻塞同步。乐观锁一般采用CAS算法实现。

典型的乐观锁案例：Java并发包Atomic原子类，数据库version版本机制

3. 悲观锁与乐观锁在性能方面的比较

悲观锁会堵塞锁的线程，这种费用是固定的。悲观锁的原始费用高于乐观锁。

乐观锁的初始费用比悲观锁小，但如果一直拿不到锁或者并发量大，竞争激烈，会导致不断的重试，所以会消耗越来越多的资源，甚至超过悲观锁。

**公平锁与非公平锁**

公平锁即 尽量 以请求锁的顺序来获取锁。比如，同是有多个线程在等待一个锁，当这个锁被释放时，等待时间最久的线程（最先请求的线程）会获得该所，这种就是公平锁。而非公平锁则无法保证锁的获取是按照请求锁的顺序进行的，这样就可能导致某个或者一些线程永远获取不到锁。

在Java中，**synchronized就是非公平锁，它无法保证等待的线程获取锁的顺序。而对于ReentrantLock 和 ReentrantReadWriteLock，它默认情况下是非公平锁，但是可以设置为公平锁**

**可中断锁**

顾名思义，可中断锁就是可以响应中断的锁。在Java中，synchronized就不是可中断锁，而Lock是可中断锁。  
　　如果某一线程A正在执行锁中的代码，另一线程B正在等待获取该锁，可能由于等待时间过长，线程B不想等待了，想先处理其他事情，我们可以让它中断自己或者在别的线程中中断它，这种就是可中断锁。在前面演示tryLock(long time, TimeUnit unit)和lockInterruptibly()的用法时已经体现了Lock的可中断性。

[Link 1]: https://so.csdn.net/so/search?q=%E9%87%8D%E5%85%A5%E9%94%81&spm=1001.2101.3001.7020
[Link 2]: https://so.csdn.net/so/search?q=%E9%80%92%E5%BD%92%E8%B0%83%E7%94%A8&spm=1001.2101.3001.7020