本篇文章是第二篇，聚焦分析偏向锁延迟策略：

1. 什么是延迟偏向

2. 为什么需要延迟偏向

3. 延迟偏向机制是怎样的

4. 延迟偏向对锁膨胀的影响及证明

5. 从Hotspot源码角度证明

 

内容有点多，分两篇发。

 

01

是什么

 

什么是偏向延迟呢？见名知意：偏向锁就算是开启的，也不是马上就可以用的，中间有个延时。

 

对应的JVM参数是BiasedLockingStartupDelay，默认是4秒，可通过-XX:BiasedLockingStartupDelay修改

 

 

02

为什么

 

不知道大家在看到JVM中有偏向延迟这个机制的时候，脑海中有没有冒出这么几个问题：1、为什么要搞个偏向延迟？2、这个延时是从什么时候开始计算的？从JVM启动时吗？

 

为什么要设计

 

先回答第一个问题。这个问题的答案在网上有很多版本，最权威的答案就是这段注释。翻译过来就是说：这是一个启动时间回归的解决方案。说人话就是这样做，JVM启动可以更快。

 

 

为什么会更快呢？按照注释的说法：因为JVM在启动期间会采取大量安全点来消除偏差。这跟偏向锁有啥关系？说下我的理解哈，不一定是JVM工程师设计此的初衷。安全点大家应该是很熟悉了，启用安全点会带来STW。而偏向锁的撤销与重偏向判断，也是需要启用安全点的，因为需要扫描所有线程的虚拟机栈，需要内存静止才能保证结果准确。而JVM在启动期间用到的锁，包括初始化很多类的过程中用的锁，都会经过偏向锁逻辑，如果没有偏向延迟，就会带来更多的STW，导致JVM启动时间过长。

 

多说一句，有点不好理解：启动期间启用安全点消除偏差是一种先行发生策略，是为了保证启动期间有互动的多个线程的业务先后顺序。跟为了追求低延时数据同步插入内存屏障触发即时回写内存是差不多的思想。

 

延时何时计算

 

看下上面的代码，如果有延时，就创建一个任务。偏向延迟就是在这个任务中完成的，是由WatcherThread执行的，延迟偏向以后，WatcherThread执行到任务的task方法，创建一个VM_Operation丢入VMThread的任务池队列，等待VMThread执行。如果木有延时，就很直接了，创建一个VM_Operation丢人VMThread的任务池队列，等待VMThread执行。

 

 

顺便吐槽下，这个延时实现相当复杂。总之，Hotspot源码里面，就没有简单的东西。作为局外人，有些地方，我是真的不解，为啥要搞那么复杂。比如偏向锁整个机制，也是复杂的一批。

 

那延时是从哪开始的呢？是WatcherThread执行到sleep方法开始的，因为计算剩余时间一定需要与当前时间进行对比。

 

void WatcherThread::run() {
    ……
    // Calculate how long it'll be until the next PeriodicTask work
    // should be done, and sleep that amount of time.
    int time_waited = sleep();
    ……
    PeriodicTask::real_time_tick(time_waited);
}

 

03

锁类型

 

synchronized对应的锁类型有这些：

1. 无锁

2. 偏向锁

3. 轻量级锁

4. 重量级锁

    

 

这些锁存储在哪个位置呢？对象头中。Java的每个对象，在JVM中的结构如图。Mark Word区域就是对象头。展开来就是上图的样子

 

04

对锁膨胀的影响

 

好的答案从好的问题开始。对于这个问题，咱们从这几个问题开始着手：

1. 延迟偏向之前创建的对象是什么锁

2. 延迟偏向之后创建的对象是什么锁

3. 创建的对象的锁是是如何被延迟偏向影响的。这个下篇讲

4. 延迟偏向之后，之前创建的对象持有的锁会被批量修改吗

5. 有或无延迟偏向，锁如何膨胀

 

延迟偏向之前创建的对象是无锁状态。细节下篇讲

 

 

延迟偏向之后创建的对象是未偏向的偏向锁。细节后面讲

 

 

延迟偏向之前创建的对象，延迟偏向后，是不会批量修改的。言外之意就是延迟偏向之前创建的对象是无锁，延迟偏向之后还是无锁。

 

 

延迟偏向之前是无锁，膨胀后不会经历偏向锁，会直接膨胀成轻量级锁

 

 

延迟偏向之后创建的对象是未偏向的偏向锁，经过synchronized就会变成偏向当前线程的偏向锁

 

 

关于synchronized的锁膨胀逻辑，后面写文章细讲。