锁粗化是JIT自动合并相邻同锁同步块的优化，仅对无逃逸、无分支、无调用的连续synchronized生效；锁消除则依赖逃逸分析，对未逃逸对象彻底删除synchronized字节码。
锁粗化：JIT 把多个 synchronized 合成一个，但只在特定代码模式下生效
锁粗化不是开发者手动写的优化，而是 JIT（HotSpot 的 C2 编译器）在运行时识别出连续、无干扰的加锁/解锁序列后，自动合并成单次加锁。它只对「同一把锁」且「中间没逃逸、没条件分支、没方法调用」的相邻同步块起作用。
常见错误现象：写了三段独立的 synchronized(this) 块，以为能细粒度控制，结果 JIT 合并了——你测出来的吞吐量比预期高，但锁竞争没减少，反而可能让本可并发执行的逻辑被串行化。
- 典型可粗化场景：
synchronized(obj) { a(); } synchronized(obj) { b(); } synchronized(obj) { c(); }（无中间变量逃逸、无 if/for、a/b/c 是小函数或内联候选） - 一旦中间有
obj.toString()这类可能触发锁释放语义的方法调用，或出现if (x > 0)分支，粗化就失效 - 验证方式：加 JVM 参数
-XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining，观察是否出现coarsened字样日志
锁消除：JIT 发现锁根本没被共享，直接删掉 synchronized 字节码
锁消除的前提是逃逸分析（Escape Analysis）判定对象不会逃逸出当前线程作用域。一旦成立，JIT 就认为“这把锁没人争”，连加锁指令都省了——不是降级为偏向锁，是彻底不生成。
使用场景非常受限：基本只适用于局部 new 出的对象，且所有字段写入和方法调用都在当前栈帧内完成。比如 new StringBuilder().append("a").append("b") 里的 synchronized 就常被消除。
立即学习“Java免费学习笔记（深入）”；
- 容易踩的坑：只要对象被存进
static字段、传给未知方法（如logger.info(obj)）、或放进ThreadLocal以外的容器，逃逸分析就会失败，锁消除失效 - 默认开启但依赖 JVM 参数：
-XX:+DoEscapeAnalysis（JDK8 默认开），-XX:+EliminateLocks（必须同时开） - 性能影响明显：消除后不仅没锁开销，连 monitor enter/exit 的字节码都不生成，方法更易被内联
为什么本地测试常看不到锁粗化/消除效果
这两个优化都发生在 C2 编译后的峰值性能阶段，不是解释执行或 C1 编译时发生的。冷启动、短生命周期、低迭代次数的测试，根本等不到 JIT 编译触发。
- 必须跑够阈值：方法调用次数默认 ≥ 10000（
-XX:CompileThreshold=10000），且需经历分层编译（C1 → C2） - 不能用
System.out.println()打点测耗时——它本身带锁，会污染逃逸分析和粗化判断 - JDK 版本差异大：JDK15+ 默认关闭偏向锁（
-XX:+UseBiasedLocking），但锁消除/粗化仍有效；JDK17 开始逃逸分析在某些 GC 下（如 ZGC）可能被禁用
synchronized 写法直接影响 JIT 是否敢优化
JIT 不会去猜你的意图，它只看字节码结构和运行时数据流。同一个语义，不同写法可能导致优化开关完全不同。
- 别写
synchronized(this) { ...; return x; }然后紧接着又一个synchronized(this) { ... }—— 中间没有空行或注释不影响，但 return 会让 JIT 认为控制流已退出，粗化概率降低 - 用
final局部变量持有锁对象，比直接用this或成员变量更容易触发消除（逃逸分析更确定） - 避免在
synchronized块里调用非 final 方法——哪怕只是list.size()，也可能阻止内联，进而阻断逃逸分析链
真正难的不是理解概念，是写出 JIT 愿意信的代码。它不看你注释里写了什么，只认字节码和运行时行为。
