JVM锁机制：偏向锁、轻量锁与重量锁解析

本文深入剖析了JVM中三种核心锁机制——偏向锁、轻量级锁与重量级锁的演进逻辑、触发条件、升级路径及实际性能影响，揭示了“锁膨胀”背后严谨而精妙的设计权衡：偏向锁并非一劳永逸，只要出现竞争就启动存活检查并可能升级；轻量级锁依赖自适应自旋，在连续失败后才退守重量级锁；而重量级锁则彻底交由操作系统调度，带来显著上下文切换开销。文章不仅厘清了hashCode、wait/notify、GC等常见操作如何悄然破坏锁优化，还提供了JOL、jstack等实战工具链来精准验证锁状态，帮助开发者跳出“黑盒猜测”，真正看懂同步背后的字节码与内存布局，从而在高并发场景下做出更稳健的锁策略选择。

偏向锁什么时候会失效并升级？

偏向锁不是永久有效的，只要出现“另一个线程来竞争”这个事实，它就大概率要升级——但不是立刻升，而是触发一连串检查。关键在于：**偏向锁不会主动释放，所以“竞争”发生时，JVM必须先确认原持有线程是否还活着、是否还在用这把锁**。

常见触发场景包括：

• 第二个线程调用 synchronized(obj) 试图进入同一同步块
• 任意线程对已偏向对象调用 obj.wait() 或 obj.notify()（哪怕还是原线程）→ 直接升级为轻量级锁
• 任意线程调用 obj.hashCode() → 如果对象正处在偏向状态，强制升级为重量级锁（因为 hashCode 需要存进 Monitor，而偏向锁的 Mark Word 没地方存）
• GC 过程中发现偏向线程已消亡，且锁未被释放 → 清空偏向信息，重置为无锁状态，下个竞争者可重新偏向

容易踩的坑：-XX:BiasedLockingStartupDelay=0 必须配 -XX:+UseBiasedLocking 才生效；默认延迟 4 秒，意味着刚启动那几秒你测不到偏向行为，别误判“没开启”。

轻量级锁自旋失败后一定升级为重量级锁吗？

是的，但“失败”的判定比想象中严格：不是某一次 CAS 失败就升级，而是**连续自旋达到阈值（默认 10 次）后仍无法获取锁，才触发升级**。而且 JDK 6+ 默认启用自适应自旋——如果上次在同一个锁上自旋成功了，这次就会多旋几次；反之则可能跳过自旋直接阻塞。

实操建议：

• 可通过 -XX:PreBlockSpin=20 调高固定自旋次数（仅 JDK 6~8 有效），但更推荐依赖自适应逻辑
• 若应用大量短临界区 + 高并发争抢（如高频计数器），自旋反而浪费 CPU，此时关闭偏向锁 + 适度调低自旋（或用 ReentrantLock 配合 tryLock()）更稳
• 注意：轻量级锁解锁时会校验 Mark Word 是否匹配，若不一致（比如被其他线程篡改过），会直接唤醒等待队列，不走正常释放流程

性能影响很实际：自旋期间线程不挂起，但占着 CPU；一旦升级为重量级锁，线程进 Monitor 队列、OS 调度介入、上下文切换开销立刻上来——这就是为什么“锁膨胀”常成为 GC 日志里 BlockingQueue 或 ConcurrentHashMap 初始化阶段的隐形瓶颈。

重量级锁的 Monitor 到底长什么样？

它不是一个 Java 对象，而是 JVM 在对象头外维护的一块 C++ 结构体，包含三个核心字段：_owner（持有线程指针）、_WaitSet（调用 wait() 挂起的线程队列）、_EntryList（正在自旋或阻塞等待锁的线程队列）。一旦锁膨胀到这一步，所有后续竞争都绕不开操作系统线程调度。

关键事实：

• Monitor 是 lazy-initialize 的——只有首次升级时才分配，不是每个对象都有
• hashCode() 和 wait()/notify() 一定会走到 Monitor，所以它们天然破坏偏向性
• 重量级锁状态下，synchronized 的入口不再是 CAS，而是调用 ObjectSynchronizer::enter()，走 OS mutex（如 pthread_mutex_t）
• 使用 JOL（Java Object Layout）工具查看对象头，能看到 Mark Word 变成指向 Monitor 的指针，且锁标志位为 010

兼容性提醒：某些老版本 JDK（如 7u40 前）在 CMS GC 下曾有 Monitor 泄漏问题；JDK 8u40 后基本稳定，但若频繁看到 java.lang.Thread.State: BLOCKED (on object monitor) 占比突增，就得查是不是锁粒度太粗或存在隐式锁竞争。

怎么验证当前锁到底处于哪种状态？

不能靠猜，得用工具看 Mark Word。最直接的是用 JOL：new org.openjdk.jol.vm.VM().details() 确认 JVM 参数生效，再用 ClassLayout.parseInstance(obj).toPrintable() 输出对象头十六进制值，对照锁状态位解析。

示例判断逻辑（Mark Word 低 3 位）：

• 001 → 无锁（未锁定，可偏向）
• 101 → 偏向锁（thread ID 存在，且偏向位为 1）
• 000 → 轻量级锁（指向当前线程栈中 Lock Record 的指针）
• 010 → 重量级锁（指向 Monitor 的指针）

容易被忽略的点：JVM 参数 -XX:+PrintSynchronizationStatistics 会输出全局锁统计（如偏向撤销次数），但只在退出时打印；生产环境慎用。真正实用的是配合 jstack -l 查看线程堆栈中的锁状态描述——里面明确写着 “locked <0x...> (a java.lang.Object)” 还是 “- waiting to lock <0x...>”，后者基本就是重量级锁排队了。

理论要掌握，实操不能落！以上关于《JVM锁机制：偏向锁、轻量锁与重量锁解析》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！