锁粗化与锁消除是JVM JIT编译器自动执行的运行时优化：锁粗化合并连续小粒度锁以减少开销，锁消除基于逃逸分析移除无竞争的锁，二者均不改变语义、无需手动干预，依赖热点代码编译与正确代码结构。
锁粗化和锁消除是 JVM 在运行时自动完成的优化，开发者不需要手动“使用”它们，而是要写出能让 JVM 识别并应用这些优化的代码结构。关键在于理解它们的触发条件，并避免写出阻碍优化的写法。
锁粗化：合并重复加锁，减少开销
当同一个线程在连续、无干扰的代码段中，对同一对象反复加锁解锁（尤其是循环内），JVM 会自动把锁范围扩大到整个代码块外——这就是锁粗化。它不依赖注解或配置，完全由 JIT 编译器在热点代码编译阶段决定。
- 典型场景是循环体内的 synchronized 块，比如对共享缓冲区逐条写入
- 确保循环体内没有其他线程可观察的共享状态变更（如 volatile 写、notify、修改全局集合等），否则 JVM 不敢粗化
- 不要人为拆分同步块试图“精细化”，例如把一个长操作硬拆成多个小 synchronized 块——这反而可能阻止粗化
锁消除：去掉根本不需要的锁
锁消除依赖逃逸分析（Escape Analysis）。JVM 判断某个锁对象是否只被当前线程访问、不会“逃逸”到别的线程，如果是，就直接删掉 synchronized 关键字对应的所有锁指令。
- 最常见于局部创建的对象，比如方法内 new 的 StringBuffer、ArrayList 或自定义锁对象
- 参数对象若确定不会被存入静态字段、线程共享容器或跨线程传递，也可能被消除
- 需保证 JVM 开启了逃逸分析（HotSpot 默认开启；可通过 -XX:+DoEscapeAnalysis 确认）
- 避免将局部对象赋值给 static 字段、放入 ConcurrentHashMap、或作为返回值传出——这些都会导致逃逸，锁无法消除
怎么验证优化是否生效
单纯看 Java 源码无法确认，必须结合 JVM 运行时行为：
立即学习“Java免费学习笔记（深入）”；
- 用 -XX:+PrintCompilation 查看 JIT 编译日志，观察热点方法是否被编译
- 配合 -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly（需 hsdis）查看汇编，确认 monitorenter/monitorexit 指令是否消失或合并
- 对比开启/关闭逃逸分析（-XX:+/-DoEscapeAnalysis）或锁优化（-XX:+/-EliminateLocks）时的性能差异
真正该做的不是“用”，而是“不干扰”
你不需要调用 API 或写特殊语法。只需保持代码简洁清晰：局部对象尽量短生命周期、同步范围合理、避免不必要的共享。JVM 会在合适的时机自动完成锁粗化与锁消除——前提是你的代码没给它制造歧义。
