如何使用Java原生偏向锁与轻量级锁解析对象头锁升级流程

先聊聊Ja va里synchronized的锁升级。说实话，这事儿全是JVM在后台悄无声息地打理，开发者没法直接调用什么“偏向锁”或“轻量级锁”的API。但别急——虽然不能手动控制，但你完全可以通过理解对象头（尤其是那个Mark Word的变化），来观察、验证，甚至变相引导锁状态的演进。关键不在于你手动去“调用”，而在于你搞清触发条件、状态标识和运行时行为。

对象头锁升级的核心载体是Mark Word

每个Ja va对象在堆里都藏着个对象头，里面有个叫Mark Word的家伙——64位JVM上占64比特，32位上占32比特。它动态存储着锁状态、线程ID、GC年龄这些关键信息。锁的四种状态（无锁→偏向锁→轻量级锁→重量级锁）全靠Mark Word里固定比特位的组合来标识。JVM呢，就看着这些位值来决定该怎么处理synchronized请求。说白了，锁升级就是Mark Word里几个比特的“变脸游戏”。

偏向锁：单线程场景下的零开销优化

• 触发时机：对象头一回被某个线程进入synchronized块，而且这时候没有其他线程跟它抢。
• Mark Word变化（64位JVM）：
  • 原来无锁态：低2位是01，高位存hashCode或0，偏向位为0。
  • 升级后：偏向位变成1，54位填入当前线程ID，低2位还是01。
• 行为特点：这个线程后续再进来，不用CAS操作，直接比对线程ID就行，成本几乎为零。但如果其他线程想抢，就得触发偏向撤销（需要STW暂停，不过时间极短）。

轻量级锁：多线程交替但无激烈竞争时的自旋抢锁

• 触发时机：偏向锁被撤销了（也就是第二个线程来竞争），但还没到自旋的阈值。
• Mark Word变化：低2位变成00，其余62位存指向当前线程栈帧中Lock Record的指针。
• 行为特点：
  • 线程自己在栈上建一个Lock Record，把原来的Mark Word拷贝过来（这叫Displaced Mark Word）。
  • 然后通过CAS操作，把对象头更新成指向这个Lock Record的指针。
  • 如果CAS失败——说明已经被其他线程抢占了——那就自旋重试。默认最多10次（可以用-XX:PretenureSizeThreshold等参数微调）。

重量级锁：自旋失败或竞争加剧后的系统级阻塞

• 触发时机：轻量级锁自旋超限、或者多个线程同时争抢、或者锁持有时间太长。
• Mark Word变化：低2位变成10，其余62位存指向堆中Monitor对象的指针。
• 行为特点：线程直接挂起，进入操作系统内核态等待队列——用户态到内核态的切换，开销一下子就上来了。

如何实际观察与验证锁状态？

• 用JOL（Ja va Object Layout）工具打印对象头：

  System.out.println(ClassLayout.parseInstance(lock).toPrintable());

  配合-XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0启动参数，确保偏向锁默认启用。
• 控制竞争节奏来观察：
  • 单线程反复synchronized(lock)，能稳定保持偏向锁。
  • 两线程错峰执行（比如让Thread-1先跑，sleep一会儿再启动Thread-2），容易停在轻量级锁。
  • 多线程高密度争抢（比如for循环启10个线程同步操作），很快就膨胀到重量级锁了。
• 特别注意：一旦调用obj.hashCode()，对象就永久失去获得偏向锁的资格——因为Mark Word得复用空间存hash，跟线程ID冲突了。

最后说一句：锁升级是不可逆的，而且整个过程没有代码干预点——它根本就不是个API，而是JVM基于Mark Word位模式和实时竞争情况作出的底层决策。真正有效的“使用”，是写出符合各锁适用场景的代码：避免无谓的哈希计算、控制好临界区粒度、减少锁持有时间。这样，JVM才有机会让锁停留在更轻量的状态，你的程序也就跑得更顺了。