锁消除发生在JIT编译时，前提是逃逸分析证明同步块内对象未逃逸且满足热编译等条件；锁粗化则合并高频重复获取同一锁的相邻同步块以减少开销。
锁消除发生在什么时机？
锁消除是 JIT 编译器在运行时做的优化，前提是它能**静态证明某个 synchronized 块内的对象不会被其他线程访问**——最常见的是局部对象（如 new StringBuilder()、new Object()），逃逸分析确认该对象没“逃出”当前方法或线程。
注意：必须开启逃逸分析（JDK 8+ 默认开启），且不能禁用锁消除（-XX:-EliminateLocks）；另外，调试模式（-Xdebug）或频繁的 JIT 禁用（如刚启动时）会导致锁消除失效。
- 典型可消除场景：
StringBuffer在方法内拼接字符串后立即返回，且未传入参数或返回引用 - 不可消除的陷阱：把加锁对象赋值给
static字段、放入ConcurrentHashMap、作为参数传给未知方法 - 验证是否消除：加上
-XX:+PrintEliminateAllocations -XX:+UnlockDiagnosticVMOptions，看日志里是否有 “eliminated synchronized” 相关输出
锁粗化要合并哪些同步块？
锁粗化（Lock Coarsening）不是简单地把相邻 synchronized 合并，而是当 JIT 发现**同一把锁被连续、高频、无实际并发意义地反复获取/释放**（比如循环体内），就会把整个区域扩大为一个更大的同步块。
例如对 StringBuffer.append() 的连续调用，在字节码层面会生成多个 monitorenter/monitorexit 对，JIT 可能将其粗化为一次进入、一次退出。
- 触发条件：同一锁对象、紧邻的同步块、中间无非同步的长耗时操作（否则粗化反而降低并发性）
- 不适用场景：循环中夹杂 I/O、锁内调用了可能阻塞或重入的方法（如
wait()）、或同步块之间有共享状态变更逻辑 - 副作用：粗化后可能延长单次持有锁的时间，反而增加争用——所以它只在“锁开销 > 持有时间增长”时才启用
为什么开了逃逸分析也不一定锁消除？
逃逸分析只是前提，不是充分条件。JIT 还需满足：方法已足够热（被调用次数达标）、编译层级足够高（C2 编译器介入）、且没有干扰优化的代码模式。
- 常见干扰项：
System.out.println()（可能引入同步）、Thread.currentThread()（触发线程逃逸检查）、任意native方法调用（JIT 保守起见放弃分析） - 对象“看似局部”，但通过反射、Lambda 捕获、或
varargs数组传递，都可能导致逃逸判定失败 - 使用
-XX:+PrintEscapeAnalysis可查看每个对象的逃逸状态（GlobalEscape表示逃逸，NoEscape才可能消除）
比锁消除更值得优先做的其实是……
别太依赖锁消除和粗化——它们是 JIT 的“锦上添花”，不是解决竞争的根本手段。真正减少锁竞争，得从代码结构下手：
- 用
java.util.concurrent包里的无锁或分段锁实现，比如ConcurrentHashMap替代Hashtable，LongAdder替代synchronized counter++ - 缩小同步范围：只锁关键临界区，不要把日志、校验、I/O 包进去
- 避免锁对象暴露：别用
this或公共类对象（如String.class）做锁，优先用私有 final 对象 - 考虑读写分离：读多写少场景下，
ReentrantReadWriteLock或StampedLock能显著提升吞吐
锁消除和粗化是 JVM 自动帮你省掉的几条字节码指令；而选对并发工具、设计好锁粒度，才是你真正能掌控的性能杠杆。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
