Synchronized锁升级

最新推荐文章于 2025-06-19 20:24:15 发布

dl-kun

最新推荐文章于 2025-06-19 20:24:15 发布

阅读量875

点赞数 19

CC 4.0 BY-SA版权

分类专栏： JavaEE 文章标签：开发语言 java javaee

本文链接：https://blog.csdn.net/deku_/article/details/143025592

JavaEE 专栏收录该内容

23 篇文章

订阅专栏

jdk1.8：无锁 -> 偏向锁 -> 轻量锁 -> 重量级锁

jdk15：无锁 -> 偏向锁（默认不开启，耗费维护成本高） -> 轻量锁 -> 重量级锁

Synchronized锁升级流程

偏向锁 (Biased Locking)

目的：当一个线程多次访问同步块时，减少CAS操作的开销，提高性能。

实现：

对象头信息：每个对象都有一个对象头，其中包含Mark Word（标记字），用于存储对象的哈希码、GC年龄等信息。
初始状态：默认情况下，如果启用了偏向锁（可以通过JVM参数控制），新分配的对象的Mark Word会被设置成可偏向状态。
获取锁：当线程第一次进入同步块时，JVM会尝试使用CAS操作将Mark Word更新为指向当前线程，并设置偏向标志位。
重入：如果同一个线程再次进入同步块，由于Mark Word已经指向该线程，不需要额外的CAS操作，直接成功获得锁。
撤销：如果有其他线程试图获取锁，则需要撤销偏向锁，这涉及到停止持有偏向锁的线程，然后将锁状态升级到轻量级锁。

轻量级锁 (Lightweight Locking)

目的：在没有多线程竞争的情况下，提供比重量级锁更高效的锁定机制。

实现：

Lock Record：在线程栈中创建一个Lock Record，用来存储指向对象的指针。
CAS尝试：尝试使用CAS操作将对象头的Mark Word替换为指向Lock Record的指针。
成功：如果CAS成功，那么当前线程就获得了锁。
失败：如果CAS失败，表示存在竞争，此时会进行自旋尝试重新获取锁，若仍无法获取，则膨胀为重量级锁。默认情况下，这个CAS值是10次左右。不过，自旋的策略JVM可能会根据实际情况动态调整，如果多次自旋获取失败这个次数可能会减小。

重量级锁 (Inflated Locking)

目的：处理真正的线程竞争情况，确保线程安全。

实现：

Monitor：每个对象都关联着一个监视器（Monitor），它是一个操作系统级别的互斥锁。
阻塞与唤醒：当线程未能通过轻量级锁获取锁时，会膨胀为重量级锁。此时，线程会被挂起并放入等待队列中，直到被持有锁的线程释放锁后唤醒。
性能影响：重量级锁涉及操作系统内核态和用户态之间的切换，因此性能开销较大。

底层源码层面

对象头结构：在HotSpot虚拟机中，对象头包括了Mark Word和Klass Pointer。Mark Word的格式根据对象的状态不同而变化。
偏向锁的启用/禁用：可以通过JVM参数如 -XX:+UseBiasedLocking 或 -XX:-UseBiasedLocking 来开启或关闭偏向锁。
锁升级过程：具体实现位于HotSpot虚拟机的代码中，例如 ObjectSynchronizer.cpp 文件中的相关函数，这些函数负责处理锁的状态转换逻辑。

示例流程

初始化：对象创建时，如果是启用偏向锁的情况，Mark Word会被设置为可偏向状态。
偏向锁：线程A首次获取锁，通过CAS将Mark Word更新为指向自己，并设置偏向标志。
轻量级锁：线程B尝试获取锁，发现Mark Word已被占用，撤销偏向锁，然后尝试通过CAS更新Mark Word指向自己的Lock Record。
重量级锁：如果多个线程同时竞争，轻量级锁升级为重量级锁，未获得锁的线程将被挂起，直到锁被释放。

锁升级后，对象头里保存的hashcode去哪儿了？

hashcode是唯一的，初始化后不允许改变，hash信息并不在创建对象后就存在对象头里，在初始化hashcode后才保存到对象头里。初始化hash信息后，不允许锁升级为偏向锁，偏向锁无法保存hash信息，这时锁会自动升级为轻量级锁，轻量级锁对象头里保存的是栈桢里的LockWord信息，这里会保存hash和gc信息，锁释放后再将这些信息写回对象头里。重量级锁类似轻量级锁，不过hash信息是保存在堆里的，指向互斥量，monitor里，在锁的同步方法里使用一致性hash时，锁会升级为重量级锁。

JIT（Just In Time compiler）编译器对锁的优化

锁消除：每次都是不同的锁，例如在同步方法内部新建对象，用新的对象来创建锁，这样每次调用都是不同的锁，这是无意义的，这样JIT会优化，消除锁。

锁粗化：在同一个线程里，多次获取同一把锁顺序执行代码，与一次获取锁后顺序执行代码意义相同，JIT会将锁粗化，将多次获取锁合并为一个，将里面的代码按照顺序依次执行。

为什么JDK 15默认关闭了偏向锁

JDK 15 默认关闭偏向锁的主要原因是性能考量。虽然偏向锁在某些场景下可以显著提高性能，但在其他一些场景下，尤其是高并发环境下，偏向锁反而可能成为性能瓶颈。具体原因包括：

启动开销：启用偏向锁需要额外的时间来进行初始化，这在应用程序启动时会产生一定的延迟。
撤销开销：当多个线程竞争同一个对象时，偏向锁需要被撤销并升级为轻量级锁或重量级锁。这个撤销过程本身就有一定的开销，尤其是在频繁发生锁竞争的情况下。
内存占用：每个对象头为了支持偏向锁，需要额外的空间来存储偏向线程ID等信息，这在大量对象存在时会增加内存占用。
不适用场景：对于那些很少重复访问同一同步块的应用程序来说，偏向锁带来的性能提升并不明显，反而可能因为额外的管理开销而降低性能。

在Synchronized块里调用 hashCode 方法，触发锁升级

JDK15以前：

撤销偏向锁：hashCode 方法需要访问对象头中的哈希码信息。由于当前是偏向锁状态，对象头中的Mark Word已经被替换为指向线程的指针，因此需要撤销偏向锁。

计算哈希码：撤销偏向锁后，JVM会重新计算对象的哈希码，并将其存储在对象头中。

升级为轻量级锁：如果此时没有其他线程竞争锁，那么锁会升级为轻量级锁。轻量级锁的状态下，对象头中的Mark Word会被替换为指向线程栈帧中Lock Record的指针。

JDK15及以后：在轻量级锁状态下，对象头已经被替换为指向线程栈帧中Lock Record的指针，这意味着对象头中不再有空间来存储哈希码信息。因此，当需要调用 hashCode 方法时，JVM必须确保能够访问到正确的哈希码信息。为此，JVM选择将轻量级锁膨胀为重量级锁，这样可以恢复对象头的原始状态，从而允许存储和访问哈希码信息。