同步消除是JIT编译器基于逃逸分析结果，在生成机器码时跳过对未逃逸对象的加锁/解锁操作，而非删除synchronized关键字；它消除冗余同步开销，提升单线程局部对象操作性能。
同步消除不是删掉 synchronized 关键字，而是 JIT 编译器在生成机器码时，跳过对未逃逸对象执行加锁/解锁的实际操作。它依赖逃逸分析的结论——只要确认对象不会被其他线程访问，那锁就纯属冗余。
逃逸分析是锁消除的前提
JVM 先判断一个对象是否“逃逸”：如果它只在当前方法内创建、仅被当前线程使用、不作为返回值、不赋给静态字段或实例字段、不传入可能跨线程调用的方法（如 Thread.start() 或 Executor.submit()），就标记为“未逃逸”。这类对象天然线程私有，不存在竞争可能。
- 未逃逸 → 对象生命周期封闭 → 同步无意义 → JIT 不生成
monitorenter/monitorexit指令 - 哪怕用了
StringBuffer或自定义synchronized方法，只要对象没逃逸，锁逻辑就被抹去 - 逃逸分析默认开启（Server 模式下），但需确保使用 C2 编译器（而非 C1），否则锁消除不会触发
典型可消除场景
常见于方法内部临时构造的线程安全类，它们的同步方法本意是防多线程并发，但在单线程局部作用域中完全多余：
-
StringBuffer sb = new StringBuffer(); sb.append("a").append("b");——append内部虽有synchronized，但sb未逃逸，锁被消除 -
Vector list = new Vector(); list.add(x);—— 仅在方法内使用，不传出、不共享，同步开销被跳过 -
Counter c = new Counter(); c.increment();—— 自定义同步方法，只要c是局部新对象且未暴露，同样适用
为什么能提升性能
即使没有真实竞争，synchronized 仍会触发 monitor 进入/退出流程：修改对象头 Mark Word、潜在 CAS、内存屏障，甚至可能引起线程状态切换。对高频小对象操作（如字符串拼接、循环内临时集合），这些开销累积明显。
- 锁消除后，字节码里仍有
monitorenter/monitorexit，但 JIT 编译出的汇编中找不到lock前缀指令 - JMH 实测显示：关闭逃逸分析后，
StringBuffer.append比开启时慢约 15%，差的就是这几处被省掉的锁路径 - 它不改变语义，也不影响调试或字节码验证，纯粹是运行期的本地代码优化
如何让锁消除更易生效
开发者不能直接控制锁消除，但可以通过编码习惯提高 JVM 的识别确定性：
- 缩小变量作用域：优先在方法内
new，避免提升为字段或静态引用 - 避免间接逃逸：不用泛型容器或反射传递对象；少用
this作为参数传入外部方法 - 慎用返回对象：
return new Result()容易导致逃逸；可改为拆解为基本类型返回 - 避免干扰编译：远程调试、JDWP agent、超长方法（超 C2 阈值）都可能导致逃逸分析退化或禁用
