JVM内部细节之二：偏向锁（Biased Locking）

在前面一片文章《JVM内部细节之一：synchronized关键字及实现细节》中已经提到过偏向锁的概念，在理解什么是偏向锁前必须先理解什么是轻量级锁（Lightweight Locking）。引入偏向锁是为了在无多线程竞争的情况下尽量减少不必要的轻量级锁执行路径，因为轻量级锁的获取及释放依赖多次CAS原子指令，而偏向锁只需要在置换ThreadID的时候依赖一次CAS原子指令（由于一旦出现多线程竞争的情况就必须撤销偏向锁，所以偏向锁的撤销操作的性能损耗必须小于节省下来的CAS原子指令的性能消耗）。下面看具体细节：

一、对象头中的Mark Word布局

在上一篇文章中所讨论的轻量级锁中在我参考的Paper中对于重量级锁的实现并没有通过状态位来表现而是直接通过在轻量级锁的Monitor Record中关联一个底层操作系统的互斥信号量来实现重量级锁的操作（并不影响我们理解JVM内部锁的运作过程），在偏向锁的处理过程中并不涉及重量级锁，我们这里只需要关心biasable和lightweight locked两种状态。在JDK1.6以后默认已经开启了偏向锁这个优化，我们可以通过在启动JVM的时候加上-XX:-UseBiasedLocking参数来禁用偏向锁（在存在大量锁对象的创建并高度并发的环境下禁用偏向锁能够带来一定的性能优化）。

二、偏向锁的获取过程（假设开启了偏向锁优化）：

（1）初始时对象处于biasable状态，并且ThreadID为0即biasable & unbiased状态（这里不讨论epoch和age）

（2）当一个线程试图锁住一个处于biasable & unbiased状态的对象时，通过一个CAS将自己的ThreadID放置到Mark Word中相应的位置，如果CAS操作成功进入第（3）步否则进入（4）步

（3）当进入到这一步时代表当前没有锁竞争，Object继续保持biasable状态，但是这时ThreadID字段被设置成了偏向锁所有者的ID，然后进入到第（6）步

（4）当前线程执行CAS获取偏向锁失败（这一步是偏向锁的关键），表示在该锁对象上存在竞争并且这个时候另外一个线程获得偏向锁所有权。当到达全局安全点（safepoint）时获得偏向锁的线程被挂起，并从偏向锁所有者的私有Monitor Record列表中获取一个空闲的记录，并将Object设置为LightWeight Lock状态并且Mark Word中的LockRecord指向刚才持有偏向锁线程的Monitor record，最后被阻塞在安全点的线程被释放，进入到轻量级锁的执行路径中，同时被撤销偏向锁的线程继续往下执行同步代码。

（5）当一个线程试图锁住一个处于biasable & biased并且ThreadID不等于自己的ID时，这时由于存在锁竞争必须进入到第（4）步来撤销偏向锁。

（6）运行同步代码块

二、偏向锁的解锁过程：

（1）偏向锁解锁过程很简单，只需要测试下是否Object上的偏向锁模式是否还存在，如果存在则解锁成功不需要任何其他额外的操作。

三、参考资料：

• Eliminating Synchronization-Related Atomic Operations with Biased Locking and Bulk Rebiasing