高并发时为什么推荐ReentrantLock而不是synchronized

目录

  • [1、最初的 synchronized](#1、最初的 synchronized)
  • [2、synchronized 的优化](#2、synchronized 的优化)
  • [3、但是,JAVA的最终答案 JDK 21 LTS 来了](#3、但是,JAVA的最终答案 JDK 21 LTS 来了)

1、最初的 synchronized

它默认对临界资源添加重量级锁,即使可能并不存在竞争,只要走到临界区通通给你加锁。

现在来回答问题:

1) 如果是低于 JDK 1.5,抱歉你没得选,只能先将就着用 synchronized 重量级锁

2)如果你的 JDK 版本是1.5 那么推荐 ReentrantLock,这个时候的 synchronized 还是默认加重量级锁 。

接下来我们看看 JDK 1.6 干了啥

2、synchronized 的优化

在JDK 1.6 ,官方引入了如下的一系列优化:

  1. 锁消除
  2. 锁粗化
    3)锁升级:无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁
    重点介绍影响比较大的 "锁升级"
    无锁: 不存在任何互斥资源的竞争,无需加任何锁。
    偏向锁:当临界资源被某一个线程访问到了,那么在临界资源的对象头里标记偏向锁;在添加偏向锁的线程结束锁定前:1) 如果没有其它线程竞争该临界资源,效率等同无锁;2) 若此时另一个线程也希望访问该临界资源,那么偏向锁将升级为轻量级锁。(补充,新版本的JDK中,偏向锁已经被移除)
    轻量级锁:何谓轻量级锁? 就是当被多个线程竞争的临界资源上,若存在轻量级锁时,等待获取锁的线程不会直接进入等待队列,而是先尝试指定次数的自旋,如果超过默认自旋次数仍未获取到锁,那么轻量级锁将会升级为重量级锁。(自旋次数JVM可配置,但是一般不建议动它)
    重量级锁:如果临界资源上已经被某个线程,添加了重量级锁,那么当其它线程过来竞争锁的时候,就会直接进入等待队列,直至当前线程推出临界区,才会被唤醒、执行临界区。

然后我们重点说一下,轻量级锁的自旋,它好在哪里?了解JVM 并发编程模型的人都知道,在 JDK 21 LTS 推出虚拟线程之前,线程的调度是依托于底层的操作系统内核来完成的,相当于线程的:创建、等待、唤醒、销毁 ... 等等动作都直接依赖操作系统内核的API来完成,这是非常重型的操作, 所谓重量级锁,就是因为它直接阻塞别的线程,是一个非常耗费资源的操作。

而引入这个特性之后,其实 synchronized 的性能已经有了长足的进步,到了这里,其实跟 ReentrantLock 对比已经丝毫不怵了;甚至因为升级这个特性,有些时候 synchronized 会有更强悍的表现。


当 JDK1.6 <= version < JDK 21, 我们来回答问题:

高并发下 ReentrantLock 和 synchronized 哪个性能更好?

这个题可能没有标准答案,这里需要结合存在临界资源竞争的场景,来具体分析实际的临界操作行为,ReentrantLock 和 synchronized 谁更好。

  1. 当操作单一且耗时较短时,可以使用 synchronized 来做同步控制,因为只要不升级为重量级锁,性能损耗是极小的;且由于官方基于JVM做了针对性的优化, 那么它的适配性应当是更好的,如果没有复杂需求、临界操作并不复杂的时候,建议使用synchronized,因为它足够简单,性能也不在是鸿沟。
  2. 而 ReentrantLock它功能更加强大,它是在用户态下基于 AQS (Abstract Queued Synchornizer)实现,它不会阻塞内核线程。ReentrantLock 支持中断等待、支持公平锁、支持锁定多个对象,这些都是 synchronized 所不能具备的特性,在较为复杂的场景下,尤其建议使用 ReentrantLock 。

这里有一个值得思考的事情, AQS 实现的Lock 要考虑一个点,如果临界区很耗时,存在多个线程排队的时候,由于它没有进行上下文的切换,说明排队中的线程是没有被挂起的。在非虚拟线程场景下,jvm线程跟操作系统内核线程是一比一深度绑定的,那么是否应该指出这种情景下可能存在,cpu空转浪费资源。

不论是从ReentrantLock,还是synchronized的角度看,我们做程序设计时,应当保证临界区尽可能的小,尽可能的高效。

这里判断的临界值是:synchronized 阻塞再拉起线程的消耗,是否远大于临界区的执行时长。如果是,那么必须使用 Reentrantlock。否则,当阻塞再拉起线程的代价,远小于临界区执行的消耗时,应当慎重考虑使用何种锁。起码该JVM线程被阻塞后, 内核线程能释放出来干点别的事。

-- 如果有人,不看版本,不分析业务临界操作行为,就直接说谁好谁差,一律视为半桶水就行了。

3、但是,JAVA的最终答案 JDK 21 LTS 来了

JDK8 之后,最值得升级的 JDK 版本,虚拟线程,号称史诗级的加强,下一个主权就是它了!!!

自此,虚拟线程成为了JVM正式支持的功能.(jdk 19 的虚拟线程只是预览功能)

这里就不得不重点介绍一个特性了:JVM 并发编程模型,前文提到,在JDK 21 LTS 推出虚拟线程之前,jvm 的线程调度依赖操作系统内核。

在 JDK 21 的时代,JVM的线程被划分为了如下两种类型:

平台线程:所谓平台线程就是,跟操作系统内核深度绑定基于操作系统内核实现,其实它就是 JDK 21 LTS 版本之前的java 线程,"平台线程" 的调度依赖操作系统内核。

虚拟线程:JDK 21 LTS 新特性,"虚拟线程" 只在 JVM 内部调度,"虚拟线程"的调度,不再依赖操作系统内核的线程调度,它只发生在 JVM用户态,所以 "虚拟线程" 的调度行为是非常轻量的。"虚拟线程" 有等待队列,"虚拟线程"的执行需要靠"平台线程"来调度等待队列。可以理解为多个"虚拟线程",在竞争"平台线程" 的cpu时间分片.

在虚拟线程的场景下,我们开发者,调用的是虚拟线程,"平台线程"由 JVM自身进行控制。我们在 "虚拟线程" 内部不论执行了多少休眠、阻塞等操作,丝毫不会影响"平台线程"的调度。

  1. 当虚拟线程休眠、阻塞、等待时,那么它将会从 "平台线程" 上 unmount 并进入等待队列
  2. 当 "平台线程" 上unmount 了某个虚拟线程,或者某个虚拟线程执行结束了,那么 "平台线程" 会在依据一定的规则,从虚拟线程等待队列里唤起并mount某一个虚拟线程,执行时间分片。
  3. 虚拟线程所需的空间极小,在 JDK 21 环境下,可以清理拉起数万、甚至数十万的虚拟线程,同等硬件资源下,相较于之前的并发编程模型,可以更多拉起的线程数,已经到指数级了。这是几近可以跟 golang 在高并发领域,掰头一下的水平了,这够高并发了吧?
    由此来看 "虚拟线程" 这种用户态实现的并发编程模型,在高并发场景下,要远胜于之前的 "操作系统内核态" 并发编程模型。

我用了这么多文字介绍JVM并发编程模型,那么它跟 ReentrantLock 和 synchronized 有什么关系呢?

这是因为,synchronized 会将虚拟线程固定在平台线程上,在 synchronized 临界区执行结束之前,无法被 unmount, 这样是会影响高并发场景下虚拟线程的调度效率的。

而ReentrantLock 就不会有这样的问题了,碰到阻塞操作时,"虚拟线程"会很丝滑的从"平台线程"上unmount,让出"平台线程的"时间分片。


现在我们基于 JDK 21 LTS 版本来回答问题:高并发下 ReentrantLock 和 synchronized 哪个性能更好?

1)首先为了有更好的高并发体验(IO密集型),应当使用 "虚拟线程"进行开发

  1. 由于 synchronized 会阻止虚拟线程遇到阻塞后从 "平台线程"上 卸载,所以不推荐在高并发场景使用它,它会极大的影响虚拟线程在平台线程上的调度。在虚拟线程的版本, "ReentrantLock" 才是最终答案。

当然你要是说我不用 "虚拟线程" ,那答案同第二节所述。