怎么利用逃逸分析自动触发的“锁消除（Lock Elision）”抹平不必要的 StringBuffer 线程同步-java教程-PHP中文网

锁消除是jvm通过逃逸分析在jit编译阶段自动移除未逃逸对象的无意义同步操作；前提是对象仅在当前线程内使用且不被外部访问，如局部stringbuffer的append调用。

怎么利用逃逸分析自动触发的“锁消除（lock elision）”抹平不必要的 stringbuffer 线程同步

直接让 JVM 在运行时自动跳过 StringBuffer 的 synchronized 方法调用，不需要改代码、也不需要换 StringBuilder——关键在于确保对象不逃逸，且 JIT 编译器能识别并优化。

锁消除只对“完全私有”的对象生效。只要 StringBuffer 实例满足以下全部条件，JVM 就大概率消除其内部锁：

在方法体内 new 出来，不作为参数传入任何可能跨线程的方法（比如 Executor.submit()、Thread.start()、日志框架的异步写入方法）
不赋值给静态字段、类成员变量或全局容器（如 static Map, ?> CACHE）
不作为返回值返回给调用方
不被写入到其他已逃逸对象的字段中（例如：某个已暴露给线程池的对象的成员字段）

有些看似无害的操作会直接导致对象“逃逸”，让锁消除失效：

调用 sb.toString() 后把结果字符串存进 static 集合——StringBuffer 本身虽未传出，但若分析器无法证明 toString() 不触发内部状态泄露，保守起见可能放弃优化
把 StringBuffer 传给一个非 final、非 private 的工具方法，尤其该方法签名接受 Object 或泛型参数——JVM 无法静态确认该方法是否存储引用
在 lambda 表达式或匿名内部类中引用 sb（即使没显式传递），因为闭包捕获可能隐式延长生命周期
用反射调用 append() 或访问其字段——逃逸分析不处理反射路径，直接绕过优化

不能只看参数是否开启，得观察实际行为：

启动时加上：-XX:+DoEscapeAnalysis -XX:+EliminateLocks -XX:+PrintEscapeAnalysis -XX:+PrintCompilation
运行后关注日志中是否出现 “lock elided” 或 “eliminated” 字样，以及对应方法是否被 C2 编译（C1 不做锁消除）
用 JMH 做对比测试：分别加 -XX:+DoEscapeAnalysis 和 -XX:-DoEscapeAnalysis，测同一段 StringBuffer 拼接逻辑；性能差距约 10%–15%，基本可确认锁被消除了
注意：必须让目标方法执行足够多次（默认阈值 10000 次），才能触发 C2 编译，短时间压测看不到效果