锁消除是JVM通过逃逸分析在JIT编译阶段自动移除未逃逸对象的无意义同步操作；前提是对象仅在当前线程内使用且不被外部访问，如局部StringBuffer的append调用。
锁消除不是靠程序员手动删掉 synchronized，而是 JVM 在运行时通过逃逸分析自动识别并移除“根本不需要”的锁。它发生在 JIT 编译阶段，前提是对象不会被其他线程访问——也就是“没逃逸”。
锁消除发生的前提：逃逸分析确认对象私有
JVM 先做逃逸分析，判断一个对象是否可能被当前方法外的代码（尤其是其他线程）引用：
- 如果对象只在方法内创建、使用，且不作为返回值、不赋给静态变量、不传入其他方法（尤其不传给可能跨线程调用的方法），就判定为“未逃逸”
- 未逃逸 → 属于当前线程独占 → 对它加锁毫无意义 → JIT 编译器直接跳过生成 monitorEnter/monitorExit 指令
- 典型例子：StringBuffer sb = new StringBuffer(); sb.append("a"); sb.append("b"); —— 虽然 append 是 synchronized 方法，但 sb 没逃逸，锁就被消除了
哪些代码容易触发锁消除
常见于局部构造、单线程场景下的 JDK 线程安全类：
- StringBuffer：方法内拼接字符串，不返回也不共享
- Vector / Hashtable：仅在方法内临时使用，不暴露给外部
- 自定义 synchronized 方法：像 Counter.increment() 这种，对象只在 doSomething() 内 new 出来并调用
- 注意：即使用了 synchronized 关键字或 ReentrantLock，只要对象不逃逸，JIT 仍可能优化掉整个同步逻辑
锁消除不是默认总开，得看 JVM 参数和模式
HotSpot 默认在 Server 模式下启用逃逸分析，但锁消除依赖它：
立即学习“Java免费学习笔记（深入）”；
- 必须开启逃逸分析：-XX:+DoEscapeAnalysis（JDK8+ 通常默认开启）
- 显式启用锁消除：-XX:+EliminateLocks
- 验证是否生效：加 -XX:+PrintEscapeAnalysis -XX:+PrintCompilation，观察日志中是否有 “eliminated” 或 “lock elided” 字样
- 关闭逃逸分析后，StringBuffer 的 append 性能可能下降约 15%，差的就是那几把被省掉的锁
锁消除的本质是编译期优化，不是运行时行为
它不改变源码，也不影响字节码的语义正确性，而是在 JIT 将字节码编译为本地机器码时做的决策：
- 字节码里仍有 monitorenter/monitorexit 指令，但 JIT 编译器选择不把它们翻译成实际的锁操作
- 没有上下文切换、没有内存屏障、没有竞争等待——相当于这段同步逻辑“不存在了”
- 它和锁粗化、偏向锁一样，属于 JVM 默默做的性能优化，开发者无需干预，但得懂它何时起效、何时失效
基本上就这些。锁消除看着玄，核心就一句：对象没跑出去，锁就白加——JVM 比你还懂。
