锁消除是JVM通过逃逸分析在JIT编译阶段自动移除未逃逸对象的无意义同步操作；前提是对象仅在当前线程内使用且不被外部访问，如局部StringBuffer的append调用。
直接让 JVM 在运行时自动跳过 StringBuffer 的 synchronized 方法调用，不需要改代码、也不需要换 StringBuilder——关键在于确保对象不逃逸，且 JIT 编译器能识别并优化。
确保 StringBuffer 对象严格限定在方法内使用
锁消除只对“完全私有”的对象生效。只要 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 编译，短时间压测看不到效果
不必强求，但值得信任
现代 HotSpot（JDK 8u261+ 及 JDK 11/17/21 默认 Server 模式）已将逃逸分析与锁消除深度集成。只要代码结构干净，StringBuffer 在局部拼接场景下，和 StringBuilder 的实测性能几乎一致——JVM 确实在背后悄悄抹掉了那些本就不该存在的锁。
