当前位置：首页 > 文章列表 > 文章 > java教程 > 锁粗化（Lock Coarsening）：分析在循环内频繁加锁变量时，JVM 如何自动合并锁范围

锁粗化（Lock Coarsening）：分析在循环内频繁加锁变量时，JVM 如何自动合并锁范围

2026-05-24 11:24:37 0浏览收藏

小伙伴们对文章编程感兴趣吗？是否正在学习相关知识点？如果是，那么本文《锁粗化（Lock Coarsening）：分析在循环内频繁加锁变量时，JVM 如何自动合并锁范围》，就很适合你，本篇文章讲解的知识点主要包括。在之后的文章中也会多多分享相关知识点，希望对大家的知识积累有所帮助！

锁粗化是JVM JIT编译器自动将同一锁、同一线程、连续无干扰的多次加锁解锁合并为一次大范围同步的操作，典型场景是循环内对未逃逸局部对象（如StringBuffer）的反复同步调用。

锁粗化不是开发者手动调整的策略，而是 JVM 的 JIT 编译器（主要是 HotSpot 的 C2 编译器）在运行时识别出特定代码模式后，自动把多个细粒度加锁/解锁操作合并成一次更大范围同步的过程。它针对的是「同一把锁、同一线程、连续执行、中间无干扰」的场景，尤其常见于循环体内对共享对象的反复同步调用。

锁粗化在循环中的典型触发条件

当循环体内部每次迭代都对同一个锁对象执行 synchronized 块，且满足以下全部条件时，JIT 才可能将其粗化：

锁对象是局部变量或逃逸分析判定为未逃逸的对象（如 new Object() 或 final 字段）
循环内没有方法调用可能引发锁语义变化（例如 obj.wait()、obj.notify()，或任何可能被重写的同步方法）
循环中没有条件分支（if、switch）、异常处理（try-catch）或跳出逻辑（break、return）打断同步流
循环体内的操作不涉及将锁对象暴露给其他线程（比如存入 static 集合、传给 logger、放入 ThreadLocal 以外的容器）

为什么 StringBuffer.append() 在循环里常被粗化

StringBuffer 的 append() 是同步方法，下面这段代码是锁粗化的经典示例：

public String test() {
  StringBuffer sb = new StringBuffer();
  for (int i = 0; i < 100; i++) {
    sb.append("a");
  }
  return sb.toString();
}

JIT 会发现：100 次 sb.append() 实际上是对同一个 sb 对象重复加锁释放。由于 sb 是局部变量、未逃逸、循环中无分支无调用（append 内部被内联），C2 编译器就可能把整个循环包裹进一个大的 synchronized(sb) 块——等效于只加锁一次、执行完所有 append、再解锁一次。

实际效果与注意事项

粗化后性能提升明显，但代价是锁持有时间变长，可能加剧其他线程的等待。因此 JIT 对循环内的粗化非常谨慎：

它通常不会把「循环体本身」直接粗化，而是把循环内多个相邻的独立 synchronized 块合并（例如三个分开写的 synchronized(sb) { sb.append(...); }）
一旦循环中出现 sb.toString() 这类可能触发 monitor 退出语义的方法，或插入日志、计数器更新等非纯操作，粗化就会失效
冷启动、短命程序、低频调用方法根本等不到 C2 编译，所以本地简单 for 循环测试往往看不到效果；需确保方法被调用超 10000 次（默认阈值），并启用 -XX:+PrintCompilation 观察编译日志中是否出现 coarsened

怎么确认你的代码被粗化了

不能靠肉眼或单次执行耗时判断。有效方式是：

添加 JVM 参数：-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompilation -XX:+PrintInlining
让程序稳定运行足够久（比如压测几分钟），观察输出日志中对应方法名是否带 coarsened 或 lock coarsening 字样
配合 JMH 做微基准测试，关闭预热干扰，对比开启/关闭 -XX:-EliminateLocks（也控制粗化）前后的吞吐量差异

终于介绍完啦！小伙伴们，这篇关于《锁粗化（Lock Coarsening）：分析在循环内频繁加锁变量时，JVM 如何自动合并锁范围》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！