锁粗化是JVM JIT编译器（主要是HotSpot C2）在运行时自动将同一锁、同一线程、连续无干扰的多次加锁解锁合并为一次大范围同步的优化机制，通过减少monitorenter/monitorexit指令、CAS、内存屏障及线程状态切换等开销来提升性能。
锁粗化不是手动写的逻辑，而是 JVM 的 JIT 编译器（主要是 HotSpot 的 C2 编译器）在运行时自动识别并优化的机制。它不改变源码，而是在字节码层面重写加锁/解锁指令，把原本分散的多次同步操作压缩为一次更长的临界区，从而减少底层开销。
为什么合并能提效
每次 synchronized 进入和退出，JVM 都要执行：
- monitorenter / monitorexit 指令
- 更新对象头 Mark Word 中的锁状态
- 执行 CAS 操作和内存屏障
- 可能触发线程挂起或唤醒（哪怕没竞争）
循环 100 次，就是 100 套完整流程——这些开销加起来，可能比实际业务逻辑还重。锁粗化后，只做 1 次加锁、1 次解锁，中间所有操作都跑在同一个锁持有期内，CPU 周期就被真正用在了业务上。
JVM 合并的关键条件
不是所有循环里的 synchronized 都会被粗化。JIT 必须确认以下几点才敢动手：
- 锁对象完全不变：比如
synchronized(lock)中的lock是局部变量、final 字段，或逃逸分析判定未逃逸的对象（如 new Object()） - 同步块之间无干扰：中间不能有
wait()、notify()、可能被重写的方法调用，也不能有try-catch、if分支、break或return - 整个同步序列是热点代码：方法需被高频调用（默认超 10000 次），触发 C2 编译；冷启动或简单测试往往看不到效果
- 没有跨线程暴露风险：锁对象不能被存入 static 集合、传给日志框架、或放入全局容器等可能被其他线程访问的地方
典型可粗化场景
最常见的是对局部未逃逸对象的连续同步调用，比如：
public String build() {
StringBuffer sb = new StringBuffer();
for (int i = 0; i < 100; i++) {
sb.append("x");
}
return sb.toString();
}JIT 会发现：
- sb 是局部变量，未逃逸
- append() 是同步方法，每次调用都隐式 synchronized(sb)
- 循环体无分支、无外部调用（append 被内联）、无异常结构
→ 编译后等效于：synchronized(sb) { for(...) sb.append(...); }
手动写法也能引导粗化
虽然粗化是自动的，但你可以让代码更“友好”：
立即学习“Java免费学习笔记（深入）”；
- 把循环外紧邻的多个小同步块，合并成一个大块（只要中间操作轻量、快速）
- 避免在循环里调用
toString()、hashCode()等可能触发 monitor 语义变更的方法 - 不用
this或静态锁做循环内同步，优先用局部新建的锁对象 - 确认应用已稳定运行足够久，让 JIT 有时间编译；可用
-XX:+PrintCompilation查看是否出现coarsened日志
