jdk 9+并未优化重量级锁性能，而是通过禁用偏向锁、优化自旋策略、精简objectmonitor及强化逃逸分析，减少其使用频率与触发概率。
Java 中 synchronized 在 JDK 9 及之后版本中，并没有对重量级锁（Heavyweight Lock）本身做“性能优化”，而是进一步弱化其使用场景、加速锁膨胀的退出路径，并配合 JVM 全局策略降低其触发概率。换句话说：JDK 9+ 不是让重量级锁变快，而是让它更少被用到、更快被绕过或替代。
偏向锁在 JDK 9+ 被默认禁用
这是影响重量级锁实际出现频率最关键的一环：
- JDK 6 引入偏向锁，初衷是优化单线程反复加锁场景；但真实业务中对象生命周期短、竞争模式复杂，偏向锁撤销开销（尤其是批量撤销）反而成为性能瓶颈；
- JDK 9 开始，默认关闭偏向锁：
-XX:-UseBiasedLocking成为 JVM 启动默认行为； - 这意味着新创建的对象从一开始就不进入偏向状态，锁膨胀路径变为：无锁 → 轻量级锁 → 重量级锁，跳过了易引发撤销抖动的偏向阶段；
- 结果：轻量级锁自旋失败后更早、更干净地升级，避免了偏向锁撤销带来的 safepoint 停顿和 Mark Word 重写开销，间接减少了重量级锁因“被动升级延迟”导致的阻塞堆积。
轻量级锁自旋策略更激进且可控
重量级锁的触发前提是轻量级锁自旋失败。JDK 9+ 对此环节做了精细化调控：
- 引入
-XX:PretenureSizeThreshold和 GC 配合，使短命同步对象更可能分配在年轻代，缩短锁生命周期，降低长期竞争概率； - 自旋次数不再硬编码，而是由 JVM 运行时根据前序锁竞争历史动态调整（通过
UseAdaptiveSpinning默认开启）； - 当检测到某锁频繁自旋失败，JVM 会快速放弃自旋，提前膨胀为重量级锁——看似“更快变重”，实则是避免 CPU 空转浪费，让线程尽早挂起，提升整体吞吐；
- 该策略让重量级锁的启用更符合实际负载，而非机械等待固定次数，减少了无效自旋带来的响应延迟。
Monitor 与 ObjectMonitor 实现持续精简
重量级锁底层依赖 ObjectMonitor，JDK 9+ 对其内存布局与调度逻辑做了静默优化：
- Mark Word 中 Monitor 指针字段复用更紧凑，减少对象头膨胀，缓解 GC 压力；
-
ObjectMonitor的等待队列（_WaitSet）和竞争队列（_EntryList）采用更高效的链表+数组混合结构，插入/唤醒操作常数级时间复杂度提升； - 在 Linux 平台，JVM 更倾向复用
futex（fast userspace mutex）机制替代传统 pthread_mutex，大幅降低用户态–内核态切换频次——虽然仍属重量级语义，但系统调用开销显著下降； - 这些改动不改变“线程阻塞”本质，但让阻塞/唤醒动作本身更快、更省资源。
逃逸分析与锁消除成为主流前置防线
JDK 9+ 将逃逸分析（Escape Analysis）默认开启并深度集成，直接从源头减少重量级锁的生成机会：
- 若同步块内的对象未逃逸出方法作用域（如局部
new Object()），JVM 可判定该锁完全无竞争，直接执行锁消除（Lock Elision），连轻量级锁都不创建； - 对可标量替换的对象，同步代码块甚至被内联展开，彻底脱离 Monitor 流程；
- 这意味着大量原本会走到轻量级锁、再因自旋失败升级为重量级锁的代码，在编译期就被“无声移除”，根本不会触发锁膨胀流程。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
