synchronized 不存在“锁粗化自愈机制”；锁粗化是JIT编译期对连续同锁对象的同步块进行合并的静态优化，不处理多层嵌套、不同锁对象或含wait/notify等干扰操作的场景。
synchronized 在多层嵌套场景下并不存在所谓“锁粗化自愈机制”——这个说法是不准确的，容易引起概念混淆。jvm 的锁粗化（lock coarsening）不是一种动态恢复或自我修复的行为，它不针对“嵌套结构出问题后自动修正”，也不具备“自愈”能力；它是一种静态/半静态的编译期优化策略，只在满足严格条件时由 jit 编译器主动触发，且仅作用于连续、无竞争、同锁对象的同步块序列。
下面从三个关键角度帮你理清本质：
锁粗化不处理“嵌套”，只识别“连续同锁语句块”
多层 synchronized 嵌套（比如 synchronized(A) { synchronized(B) { ... } }）属于不同锁对象、不同临界区、存在嵌套关系的结构，JVM 不会对这类代码做粗化。
锁粗化真正关心的是这种模式：
synchronized(lock) { do1(); }
synchronized(lock) { do2(); }
synchronized(lock) { do3(); }或者更典型的循环内重复加锁：
for (int i = 0; i < 10; i++) {
synchronized(lock) { process(i); }
}✅ JIT 可能将其优化为：
synchronized(lock) {
for (int i = 0; i < 10; i++) {
process(i);
}
}⚠️ 但如果是：
立即学习“Java免费学习笔记（深入）”；
synchronized(a) {
// ...
synchronized(b) { // 不同锁对象 → 粗化不生效
// ...
}
}→ 完全不会合并，也不会“自愈”成单锁。
所谓“自愈”其实是误解了锁升级与粗化的边界
有人把“偏向锁被撤销后升级为轻量级锁，再配合粗化减少 CAS 次数”理解为“自愈”，这是混淆了两个独立机制：
- 锁升级（bias → lightweight → heavyweight）：响应竞争，解决锁安全性问题；
- 锁粗化：响应高频小同步，解决指令开销问题；
- 二者无因果关系，也不联动。粗化发生在编译阶段，而锁升级发生在运行时对象头状态变更过程中。
即使某段代码因竞争导致偏向锁被撤销，只要它仍满足粗化条件（如循环内连续同锁），JIT 依然可能对其粗化；反之，若中间插入了非同步语句、wait/notify、或锁对象逃逸，粗化就直接失效——这不是“修复失败”，而是条件不满足，压根不启动。
真正影响粗化是否生效的硬性条件
JIT（主要是 C2 编译器）启用粗化需同时满足：
- 所有
synchronized块锁定完全相同的对象引用（字节码层面可判定，非运行时值）； - 这些块在控制流图中逻辑连续（如 for 循环体、相邻 if 分支、无跳转打断）；
- 中间无任何可能引发线程可见性副作用的操作：
- 不调用
wait()/notify()/notifyAll()； - 不修改其他线程可见的共享变量（JIT 依赖逃逸分析+控制流推断）；
- 不发生锁释放（如
synchronized(x){...}后紧跟synchronized(y){...}就中断了）；
- 不调用
- 方法经内联后，整体结构清晰，JIT 能确认无并发风险。
不满足任一条件，粗化就跳过——没有“尝试失败后再自愈”的过程。
基本上就这些。
