偷偷告诉你，synchronized不再使用偏向锁啦

最新推荐文章于 2025-03-23 00:27:35 发布

原创最新推荐文章于 2025-03-23 00:27:35 发布 · 307 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#java #开发语言

本文详细解析了Java中Synchronized的锁升级过程，包括从偏向锁到轻量级、重量级锁的转变，以及为何在JDK15后偏向锁被废弃，重点分析了其可维护性差、优化效果不明显和前景不明朗的原因。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Synchronized 底层优化是Java面试常考察的点。简略来说，Synchronzied 采用逐步升级的加锁机制来降低加锁成本，每次加锁失败就升级竞争下一级锁，每升高一级，加锁成本就会提高。

在 Java 中，加锁就是线程用锁对象记录自己的一个标记。当其他线程加锁扫描到锁对象已被其他线程标记，就会加锁失败。不再执行后续临界区的代码。

一、Synchronized锁升级过程

Synchronized 首先尝试获取偏向锁（Biased lock），偏向锁会把对象头中的线程编号字段指向自己，表示锁对象被该线程标记。如果指向失败，则撤销偏向锁，升级为轻量级锁（Lightweight Lock）。这时线程使用 CAS 把对象头交换到自己的栈。如 CAS 失败，会进行重试（即自旋 Spin），重试多次仍然失败，升级到重量级锁（Heavyweight Lock），交给 OS 内核进行最终的同步处理。

二、偏向锁被废弃

偏向锁只需要设置对象头的几个字段的值就能完成加锁，“性能很高”。但在 JDK15 中，偏向锁被默认关闭。在 JDK18 中，更被标记为废弃，并不再允许通过命令行手动开启。
看起来效果很好的偏向锁，为什么逐步被打入“冷宫”？OpenJDK 开发团队在 JEP 374 中解释：

过去看到的性能提升如今远没有那么明显。许多受益于偏向锁的程序都是较旧的遗留程序，它们使用早期的 Java 集合 API，它们在每次访问时进行同步（例如 Hashtable 和 Vector ）。对于较新的程序，针对单线程场景通常使用 Java 1.2 中引入的非同步集合（例如 HashMap 和 ArrayList ），针对多线程场景，则使用 Java 5 引入的性能更高的并发结构。这意味着，如果代码升级到这些较新的类，相比偏向锁，会有更大的性能提升。此外，围绕线程池队列和工作线程构建的应用程序通常在禁用偏向锁定的情况下性能更好。（例如，SPECjbb2015 就是这样设计的，而 SPECjvm98 和 SPECjbb2005 则不是）。
偏向锁定的代价是在发生锁争用时需要执行昂贵的撤销操作。因此，受益于它的程序只是那些无竞争同步操作的程序。偏向锁的高效是假定在执行简单的锁检查加上偶尔昂贵的撤销成本，仍然低于执行 CAS 指令的成本。但 HotSpot 已经发生了很大的变化，原子指令成本的变化也改变了保持该关系所需的无竞争操作的数量。
另一个值得注意的方面是，当同步操作上花费的时间只占程序总工作负载的一小部分时，即使先前的成本关系成立，程序也不会从偏向锁中获得明显的性能改进。