synchronized 通过锁升级（无锁→偏向锁→轻量级锁→重量级锁）、锁消除（JIT逃逸分析移除无竞争锁）和锁粗化（合并高频细粒度锁）动态优化同步开销。
synchronized 在 JVM 层面不是简单粗暴地一上来就用重量级锁，而是通过一套动态、分层的优化机制来减少同步开销。这些优化在运行时自动生效，开发者通常无需手动干预，但理解它们能帮你写出更高效的并发代码。
锁升级：从无锁到重量级的自适应过程
JVM 会根据实际线程竞争情况，让锁状态逐步升级，只在必要时才付出更高代价：
- 无锁状态：对象刚创建，尚未被任何线程加锁，对象头 Mark Word 处于初始状态。
- 偏向锁：第一个线程访问时，JVM 在对象头记录该线程 ID，后续同一线程再次进入无需 CAS 或互斥操作，几乎零开销；适用于单线程反复执行的场景（如初始化、配置加载）。
- 轻量级锁：当其他线程尝试竞争，偏向锁被撤销，升级为轻量级锁；使用 CAS 尝试获取锁，失败则自旋等待（避免立即挂起线程），适合临界区短、竞争不激烈的场景。
- 重量级锁：自旋多次失败或竞争持续加剧，JVM 升级为重量级锁，依赖操作系统互斥量（Mutex），线程阻塞并进入 OS 等待队列，开销最大，但保证强一致性。
这个过程是单向的——只能升级，不能降级。一旦升到重量级锁，该对象后续所有同步操作都走重量级路径。
锁消除：编译期“删掉没用的锁”
这是 JIT 编译器基于逃逸分析做的静态优化。如果它能确定某个 synchronized 块内的变量不会被其他线程访问（比如纯局部对象、方法内新建且未逃逸的对象），就会直接移除 synchronized 关键字。
立即学习“Java免费学习笔记（深入）”；
- 常见例子：StringBuffer 的 toString() 内部有 synchronized，但若 StringBuffer 是方法内局部变量且未传出，JIT 可能消除该锁。
- 效果：完全避免锁操作，性能等同于无锁代码。
锁粗化：合并频繁的小锁
当 JIT 发现同一把锁被连续、高频地反复加锁/解锁（比如循环体内多次 synchronized），会将多个细粒度锁合并成一个更大范围的锁。
- 例如：
for (int i = 0; i 可能被粗化为 <code>synchronized(lock) { for (...) list.add(i); }。 - 目的：减少锁申请/释放次数和上下文切换，尤其对短临界区+高频率调用有效。
其他底层支撑机制
这些优化得以实现，依赖于 JVM 对对象内存结构的精细控制：
- 对象头（Mark Word）：锁状态、偏向线程 ID、hashcode、GC 分代年龄等都复用同一块内存位，不同锁状态下按需解释 bit 含义。
- Monitor（监视器）：每个 Java 对象隐式关联一个 Monitor，负责管理 EntryList（争抢队列）、Owner（持有者）、WaitSet（wait 等待队列）。
- 自适应自旋：轻量级锁阶段，JVM 不固定自旋次数，而是根据前一次锁的持有时间动态调整——上次很快释放就多自旋几次，否则快速退避。
