jdk1.6 之后的 synchronized 底层做了哪些优化

2025年Java面试宝典下载
提取码: 9b3g

JDK1.6 之后的 synchronized 底层做了哪些优化

说到Java中的synchronized关键字，很多人在面试中都会被问到"JDK1.6之后对synchronized做了哪些优化？"。这个问题其实是考察对Java锁机制的理解，特别是锁膨胀过程和锁优化策略。今天咱们就深入聊聊这个话题，结合真实面试场景帮你梳理答案。

锁膨胀过程：从偏向锁到重量级锁

在JDK1.6之前，synchronized的实现直接关联操作系统层面的互斥锁（Mutex Lock），这种实现方式虽然简单，但性能较差。从JDK1.6开始，HotSpot虚拟机引入了锁膨胀机制，将锁状态分为：无锁、偏向锁、轻量级锁、重量级锁四个阶段。

举个例子：当线程A首次进入同步块时，虚拟机会在对象头中记录偏向锁标记和线程ID（偏向锁阶段）。如果此时线程B尝试获取锁，虚拟机会先撤销偏向锁，升级为轻量级锁（通过CAS操作竞争锁）。如果自旋一定次数后仍未获取锁，最终会膨胀为重量级锁。这种按需升级的机制减少了直接使用重量级锁的性能损耗。

偏向锁：减少无竞争场景的开销

偏向锁优化是JDK1.6新增的核心特性。它的设计初衷是解决"无竞争场景下的同步性能问题"。比如单线程重复获取锁的场景，无需每次加锁都进行CAS操作。

具体实现上，当一个线程首次获取锁时，虚拟机会将对象头中的标记设为偏向模式，并记录线程ID。下次同一线程再进入同步块时，只需要检查对象头中的线程ID是否与当前线程一致即可，省去了CAS操作的开销。注意：偏向锁默认在应用启动几秒后才会启用（JVM参数-XX:BiasedLockingStartupDelay）。

轻量级锁：应对轻度竞争

当多个线程交替执行同步块（而非并行竞争）时，偏向锁会升级为轻量级锁。此时虚拟机会在当前线程的栈帧中创建锁记录（Lock Record），并通过CAS操作将对象头中的指针指向这个锁记录。

如果CAS成功，说明线程获取了轻量级锁；如果失败，则会自旋重试（适应性自旋）。这个过程避免了直接阻塞线程，减少了线程上下文切换的开销。如果自旋达到阈值仍未成功（默认10次），锁会升级为重量级锁。

适应性自旋：动态调整策略

JDK1.6还引入了适应性自旋优化。传统的自旋锁采用固定次数自旋（比如10次），而适应性自旋会根据"最近获取锁的成功率"动态调整自旋次数。例如：

• 如果某个锁对象最近经常自旋成功，则增加自旋次数
• 如果某个锁自旋很少成功，则直接跳过自旋进入阻塞

这种动态策略有效平衡了CPU资源消耗和线程等待时间。

锁消除与锁粗化

除了上述优化，编译器还会通过逃逸分析进行锁消除（Lock Elimination）。例如在单线程环境下使用StringBuffer的append方法时（虽然方法本身是同步的），虚拟机会直接去掉同步操作。

另一项优化是锁粗化（Lock Coarsening）。当虚拟机检测到多个连续操作对同一个对象反复加锁/解锁时（比如循环体内的同步操作），会将同步范围扩大到整个操作序列外部，减少不必要的锁竞争。

实际面试怎么答？

在真实面试场景中，可以这样组织答案：

1. 先说背景："JDK1.6之前synchronized性能差，因为直接关联操作系统锁"
2. 分点说明优化技术：偏向锁、轻量级锁、锁膨胀、适应性自旋、锁消除/粗化
3. 结合使用场景举例（比如单线程场景用偏向锁，交替执行用轻量级锁）
4. 补充锁优化的最终目标：减少直接使用重量级锁的情况

最后提一嘴：如果大家需要购买面试鸭会员，可以通过面试鸭返利网找到我，能返利25元。另外，想系统准备Java面试的话，可以下载这份面试资料：2025年Java面试宝典，内容涵盖高频考点和实战案例。