深入了解Java Synchronized锁升级过程

前言

首先，synchronized 是什么？我们需要明确的给个定义——同步锁，没错，它就是把锁。

可以用来干嘛？锁，当然当然是用于线程间的同步，以及保护临界区内的资源。我们知道，锁是个非常笼统的概念，像生活中有指纹锁、密码锁等等多个种类，那 synchronized 代表的锁具体是把什么锁呢？

答案是—— Java 内置锁。在 Java 中，每个对象中都隐藏着一把锁，而 synchronized 关键字就是激活这把隐式锁的把手（开关）。

先来简单了解一下 synchronized，我们知道其共有 3 种使用方式：

• 修饰静态方法：锁住当前 class，作用于该 class 的所有实例

• 修饰非静态方法：只会锁住当前 class 的实例

• 修饰代码块：该方法接受一个对象作为参数，锁住的即该对象

使用方法就不在这里赘述，可自行搜索其详细的用法，这不是本篇文章所关心的内容。

知道了 synchronized 的概念，回头来看标题，它说的锁升级到底是个啥？对于不太熟悉锁升级的人来说，可能会想：

所谓锁，不就是啪一下锁上就完事了吗？升级是个什么玩意？这跟打扑克牌也没关系啊。

对于熟悉的人来说，可能会想：

不就是「无锁 ==> 偏向锁 ==> 轻量级锁 ==> 重量级锁 」吗？

你可能在很多地方看到过上面描述的锁升级过程，也能直接背下来。但你真的知道无锁、偏向锁、轻量级锁、重量级锁到底代表着什么吗？这些锁存储在哪里？以及什么情况下会使得锁向下一个 level 升级？

想知道答案，我们似乎必须先搞清楚 Java 内置锁，其内部结构是啥样的？内置锁又存放在哪里？

答案在开篇提到过——在 Java 对象中。

那么现在的问题就从「内置锁结构是啥」变成了「Java 对象长啥样」。

对象结构

从宏观上看，Java 对象的结构很简单，分为三部分：

从微观上看，各个部分都还可以深入展开，详见下图：

接下来分别深入讨论一下这三部分。

对象头

从脑图中可以看出，其由 Mark Word、Class Pointer、数组长度三个字段组成。简单来说：

• Mark Word：主要用于存储自身运行时数据

• Class Pointer：是指针，指向方法区中该 class 的对象，JVM 通过此字段来判断当前对象是哪个类的实例

• 数组长度：当且仅当对象是数组时才会有该字段

Class Pointer 和数组长度没什么好说的，接下来重点聊聊 Mark Word。

Mark Word 所代表的「运行时数据」主要用来表示当前 Java 对象的线程锁状态以及 GC 的标志。而线程锁状态分别就是无锁、偏向锁、轻量级锁、重量级锁。

所以前文提到的这 4 个状态，其实就是 Java 内置锁的不同状态。

在 JDK 1.6 之前，内置锁都是重量级锁，效率低下。效率低下表现在

而在 JDK 1.6 之后为了提高 synchronized 的效率，才引入了偏向锁、轻量级锁。

随着锁竞争逐渐激烈，其状态会按照「无锁 ==> 偏向锁 ==> 轻量级锁 ==> 重量级锁 」这个方向逐渐升级，并且不可逆，只能进行锁升级，而无法进行锁降级。

接下来我们思考一个问题，既然 Mark Word 可以表示 4 种不同的锁状态，其内部到底是怎么区分的呢？（由于目前主流的 JVM 都是 64 位，所以我们只讨论 64 位的 Mark Word）接下来我们通过图片直观的感受一下。

（1）无锁

这个可以理解为单线程很快乐的运行，没有其他的线程来和其竞争。

（2）偏向锁

首先，什么叫偏向锁？举个例子，一段同步的代码，一直只被线程 A 访问，既然没有其他的线程来竞争，每次都要获取锁岂不是浪费资源？所以这种情况下线程 A 就会自动进入偏向锁的状态。

后续线程 A 再次访问同步代码时，不需要做任何的 check，直接执行（对该线程的「偏爱」），这样降低了获取锁的代价，提升了效率。

看到这里，你会发现无锁、偏向锁的 lock 标志位是一样的，即都是 01，这是因为无锁、偏向锁是靠字段 biased_lock 来区分的，0 代表没有使用偏向锁，1 代表启用了偏向锁。为什么要这么搞？你可以理解为无锁、偏向锁在本质上都可以理解为无锁（参考上面提到的线程 A 的状态），所以 lock 的标志位都是 01 是没毛病的。

PS：这里的线程 ID 是持有当前对象偏向锁的线程

（3）轻量级锁

但是，一旦有第二个线程参与竞争，就会立即膨胀为轻量级锁。企图抢占的线程一开始会使用自旋：

的方式去尝试获取锁。如果循环几次，其他的线程释放了锁，就不需要进行用户态到内核态的切换。虽然如此，但自旋需要占用很多 CPU 的资源（自行理解汽车空档疯狂踩油门）。如果另一个线程 一直不释放锁，难道它就在这一直空转下去吗？

当然不可能，JDK 1.7 之前是普通自旋，会设定一个最大的自旋次数，默认是 10 次，超过这个阈值就停止自旋。JDK 1.7 之后，引入了适应性自旋。简单来说就是：这次自旋获取到锁了，自旋的次数就会增加；这次自旋没拿到锁，自旋的次数就会减少。

（4）重量级锁

上面提到，试图抢占的线程自旋达到阈值，就会停止自旋，那么此时锁就会膨胀成重量级锁。当其膨胀成重量级锁后，其他竞争的线程进来就不会自旋了，而是直接阻塞等待，并且 Mark Word 中的内容会变成一个监视器（monitor）对象，用来统一管理排队的线程。

这个 monitor 对象，每个对象都会关联一个。monitor 对象本质上是一个同步机制，保证了同时只有一个线程能够进入临界区，在 HotSpot 的虚拟机中，是由 C++ 类 ObjectMonitor 实现的。

那么 monitor 对象具体是如何来管理线程的？接下来我们看几个 ObjectMonitor 类关键的属性：

• ContentionQueue：是个队列，所有竞争锁的线程都会先进入这个队列中，可以理解为线程的统一入口，进入的线程会阻塞。

• EntryList：ContentionQueue 中有资格的线程会被移动到这里，相当于进行一轮初筛，进入的线程会阻塞。

• Owner：拥有当前 monitor 对象的线程，即 —— 持有锁的那个线程。

• OnDeck：与 Owner 线程进行竞争的线程，同一时刻只会有一个 OnDeck 线程在竞争。

• WaitSet：当 Owner 线程调用 wait()  方法被阻塞之后，会被放到这里。当其被唤醒之后，会重新进入 EntryList 当中，这个集合的线程都会阻塞。

• Count：用于实现可重入锁，synchronized 是可重入的。

对象体

对象体包含了当前对象的字段和值，在业务中u l是较为核心的部分。

对齐字节

就是单纯用于填充的字节，没有其他的业务含义。其目的是为了保证对象所占用的内存大小为 8 的倍数，因为HotSpot VM 的内存管理要求对象的起始地址必须是 8 的倍数。

锁升级

了解完 4 种锁状态之后，我们就可以整体的来看一下锁升级的过程了。

线程 A 进入 synchronized 开始抢锁，JVM 会判断当前是否是偏向锁的状态，如果是就会根据 Mark Word 中存储的线程 ID 来判断，当前线程 A 是否就是持有偏向锁的线程。如果是，则忽略 check，线程 A 直接执行临界区内的代码。

但如果 Mark Word 里的线程不是线程 A，就会通过自旋尝试获取锁，如果获取到了，就将 Mark Word 中的线程 ID 改为自己的；如果竞争失败，就会立马撤销偏向锁，膨胀为轻量级锁。

后续的竞争线程都会通过自旋来尝试获取锁，如果自旋成功那么锁的状态仍然是轻量级锁。然而如果竞争失败，锁会膨胀为重量级锁，后续等待的竞争的线程都会被阻塞。

补充：Synchronized底层原理

Synchronized被编译后会生成monitorenter 和 monitorexit 指令。

在执行monitorenter时，会尝试获取对象的锁，如果锁的计数器为 0 则表示锁可以被获取，获取后将锁计数器设为 1 也就是加 1。

在执行 monitorexit 指令后，将锁计数器设为 0，表明锁被释放。如果获取对象锁失败，那当前线程就要阻塞等待，直到锁被另外一个线程释放为止。

Monitor是依赖于操作系统的mutex lock实现的，每当挂起或者唤醒1个线程都要切换操作系统内核态。这个操作是比较重量级的，在一些情况下甚至切换时间本身会超出线程执行任务的时间。

synchronized 修饰的方法并没有 monitorenter 指令和 monitorexit 指令，取得代之的确实是 ACC_SYNCHRONIZED 标识，该标识指明了该方法是一个同步方法。

EOF

其实偏向锁还有一个撤销的过程，也是有代价的，但相比于偏向锁带好的好处，是能够接受的。但我们这里重点的还是关注锁升级的具体逻辑和细节，关于锁升级的过程就聊到这里。

来源：https://juejin.cn/post/7072533669377736711