【java】动态高并发时为什么推荐重入锁而不是Synchronized？

╰+攻爆jí腚メ 2023-01-23 08:52 109阅读 0赞

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70]

# 1.概述 #

转载：[http://www.dreamwu.com/post-1758.html][http_www.dreamwu.com_post-1758.html]  
这个图画的不错，有助于加深理解。

# 前言碎语 #

Synchronized和 ReentrantLock 大家应该都不陌生了，作为java中最常用的本地锁，最初版本中 ReentrantLock 的性能是远远强于 Synchronized 的，后续java在一次次的版本迭代中 对 Synchronized 进行了大量的优化，直到 jdk1.6 之后，两种锁的性能已经相差无几，甚至 Synchronized 的自动释放锁会更好用。

在面试时被问到 Synchronized 和 ReentrantLock 的使用选择时，很多朋友都脱口而出的说用 Synchronized ，甚至在我面试的时候问面试者，也很少有人能够答出所以然来，moon 想说，这可不一定， 只对标题感兴趣的同学可以直接划到最后 ，我可不是标题党~

# Synchronized使用 #

在 java 代码中 synchronized 的使用 是非常简单的

1.直接贴在方法上(锁住的是当前类的字节码文件)  
2.贴在代码块儿上(锁住的是对象)

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 1]  
程序运行期间，Synchronized那一块儿代码发生么什么？  
来看一张图

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 2]  
在多线程运行过程中， `线程会去先抢对象的监视器` ，这个监视器是对象独有的，其实就相当于一把钥匙，抢到了，那你就获得了当前代码块儿的执行权。

其他没有抢到的线程会进入队列(SynchronizedQueue)当中等待，等待当前线程执行完后，释放锁.

最后当前线程执行完毕后通知出队然后继续重复当前过程.

从 jvm 的角度来看 monitorenter 和 monitorexit 指令代表着代码的执行与结束 。

# SynchronizedQueue #

SynchronizedQueue 是一个比较特殊的队列，它没有存储功能，它的功能就是维护一组线程,其中每个插入操作必须等待另一个线程的移除操作，同样任何一个移除操作都等待另一个线程的插入操作。因此此队列内部其 实没有任何一个元素，或者说容量是0，严格说并不是一种容器。由于队列没有容量，因此不能调用 peek 操作，因为只有移除元素时才有元素。

# 举个例子： #

喝酒的时候， `先把酒倒入酒盅，然后再倒入酒杯，这就是正常的队列 。`

喝酒的时候， `把酒直接倒入酒杯，这就是 SynchronizedQueue 。`

这个例子应该很清晰易懂了，它的好处就是可以直接传递，省去了一个第三方传递的过程。

# 聊聊细节，锁升级的过程 #

在 jdk1.6 以前，Synchronized 是一个重量级锁，还是先贴一张图

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 3]  
这就是为什么说，Synchronized 是一个重量级锁的原因， 因为每一次锁的资源都是直接和 cpu 去申请的，而 cpu 的锁数量是固定的 ，当 cpu 锁资源使用完后还会进行锁等待，这是一个非常耗时的操作。

**但是在jdk1.6，针对代码层面进行了大量的优化，也就是我们常说的锁升级的过程。**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 4]  
这就是一个 锁升级的过程 ，我们简单的说说：

*  `无锁`：对象一开始就是无锁状态。
 *  `偏向锁`： 相当于给对象贴了一个标签 (将自己的线程 id 存入对象头中)，下次我再进来时，发现标签是我的，我就可以继续使用了。
 *  `自旋锁`： 想象一下有一个厕所，里面有一个人在，你很想上但是只有一个坑位，所以你只能徘徊等待，等那个人出来以后，你就可以使用了 。 这个自旋是使用 cas 来保证原子性的，关于 cas 我这里就不再赘述了。
 *  `重量级锁`： 直接向 cpu 去申请申请锁 ，其他的线程都进入队列中等待。

# 锁升级是什么时候发生的？ #

*  偏向锁：一个线程获取锁时会由无锁升级为偏向锁
 *  自旋锁：当产生线程竞争时由偏向锁升级为自旋锁,想象一下 while(true) ;
 *  重量级锁：当线程竞争到达一定数量或超过一定时间时，晋升为重量级锁

# 锁的信息是记录在哪里的？ #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 5]  
这张图是对象头中 `markword 的数据结构` ，锁的信息就是在这里存放的，很清楚的表明了锁在升级的时候锁信息的变动， 其实就是通过二进制的数值，来对对象进行一个标记，每个数值代表一种状态 。

# 既然synchronized有锁升级那么有锁降级吗？ #

这个问题和我们的题目就有很大的关联了。

在 HotSpot 虚拟机中是有锁降级的， 但是仅仅只发生在 STW 的时候 ，只有垃圾回收线程能够观测到它，也就是说， 在我们正常使用的过程中是不会发生锁降级的，只有在 GC 的时候才会降级。

所以题目的答案，你懂了吗？哈哈，我们接着往下走。

# ReentrantLock的使用 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 6]

ReentrantLock 的使用也是非常简单的，与 Synchronized 的不同就是需要自己去手动释放锁，为了保证一定释放，所以通常都是和 try~finally 配合使用的。

# ReentrantLock的原理 #

ReentrantLock 意为 可重入锁 ，说起 ReentrantLock 就不得不说 AQS ，因为其 底层就是使用 AQS 去实现的。

ReentrantLock有 两种模式 ，一种是公平锁，一种是非公平锁。

公平模式下等待线程入队列后会严格按照队列顺序去执行  
非公平模式下等待线程入队列后有可能会出现插队情况

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 7]

这就是ReentrantLock的结构图，我们看这张图其实是很简单的，因为主要的实现都交给AQS去做了，我们下面着重聊一下AQS。

# AQS #

AQS(AbstractQueuedSynchronizer): AQS 可以理解为就是 一个可以实现锁的框架 。

## 简单的流程理解： ##

### 公平锁： ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 8]  
第一步：获取状态的 state 的值。如果 state=0 即代表锁没有被其它线程占用，执行第二步。如果 state!=0 则代表锁正在被其它线程占用，执行第三步。  
第二步：判断队列中是否有线程在排队等待。如果不存在则直接将锁的所有者设置成当前线程，且更新状态 state 。如果存在就入队。  
第三步：判断锁的所有者是不是当前线程。如果是则更新状态 state 的值。如果不是，线程进入队列排队等待。

### 非公平锁： ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 9]  
第一步：获取状态的 state 的值。如果 state=0 即代表锁没有被其它线程占用，则设置当前锁的持有者为当前线程，该操作用 CAS 完成。如果不为0或者设置失败，代表锁被占用进行下一步。  
此时获取 state 的值，如果是0，代表刚好线程释放了锁，此时将锁的持有者设为自己如果不是0，则查看线程持有者是不是自己如果是，则给state+1，获取锁如果不是，则进入队列等待  
读完以上的部分相信你对AQS已经有了一个比较清楚的概念了，所以我们来聊聊小细节。

AQS使用state同步状态(0代表无锁，1代表有)，并暴露出 getState 、 setState 以及 compareAndSet 操作来读取和更新这个状态，使得仅当同步状态拥有一个期望值的时候，才会被原子地设置成新值。

当有线程获取锁失败后，AQS是通过一个 双向的同步队列 来完成同步状态的管理,就被添加到队列末尾。

![在这里插入图片描述][20210713220134172.png]  
这是定义头尾节点的代码，我们可以先使用 volatile 去修饰的，就是保证让其他线程可见， AQS 实际上就是修改头尾两个节点来完成入队和出队操作的。

AQS 在锁的获取时，并不一定只有一个线程才能持有这个锁，所以此时有了 独占模式和共享模式 的区别，我们本篇文章中的 ReentrantLock 使用的就是独占模式，在多线程的情况下只会有一个线程获取锁。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 10]  
独占模式的流程是比较简单的，就根据state是否为0来判断是否有线程已经获得了锁，没有就阻塞，有就继续执行后续代码逻辑。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 11]  
共享模式的流程根据state是否大于0来判断是否有线程已经获得了锁，如果不大于0，就阻塞，如果大于0，通过CAS的原子操作来自减state的值，然后继续执行后续代码逻辑。

ReentrantLock和Synchronized的区别  
其实ReentrantLock和Synchronized 最核心的区别就在于 Synchronized适合于并发竞争低的情况，因为Synchronized的锁升级如果最终升级为重量级锁在使用的过程中是没有办法消除的，意味着每次都要和cpu去请求锁资源，而ReentrantLock主要是提供了阻塞的能力， 通过在高并发下线程的挂起，来减少竞争，提高并发能力 ，所以我们文章标题的答案，也就显而易见了。  
synchronized是一个关键字，是由 jvm层面 去实现的，而ReentrantLock是由 java api 去实现的。  
synchronized是隐式锁，可以 自动释放锁 ，ReentrantLock是显式锁，需要 手动释放锁 。  
ReentrantLock可以让等待锁的线程响应中断，而synchronized却不行，使用synchronized时，等待的线程会一直等待下去， 不能够响应中断。  
ReentrantLock可以获取锁状态，而synchronized不能。  
说说标题的答案  
其实题目的答案就在上一栏目的第一条，也是核心的区别，synchronized升级为重量级锁后无法在正常情况下完成降级，而ReentrantLock是通过阻塞来提高性能的，在设计模式上就体现出了对多线程情况的支持。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70]: /images/20221004/5d77e5d6d095452db2ed5c23867636d3.png
[http_www.dreamwu.com_post-1758.html]: http://www.dreamwu.com/post-1758.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 1]: /images/20221004/bf2fcf14bef94042918fb1aba9df6a0c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 2]: /images/20221004/3d69ee511cb242c5a274083a088ca91d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 3]: /images/20221004/040b58abad634df98710f4ecceb3d61c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 4]: /images/20221004/7ee2432afe464d15a44613bf8d0c9117.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 5]: /images/20221004/46edd00865f34a7e980111b7adbbcbcf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 6]: /images/20221004/e2f8580fe654411d95dc686a38511f59.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 7]: /images/20221004/0c27c7047de8480da8e825a62f79ed3b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 8]: /images/20221004/09c5607cb843459684e1cf189ca1da81.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 9]: /images/20221004/bd5d216345544dfbb6704ac544709f5c.png
[20210713220134172.png]: /images/20221004/930704e69cbb4a7388efaa721e18266d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 10]: /images/20221004/fe10d4c66e8c483a8a7fba2e2cb10d2a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzIxMzgzNDM1_size_16_color_FFFFFF_t_70 11]: /images/20221004/c61dee2c4ff54debba931943284e4848.png