锁粗化是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 终端节点、同步与异步等。

下载

什么情况下会被粗化

不是所有连续加锁都会被优化，JVM 要求满足几个关键条件：

• 锁的是同一个对象（比如始终是 lock 或始终是 this）
• 这些 synchronized 块在字节码层面紧邻，中间没有 I/O、sleep、阻塞调用或其它线程可见的写操作
• 运行时 profiling 数据表明该路径高频执行（JIT 编译阶段才生效）
• 锁粒度本身较轻（比如只做简单计数），否则粗化反而拖慢整体响应

手动优化建议

虽然 JVM 会自动尝试粗化，但你可以主动配合提升效果：

• 优先使用 synchronized 代码块而非同步方法，因为后者锁范围固定，不易被 JIT 扩展
• 避免在循环里做耗时操作（如网络请求、文件读写），否则粗化会放大阻塞风险
• 如果逻辑上确实需要细粒度控制（比如多个线程要交替访问不同元素），就不要依赖粗化，改用更合适的并发工具（如 ConcurrentHashMap、StampedLock）

锁粗化本质是用“稍长一点的临界区”换掉“一大堆轻量但昂贵的锁操作”，不改变语义，只节省开销。它不是万能的，但对高频、无竞争、小操作的场景特别有效。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南