锁粗化是JVM将循环内或相邻的多个针对同一对象的synchronized块合并为一个大同步区域，从而将多次monitorenter/monitorexit压减为一次；其触发需满足同锁对象、字节码连续、无阻塞操作、热点代码等条件。
JVM 会自动把多个连续、针对同一对象的 synchronized 块合并成一个更大的同步区域，从而把多次加锁/解锁操作压减为一次——这是锁粗化的核心作用。
锁粗化发生的典型场景
它主要出现在以下代码结构中：
- 循环体内反复对同一个锁对象加锁，比如
for循环里每次迭代都写synchronized(obj) { ... } - 相邻的多个
synchronized代码块，中间没有其他线程可观察的共享状态变更 - 方法内连续调用多个被
synchronized修饰的实例方法，且锁对象一致（如this）
底层是怎么减少获取次数的
每次 synchronized 执行都会触发 JVM 的 monitor 操作：monitorenter 和 monitorexit。这些指令背后涉及：
- 检查锁状态、更新对象头 Mark Word
- 可能的 CAS 操作和内存屏障
- 线程挂起/唤醒（即使没竞争，也走检查路径）
锁粗化后，JVM 把原本分散在循环体内的 100 次加锁/解锁，变成循环外的一次进入和一次退出，直接砍掉 99% 的 monitor 开销。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
什么情况下会被粗化
不是所有连续加锁都会被优化，JVM 要求满足几个关键条件：
- 锁的是同一个对象（比如始终是
lock或始终是this） - 这些
synchronized块在字节码层面紧邻，中间没有 I/O、sleep、阻塞调用或其它线程可见的写操作 - 运行时 profiling 数据表明该路径高频执行（JIT 编译阶段才生效）
- 锁粒度本身较轻（比如只做简单计数），否则粗化反而拖慢整体响应
手动优化建议
虽然 JVM 会自动尝试粗化，但你可以主动配合提升效果：
- 优先使用
synchronized代码块而非同步方法，因为后者锁范围固定，不易被 JIT 扩展 - 避免在循环里做耗时操作（如网络请求、文件读写），否则粗化会放大阻塞风险
- 如果逻辑上确实需要细粒度控制（比如多个线程要交替访问不同元素），就不要依赖粗化，改用更合适的并发工具（如
ConcurrentHashMap、StampedLock）
锁粗化本质是用“稍长一点的临界区”换掉“一大堆轻量但昂贵的锁操作”，不改变语义，只节省开销。它不是万能的，但对高频、无竞争、小操作的场景特别有效。
