是否真的理解了偏向锁、轻量级锁、重量级锁（锁膨胀）、自旋锁、锁消除、锁粗化，知道重偏向吗？

最新推荐文章于 2022-07-09 21:41:12 发布

正在飞翔的猫

最新推荐文章于 2022-07-09 21:41:12 发布

阅读量2.9k

点赞数 4

分类专栏： Java 文章标签：优化 JAVA 锁

本文为博主原创文章，请尊重劳动成果，转载注明一下出处。

本文链接：https://blog.csdn.net/zq1994520/article/details/83998117

版权

Java 专栏收录该内容

13 篇文章 0 订阅

订阅专栏

知识准备：

在开始前，首先清楚系统PV信号机制

荷兰学者Dijkstra于1965年提出的信号机制是一种有效的进程同步与互斥工具。

1）整型信号与PV操作

信号量是一个整型变量，根据控制对象的不同被赋予不同的值。信号量分为如下两类：

（1）公用信号量。实现进程间的互斥，初值为1或资源的数目。

（2）私有信号量。实现进程间的同步，初值为0或某个正整数。

信号量 S的物理意义：S≥0表示某资源的可用数，若S<0，则其绝对值表示阻塞队列中等待该资源的进程数。

P操作的定义：S:=S-1，若S≥0，则执行P操作的进程继续执行；若S<0，则置该进程为阻塞状态（因为无可用资源），并将其插入阻塞队列。

V操作的定义：S:=S+1 ，若S>0，则执行V操作的进程继续执行；若S≤0，则从阻塞状态唤醒一个进程，并将其插入就绪队列，然后执行V操作的进程继续。

2）利用PV操作实现进程的互斥

令信号量mutex的初值为1，当进入临界区时执行P操作，退出临界区时执行V操作。

【例】将交通流量统计程序改写如下，实现P1 和P2间的互斥。

L1:if 有车通过   then
    begin
        P(mutex)
        COUNT:=COUNT + 1;
        V(mutex)
    end
    GOTO L1;





L2:
    begin
        P(mutex)
        PRINT COUNT;
        COUNT:=0;
        V(mutex)
    end
    GOTO L2;

3）利用PV操作实现进程的同步

【例】生产者进程P1 不断地生产产品送入缓冲区，消费者进程P2不断地从缓冲区中取产品消费。

上文摘自《软件设计师教程》一书

从上面我们可以看出，mutex值表示范围是整数，用大于等于2 个的值表示进程不同状态。

如果现在我们只关心当前资源是否处于占用状态，也就是mutex的值只有2个值来表示有现成占用和无线程占用，我不关心到底有多少资源处于占用状态，因为我不是为了替换上面的PV操作，而是在没有多线程竞争的条件的前提下，减少PV操作这种互斥量产生的性能消耗。

我这儿自己定义一下含义

mutex={true,false}

true=有别的线程请求获取资源，也就是想要获取竞争

false=没有别的线程来参与竞争

说到这儿，可能有点模糊，为什么这样就能减少了？

从前面我们知道V操作的功能一个是信号量mutex+1，还有一个就是唤醒处于等待的线程。这儿我们假设如果线程竞争不大，始终只有一个线程在做PV操作，整个程序里面，获取该资源的就只有一个，用V操作取通知所有的等待队列，但是队列为空，这个完全就是空操作。那么这儿的V操作是可以不执行的。换而言之，P操作的前面可以添加一个判断，这个判断是“检测mutex的值是否为false，判断当前线程是否有线程处于等待状态，如果是就执行原来的PV操作，如果不是，就不执行PV操作，直接对资源做操作”，这个是偏向锁的想法。

1）轻量级锁

下面来看JVM中对于轻量级锁怎么实现的：

摘自《深入理解Java虚拟机》一书

轻量级锁是JDK1.6之中加入的新型锁机制，它名字中的“轻量级”是相对于使用操作系统互斥量来实现的传统锁而言的，因此传统的锁机制就称为“重量级”锁。首先需要强调一点的是，轻量级锁并不是用来代替重量级锁的，它的本意是在没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消耗。

要理解轻量级锁，以及后面会讲到的偏向锁的原理和运作过程，必须从HotSpot虚拟机的对象（对象头部分）的内存布局开始介绍。HotSpot虚拟机的对象头（Object Header）分为两部分信息，第一部分用户存储对象自生的运行时数据，如哈希码（HashCode）、GC分代年龄等，这部分数据的长度在32位和64位的虚拟机中分别为32bit和64bit，官方称它为“Mark Work”，他是实现轻量级锁和偏向锁的关键。另一部分用户存储指向犯法去对象类型数据的指针，如果是数组对象的话，还会有一个额外的部分用于存储数组长度。

对象头信息是与对象自身定义的数据无关的额外春初成本，考虑到虚拟机的空间效率，Mark Word被设计成一个非固定的数据结构一边在技校的空间内存储尽量多的信息，它会根据对象的状态服用自己的存储空间。例如，在32位的HotSpot虚拟机中对象未被锁定的状态下，Mark Word的32bit空间中的25bit用于存储对象哈希吗（HashCode），4bit用于存储对象分代年龄，2bit用于存储锁标志位，1bit固定为0，在其他状态（轻量级锁定、重量级锁定、GC标记、可偏向）下对象的存储内容见下表。

存储内容	标志位	是否偏向	状态
对象Hash值、对象分代年龄	01	0	未锁定
指向锁记录的指针	00	0	轻量级锁定
指向重量级锁的指针	10	0	膨胀（重量级锁定）
空，不记录信息	11	0	GC标记
偏向线程ID、偏向时间戳、对象分代年龄	01	1	可偏向

加锁过程

在代码进入同步块的时候，如果此同步对象没有被锁定（锁标志位为“01”状态），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的Mark Word的拷贝（官方把这份拷贝加了一个Displaced前缀，即Displaced Mark Word），这时候线程堆栈与对象头的状态如下图所示。

然后，虚拟机将使用CAS操作尝试将对象的Mark Word更新为指向Lock Record的指针。如果这个更新动作成功，那么这个线程就拥有了该对象的锁，并且对象Mark Word的锁标志位（Mark Word的最后两个Bits）将转变为“00”（图中写的01是错误的），即表示此对象处于轻量级锁定状态，这时候线程堆栈与对象头的状态如下图所示。

如果这个更新操作失败了，虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行，否则说明这个锁对象已经被其他线程抢占了。如果有两条（包括拥有该锁的线程，没有获取锁的线程只有一条）以上的线程争用同一个锁，那轻量级锁就不再有效，要膨胀为重量级锁，锁标志的状态值变为“10”（age后面的变成·10），Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。

解锁过程

解锁过程也是通过CAS操作来进行的，如果对象的Mark Word仍然指向着线程的锁记录，那就用CAS操作把对象当前的Mark Word和线程中复制的Displaced Mark Word替换回来，如果替换成功，整个同步过程就完成了。如果替换失败，说明有其他线程尝试过获取该锁，那就要在释放锁的同时，唤醒被挂起的线程（失败的定义应该是标志位是否00吧）。

小结

轻量级锁能提升程序同步性能的依据是“对于绝大部分的锁，在整个同步周期内都是不存在竞争的”，这是一个经验数据。如果没有竞争，轻量级锁使用CAS操作避免了使用互斥量的开销，但如果存在锁竞争，除了互斥量的开销外，还额外发生了CAS操作，因此在有竞争的情况下，轻量级锁会比传统的重量级锁更慢。

注：上面括号的是我自己理解添加的，斟酌。

2）偏向锁：

上面的假设就是java虚拟机中 “轻量级锁”的想法，“轻量级锁”是通过使用CAS来替换monitor对象，而“重量级锁”的实现就是通过PV操作来的。

下面来看JVM中对于偏向锁怎么说明的：

摘自《深入理解Java虚拟机》一书

目的是消除数据在无竞争情况下的同步原语，进一步提高程序的运行性能。如果说轻量级锁是在无竞争的情况下使用CAS操作去消除同步使用的互斥量，那偏向锁就是在无竞争的情况下把整个同步都消除掉，连CAS操作都不做了。

偏向锁会偏向于第一个获得它的线程（Mark Word中的偏向线程ID信息），如果在接下来的执行过程中，该锁没有被其他的线程获取，则持有偏向锁的线程将永远不需要再进行同步。

假设当前虚拟机启用了偏向锁（启用参数-XX:+UseBiasedLocking，JDK 1.6的默认值），当锁对象第一次被线程获取的时候，虚拟机将会把对象头中的标志位设为“01”，即偏向模式。同时使用CAS操作把获取到这个锁的线程的ID记录在对象的Mark Word之中，如果CAS操作成功，持有偏向锁的线程以后每次进入这个锁相关的同步块时，虚拟机都可以不再进行任何同步操作（例如Locking、Unlocking及对Mark Word的Update等）。　　

当有另外一个线程去尝试获取这个锁时，偏向模式就宣告结束。根据锁对象目前是否处于被锁定的状态，撤销偏向（Revoke Bias）后恢复到未锁定（标志位为“01”）或轻量级锁定（标志位为“00”）的状态，后续的同步操作就如上面介绍的轻量级锁那样执行。偏向锁、轻量级锁的状态转化及对象Mark Word的关系如下图。

对于上面的文字描述和那个图，是否有疑问，我在看的时候也有疑问，图上面的意思是可偏向有关的状态有三个，一个是未偏向、未锁定但是可偏向的对象；一个是已偏向的锁定的对象；一个是已偏向未锁定的对象。为什么还有重偏向？我们再来看Mark Word的结构，看看那个锁定和未锁定从哪儿得到的。

锁状态	25bit		4bit	1bit	2bit
锁状态	23bit	2bit	4bit	是否偏向锁（是否禁用偏向）	锁标志位
无锁态	对象的hashCode		分代年龄	0	01
轻量级锁	指向栈中锁记录的指针				00
重量级锁	指向互斥量（重量级锁）的指针				10
GC标记	空				11
偏向锁	线程ID	Epoch	分代年龄	1	01

从表中我们没有看到可以标志可偏向的锁定和未锁定的标志位，那为什么上面的图这么画。还有上文的文字描述中加黑的部分表明了Mark Word第一次CAS操作后不会再update，那这个不是和图矛盾吗？

针对这个疑惑，我再下篇博文详细解释了轻量级锁、偏向锁、重量级锁

这儿可能还是不懂，那个为什么有可重偏向这个含义呢。再看一下https://pdfs.semanticscholar.org/edf9/54412a9b1ce955bea148199f325759779540.pdf这篇文章。

从中终于知道了原来偏向不单单是“一个时间段每一时刻都是同一个线程获取同一个资源”，还有一种情况是“在一个时间段内每一个时刻都是只有一个线程使用同一个对象，但是不是每一时刻都是同一个线程“。后面的是重偏向，而那个可重偏向就是批量重偏的（这个他把使用的范围扩大了，因为如果一个对象一直是一个线程在使用，没有存在并发，但是每次都是不同线程来使用的，那使用轻量级锁就没有必要，可以省略掉V操作了）。

下面再来描述一下过程

前面轻量级锁是考虑到每次都只有一个线程去获取锁，其中有可能是在不同的时间段获取锁对象的线程是不同的，也有可能是连续不同的时间段获取锁对象的线程是相同的。呵呵，这个前面的我们没有办法，如果是后面的那种情况，显然每次对锁对象做lock和unlock和Mark Word的更新是不需要的，我们只需要做第一次，既然没有其它的线程来和我争锁，我就不更新unlock和更新Mark Word了，也就是这个锁的对象在没有其它线程来和这个线程竞争的时间段中一直处于lock的状态，而且Mark Word的标志位一直是01（可偏向）。这样我们节省了什么操作呢？如果按照轻量级锁的做法，第一次在进入synchronized中，用CAS更新括号里面的对象Mark Word，如果成功，继续下面的代码，当synchronized里面的操作执行完成，再用CAS把对象的Mark Word更新回来；第二次在进入synchronized中，重复第一次的操作，每次都会lock和unlock，还会更新Mark Word的状态。偏向锁只在第一次进入synchronized的代码块用CAS更新括号里面的对象Mark Word，会多个线程ID，确认偏向成功并且在synchronized里面的操作执行完成后它将不再unlock和替换回Mark Word等，看起来synchronized这个代码整个就被消除了，只会在开始进入的时候判断Mark Word的线程ID是否是我的。

PS：上面有两个同步，其中加黑体的同步不是程序代码块的同步，这儿是 Java内存模型里面的内存交互擦操作中的，不懂可以查查资料，过程有8个操作，分别是lock，unlock、read、load、use、assign、store、write，这儿不详细赘述了。我对于那个图自从产生了疑问，百度了n次，看了很多人的中文博客，最后没办法，只有google了，最后找到https://pdfs.semanticscholar.org/edf9/54412a9b1ce955bea148199f325759779540.pdf这个论文，哎，这就是差距，想中国的大学论文，还有网上那么多错误的东西，这就是差距啊，中国人的功利心太强了，还有就是某度了。

3）自旋锁：

摘自《深入理解Java虚拟机》一书

互斥同步对性能最大的影响是阻塞的实现，挂起线程和恢复线程的操作都需要转入内核态中完成，这些操作给系统的并发性能带来了很大的压力。而在很多应用上，共享数据的锁定状态只会持续很短的一段时间。若实体机上有多个处理器，能让两个以上的线程同时并行执行，我们就可以让后面请求锁的那个线程原地自旋（不放弃CPU时间），看看持有锁的线程是否很快就会释放锁。为了让线程等待，我们只须让线程执行一个忙循环（自旋），这项技术就是自旋锁。

如果锁长时间被占用，则浪费处理器资源，因此自旋等待的时间必须要有一定的限度，如果自旋超过了限定的次数仍然没有成功获得锁，就应当使用传统的方式去挂起线程了（默认10次）。

JDK1.6引入自适应的自旋锁：自旋时间不再固定，由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而它将允许自旋等待持续相对更长的时间。

小结：

对于自旋锁、轻量级锁、偏向锁、重量级锁之间存在范围大小的排序，其中考虑到并发和是否禁用。

重量级锁 > 自旋锁 > 轻量级锁 > 偏向锁

用文字描述一下：

自旋锁：竞争不大的情况，有量竞争

重量级锁：任何情况

轻量级锁：一个时间段（整个同步周期内）中只有一个线程请求获取锁。

偏向锁：一个时间段中每一个时刻都是一个线程请求获取锁（包括所有时间端都是一个线程和不同的线程）。

4）锁消除：

摘自《深入理解Java虚拟机》一书

锁消除是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。锁消除的主要判定依据来源于逃逸分析的数据，如果判断在一段代码中，堆上的所有数据都不会逃逸出去从而被其它线程访问到，那就可以把它们当做栈上数据对待，认为它们是线程私有的，同步加锁自然就无法进行。

也许读者会有疑问，变量是否逃逸，对于虚拟机来需要使用数据流分析来确定，但是程序员自己应该是清楚的，怎么会在明知道不存在数据征用的情况下要求同步呢？答案是有许多同步措施并不是程序员自己加入的，同步的代码在Java程序中的普遍程度也许炒股了大部分读者的想象。看下面的代码

public String concatString(String  s1, String s2, String s3){

    return s1 + s2 +  s3;
}

我们也知道，由于String是一个不可变的类，对于字符串的连接操作总是通过生成新的String对象来进行的，因此Javac编译器会对String连接做自动优化。在JDK1.5之前，会转化为StringBuffer对象的连接append()操作，在JDK1.5及以后的版本中，会转化为StringBuilder对象的连续append()操作，即下面的代码

public String concatString(String s1, String  s2, String s3) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    sb.append(s3);
    return  sb.toString();
}

每个StringBuffer.append()方法中都有一个同步块，锁就是sb对象。虚拟机观察变量sb，很快就会发现它的动态作用域被限制在concatString()方法内部。也就是说，sb的所有引用永远不会“逃逸”到concatString()方法之外，其它线程无法访问到它，因此，虽然这里有锁，但是可以被安全地消除掉，在即时编译之后，这段代码就会互虐掉所欲的同步而直接执行。