锁的升级打怪：通俗易懂讲解偏向锁、轻量级锁和重量级锁

Love The Way You Lie 2021-06-10 20:38 412阅读 0赞

PART0：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o2OTE4Mzc4Nw_size_16_color_FFFFFF_t_70][]

**PART1：**

首先通过一个小例子来解释一下三种锁的区别：

假如家里只有一个碗，当我自己在家时，没有人会和我争碗，这时即为偏向锁状态

当我和女朋友都在家吃饭时，如果女朋友不是很饿，则她会等我吃完再用我的碗去吃饭，这就是轻量级锁状态

当我和女朋友都很饿的时候，这时候就会去争抢这唯一的一个碗(贫穷的我)吃饭，这就是重量级锁状态

**PART2：**

我是一个线程，生活在JVM（Java虚拟机）中， 这一段日子过得有些无聊，整个世界似乎只有这一个人，天天忙着执行代码，想休息一下都很难。

我听说人类写的代码中有些特殊的地方，叫做**临界区**，比如synchronized修饰的方法或者代码块，他们非常神奇，在同一时刻JVM老大只允许一个线程进入执行。

实际上，老大设置了一把锁，抢到了这把锁就可以执行，否则只能阻塞，等待别人释放锁。

老大说，阻塞就是不用干活了，老老实实地等着就行。

竟然还有这等美事！ 赶紧让我阻塞一次吧。

可是老大又说：“每次设置锁我都得和操作系统打交道，请他在内核中维护一个什么Mutex（互斥量）的东西，他还得把你们这些线程阻塞，切换，这可是一笔巨大的费用啊，所以这些锁还是少用为妙。”

我运气也不好，我不知道执行了多少代码，调用了多少函数，竟然一次也没遇到临界区!

我想也许这个程序员编程时不小心，没有考虑多线程并发的情况； 也有可能是这些程序大部分都是无状态的，多少个线程执行都没有问题。

于是我只好一直执行下去， 不知道过了多少天，我激动地发现，一个synchronized修饰的代码块终于出现了：

Account account = ...

synchronized(**account**)\{

...临界区的代码...

偏向锁

我满心期望别的线程已经进入了代码块，那我就可以阻塞、休息。

即使没有其他线程进入临界区，老大为我申请锁， 也得和操作系统协商什么互斥量，从用户态进入核心态，再从核心态返回用户态，总要花些功夫吧。

可是老大根本没有去找操作系统， 只是看了看这个account对象的所谓“对象头”，其中有个叫做Mark Word的东西，似乎是个什么数据结构， 里边有几个标识位，还有其他数据。

![format_png][]

老大随手使用CAS操作把我的线程ID记录到了这个Mark Word当中，修改了标识位，然后告诉我说： 可以了，你现在拥有这把锁了，进去执行代码吧。

![format_png 1][]

我惊奇地说：“老大你不和操作系统协商设置Mutex了？”

老大说：“不用了，你看现在就你一个线程进入了这个代码块，我只要记录下你的线程ID，就表示你拥有这把锁了，不用操作系统介入。”

我获得了锁，开始执行被synchronized包裹的代码块。

等到我第二次执行到这个synchronized的时候，老大只是看了一眼锁对象account的Mark Word就说：“你的线程ID还在，还持有着这个对象的锁，进入临界区执行吧。”

我连喘口气的机会都没有，只好继续执行。

老大说，这叫偏向锁，在没有别的线程竞争的时候，一直偏向我，可以让我一直执行下去。

我是多么期盼来一个新的线程来和我竞争啊！

轻量级锁

很快，机会就来了。

另外一个线程0x3704也要进入这个代码块执行，但是锁对象account 保存的是我的线程ID，他是没法进入临界区的。

我心想，我们两个至少得有一个进入阻塞状态，休息一会儿了。

但是老大还是不去操作系统协商，只是说： 我把这个偏向锁升级一下，变成一个轻量级的锁吧。

老大把锁对象account恢复成无锁状态，在我们俩的栈帧中各自分配了一个空间，叫做Lock Record， 把锁对象account的Mark Word在我们俩这里各自复制了一份，叫做Displaced Mark Word， 这名字真奇怪。

然后把我的Lock Record的**地址**使用CAS放到了Mark Word当中，并且把锁标志位改为00， 这其实就意味着我也已经获得了这个轻量级的锁了，可以继续进入临界区执行。

![format_png 2][]

0x3704没有获得锁，但还是不阻塞，老大让他自旋几次，等待一会儿。

等到我退出临界区，释放锁的时候，需要把这个Displaced markd word 使用CAS复制回去。接下来他就可以加锁了。

**我们两个交替着进入临界区，执行这段代码**，相安无事，很少出现真正的竞争。

即使是出现了竞争，想获得锁的线程只要自旋几次，等待一会儿，锁就可能释放了。

很明显，如果没有竞争或者轻度的竞争，轻量级锁仅仅使用CAS操作和Lock record就避免了重量级互斥锁的开销，对JVM老大来说，确实是个好主意。

重量级锁

轻量级锁运行得挺好，我还是没有机会休息，终于有这么一天，0x3704 正在持有锁，在临界区辛苦地执行代码。 我自旋了好多次，0x3704还是没释放锁。 这时候JVM老大说： 自旋次数太多了，太浪费CPU了，接下来升级为重量级锁！

这个重量级锁需要操作系统的帮忙，依赖操作系统底层的Mutex Lock。

只见老大创建了一个monitor 对象， 把这个对象的地址更新到了Mark word当中。

锁升级了！

![format_png 3][]

由于0x3704还在持有锁运行，而我终于进入了梦寐以求的状态：阻塞！ 终于可以休息一下了！

仔细一想，老大煞费心机地设置了偏向锁和轻量级锁，就是为了避免阻塞，避免操作系统的介入， 这两种锁无非就是针对这两种情况：

偏向锁： 通常只有一个线程在临界区执行

轻量级锁： 可以有多个线程交替进入临界区，在竞争不激烈的时候，稍微自旋等待一下就能获得锁。

至于重量级锁，也是我最为期待的锁，那就是出现了激烈的竞争，只好让我们去阻塞休息了。

\-END-

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3o2OTE4Mzc4Nw_size_16_color_FFFFFF_t_70]: /images/20210527/203f59879a844a4e89ccfef5c7fe80fe.png
[format_png]: /images/20210527/2cd5395618cf47d3aad44795bba97464.png
[format_png 1]: /images/20210527/e93cf1c1524c42cb9d3ceb3373065f53.png
[format_png 2]: /images/20210527/57ced6f4e01b4aaea3ab455740e2d024.png
[format_png 3]: /images/20210527/24868fdbaec34a3087ac1c43b05d503e.png