锁粗化是JIT编译器在满足同一对象连续高频同步、同步范围稳定未逃逸、达到热点阈值三个前提下，自动合并细粒度同步以减少指令开销的优化机制。

锁粗化不是简单地“把 synchronized 块拉长”，而是在特定高频、连续、同对象的加锁场景下，由 JIT 编译器自动合并多次细粒度同步操作，减少 monitorenter/monitorexit 指令开销，从而降低线程调度与上下文切换压力。它对复杂业务性能的提升，关键在于识别并满足触发条件，而非手动改写代码。

锁粗化真正起效的三个硬性前提

只有同时满足以下条件，JIT（通常是 C2 编译器）才可能执行锁粗化：

• 同一对象被连续、高频同步：例如在循环体内反复调用同一个 StringBuffer.append()、或对同一 Map 实例做连续 put()；单次调用或间隔 I/O、sleep、方法调用都会打断连续性
• 同步范围稳定且未逃逸：锁对象不能在循环中被重新赋值（如 sb = new StringBuffer()），也不能被传入其他方法、返回、存入 static 字段或全局容器——否则 JIT 无法确认其生命周期可控
• 达到 JIT 热点阈值：默认需该代码路径被调用约 10000 次，才会触发 C2 编译；短生命周期服务、冷启动阶段或压测时间不足时，粗化根本不会发生

复杂业务中典型可优化场景与反模式

在真实业务逻辑里，锁粗化常出现在数据组装、批量处理、状态累积等环节：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 可优化：订单状态聚合循环中，持续向一个局部 StringBuilder 追加日志；或风控规则引擎中，对单个 ThreadLocal 缓存 Map 连续写入多个校验结果
• 无效甚至有害：在循环内混合数据库查询、远程调用或锁对象每次新建；或粗化后临界区变长（如把 10 次小同步合并为一次含网络请求的大同步），反而加剧线程排队
• 常见误判：以为把多个 synchronized 方法手动合并成一个大块就是“锁粗化”——这是人为设计，不是 JVM 优化；JVM 的锁粗化是运行时透明发生的，不改变源码结构

如何验证锁粗化是否真实生效

不能只比耗时，要从指令层面确认：

立即学习“Java免费学习笔记（深入）”；

• 启用 -XX:+PrintCompilation，观察类似 123 b java.lang.StringBuffer::append (35 bytes) 的日志；若后续编译版本号上升、字节数下降，说明 JIT 已简化同步逻辑
• 用 JMH + -prof perfasm 对比热点汇编，确认 monitorenter/monitorexit 指令是否显著减少，且对应区域被合并为单次锁进出
• 配合 -XX:+UnlockDiagnosticVMOptions -XX:+PrintEscapeAnalysis 查看逃逸分析结果——锁粗化依赖对象不逃逸，若显示 “sb has escaped”，粗化必然失败

比锁粗化更值得优先做的三件事

在复杂业务中，锁粗化收益有限且不可控，应先夯实基础：

• 替换过时同步类型：用 StringBuilder 替代 StringBuffer，避免无谓的 synchronized 调用——锁消除再好，也消不掉本不该存在的锁
• 缩小锁粒度：把整个 service 方法加锁，改为只锁共享状态变更部分；或拆分锁对象（如按用户 ID 分段加锁），降低争用概率
• 评估锁替代方案：读多写少用 StampedLock，计数类操作用 LongAdder，集合操作优先选 ConcurrentHashMap ——这些比依赖 JIT 优化更确定、更可控