锁粗化是JVM自动优化，将循环内重复加锁合并为单次锁；需满足锁对象未逃逸、无方法调用改变锁语义、无中断结构、不暴露给其他线程等条件。
锁粗化不是手动写的优化技巧，而是 JVM 在运行时自动完成的编译级优化。它专治一种典型性能隐患：循环体内对同一对象反复加锁解锁。这种写法看似安全，实则可能让锁开销暴涨十倍以上。
哪些循环会触发锁粗化？
JVM（主要是 HotSpot 的 C2 编译器）只在满足全部条件时才合并锁：
- 锁对象是局部变量或经逃逸分析确认未逃逸的对象（比如 new StringBuffer()、new Object()）
- 循环体内部没有方法调用可能改变锁语义（如 wait()、notify()、重写过的同步方法）
- 循环中不含 if/switch、try-catch、break、return 等打断同步流的结构
- 锁对象没被暴露给其他线程（不存入 static 集合、不传给日志框架、不放进 ThreadLocal 以外的容器）
典型可粗化场景：StringBuffer.append() 循环
下面这段代码是锁粗化的教科书案例：
public String build() {StringBuffer sb = new StringBuffer();
for (int i = 0; i sb.append("x");
}
return sb.toString();
}
JVM 识别出：sb 是局部未逃逸对象；append() 是同步方法；100 次调用连续无干扰；内部实现已被内联。于是将整个循环包裹进一个 synchronized(sb) 块——等效于只加锁一次、执行全部 append、再解锁一次。
为什么本地测试常看不到效果？
锁粗化依赖 JIT 编译，而 C2 编译器默认要等方法被调用超 10000 次才介入。冷启动、短命程序、低频方法根本不会触发。验证时需：
- 确保方法被高频调用（例如压测循环执行上万次）
- 启用 -XX:+PrintCompilation 观察编译日志
- 避免在循环中插入 toString()、log.info()、计数器更新等“污染操作”，它们会直接禁用粗化
开发者能做的实际优化
你无法强制开启锁粗化，但可以为它创造条件，或绕过依赖：
- 优先用 StringBuilder 替代 StringBuffer（无同步开销，逃逸分析后还能进一步消除锁）
- 若必须用同步对象，把循环整体包进一个 synchronized 块，相当于手动完成粗化
- 检查循环内是否混入非纯操作（如远程调用、IO、日志），它们不仅阻止粗化，本身也该移出锁范围
