> 大家好，我是[王有志](https://flowus.cn/chang/share/fa5ee5c8-bbd8-4a82-a31e-c6be478f44bc)，欢迎和我聊技术，聊漂泊在外的生活。快来加入我们的Java提桶跑路群：[共同富裕的Java人](https://flowus.cn/chang/share/c864e259-7629-42ac-84ea-6c4f509adfa8)。

鸽了这么久是给自己找到了冠冕堂皇的理由--**羊了**。说实话发烧那几天真的很难受，根本不想下床，完成日常工作都已经用尽了全部的力气，根本没精力写文章。

言归正传，今天我们继续学习`synchronized`的升级过程，目前只剩下最后一步了：轻量级锁->重量级锁。

通过今天的内容，希望能帮助大家解答[synchronized都问啥？](https://mp.weixin.qq.com/s/I9wMn-vtISV7YpT3b4ZGzg)中除锁粗化，锁消除以及Java 8对`synchronized`的优化外全部的问题。

## 获取重量级锁

[从源码揭秘偏向锁的升级 ](https://mp.weixin.qq.com/s/bLT3r3le-tAGaC89nmyuYA)最后，看到[synchronizer#slow_enter](https://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/share/runtime/synchronizer.cpp#l339)如果存在竞争，会调用`ObjectSynchronizer::inflate`方法，进行轻量级锁的升级（膨胀）。

**Tips**：

```C++
void ObjectSynchronizer::slow_enter(Handle obj, BasicLock* lock, TRAPS) {
  ......
  ObjectSynchronizer::inflate(THREAD, obj(), inflate_cause_monitor_enter)->enter(THREAD);
}
```

通过`ObjectSynchronizer::inflate`获取重量级锁ObjectMonitor，然后执行`ObjectMonitor::enter`方法。

**Tips**：

- [关于线程你必须知道的8个问题（中）](https://mp.weixin.qq.com/s/tmjEbdst3Otz_Ls3aG1exw)中提到过该方法;

- 问题是锁升级（膨胀），但重点不在`ObjectSynchronizer::inflate`，因此代码分析放在[重量级锁源码分析](https://mp.weixin.qq.com/s/2Clag9c5i24n-Y60VbkTrw)中。

### 锁的结构

了解`ObjectMonitor::enter`的逻辑前，先来看[ObjectMonitor](https://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/share/runtime/objectMonitor.hpp)的结构：

```C++
class ObjectMonitor {
  private:
    // 保存与ObjectMonitor关联Object的markOop
    volatile markOop   _header;
    // 与ObjectMonitor关联的Object
    void*     volatile _object;
  protected:
    // ObjectMonitor的拥有者
    void *  volatile _owner;
    // 递归计数
    volatile intptr_t  _recursions;
    // 等待线程队列，cxq移入/Object.notify唤醒的线程
    ObjectWaiter * volatile _EntryList;
  private:
    // 竞争队列
    ObjectWaiter * volatile _cxq;
    // ObjectMonitor的维护线程
    Thread * volatile _Responsible;
  protected:
    // 线程挂起队列（调用Object.wait）
    ObjectWaiter * volatile _WaitSet;
}
```

`_header`字段存储了Object的markOop，为什么要这样？因为**锁升级后没有空间存储Object的markOop了，存储到_header中是为了在退出时能够恢复到加锁前的状态**。

![](http://img.blog.itpub.net/blog/2023/07/12/9298742a67739386.png?x-oss-process=style/bb)

**Tips**：

- 实际上[basicLock](https://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/share/runtime/basicLock.hpp)也存储了对象的markOop；

- `EntryList`中等待线程来自于`cxq`移入，或`Object.notify`唤醒但未执行。

### 重入的实现

[objectMonito#enter](https://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/share/runtime/objectMonitor.cpp#l265)方法可以拆成三个部分，首先是**竞争成功或重入的场景**：

```C++
// 获取当前线程Self
Thread * const Self = THREAD;

// CAS抢占锁，如果失败则返回_owner
void * cur = Atomic::cmpxchg(Self, &_owner, (void*)NULL);

if (cur == NULL) {
  // CAS抢占锁成功直接返回
  return;
}

// CAS失败场景
// 重量级锁重入
if (cur == Self) {
  // 递归计数+1
  _recursions++;
  return;
}

// 当前线程是否曾持有轻量级锁
// 可以看做是特殊的重入
if (Self->is_lock_owned ((address)cur)) {
  // 递归计数器置为1
  _recursions = 1;
  _owner = Self;
  return;
}
```

重入和升级的场景中，都会操作`_recursions`。`_recursions`记录了进入ObjectMonitor的次数，解锁时要经历相应次数的退出操作才能完成解锁。

### 适应性自旋

以上都是成功获取锁的场景，那么产生竞争导致失败的场景是怎样的呢？来看[适应性自旋](https://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/share/runtime/objectMonitor.cpp#l295)的部分，**ObjectMonitor倒数第二次对“轻量”的追求**：

```C++
// 尝试自旋来竞争锁
Self->_Stalled = intptr_t(this);
if (Knob_SpinEarly && TrySpin (Self) > 0) {
  Self->_Stalled = 0;
  return;
}
```

[objectMonitor#TrySpin](https://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/share/runtime/objectMonitor.cpp#l1869)方法是对**适应性自旋**的支持。Java 1.6后加入，移除默认次数的自旋，将自旋次数的决定权交给JVM。

**JVM根据锁上一次自旋情况决定，如果刚刚自旋成功，并且持有锁的线程正在执行，JVM会允许再次尝试自旋。如果该锁的自旋经常失败，那么JVM会直接跳过自旋过程**。

**Tips**：

- 适应性自旋的原码分析放在了[重量级锁源码分析](https://mp.weixin.qq.com/s/2Clag9c5i24n-Y60VbkTrw)中；

- [objectMonitor#TryLock](https://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/share/runtime/objectMonitor.cpp#l424)非常简单，关键技术依旧是CAS。

### 互斥的实现

到目前为止，无论是CAS还是自旋，都是偏向锁和轻量级锁中出现过的技术，为什么会让ObjectMonitor背上“重量级”的名声呢？

最后是竞争失败的场景：

```C++
// 此处省略了修改当前线程状态的代码
for (;;) {
  EnterI(THREAD);
}
```

实际上，进入[ObjectMonitor#EnterI](https://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/share/runtime/objectMonitor.cpp#l442)后也是先尝试“轻量级”的加锁方式：

```C++
void ObjectMonitor::EnterI(TRAPS) {
  if (TryLock (Self) > 0) {
    return;
  }

if (TrySpin (Self) > 0) {
    return;
  }
}
```

接来下是重量级的真正实现：

```C++
// 将当前线程（Self）封装为ObjectWaiter的node
ObjectWaiter node(Self);
Self->_ParkEvent->reset();
node._prev   = (ObjectWaiter *) 0xBAD;
node.TState  = ObjectWaiter::TS_CXQ;

// 将node插入到cxq的头部
ObjectWaiter * nxt;
for (;;) {
  node._next = nxt = _cxq;
  if (Atomic::cmpxchg(&node, &_cxq, nxt) == nxt)
    break;

// 为了减少插入到cxq头部的次数，试试能否直接获取到锁
  if (TryLock (Self) > 0) {
    return;
  }
}
```

逻辑一目了然，封装[ObjectWaiter](https://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/share/runtime/objectMonitor.hpp#l42)对象，并加入到`cxq`队列头部。接着往下执行：

```C++
// 将当前线程（Self）设置为当前ObjectMonitor的维护线程（_Responsible）
// SyncFlags的默认值为0，可以通过-XX:SyncFlags设置
if ((SyncFlags & 16) == 0 && nxt == NULL && _EntryList == NULL) {
  Atomic::replace_if_null(Self, &_Responsible);
}

for (;;) {
  // 尝试设置_Responsible
  if ((SyncFlags & 2) && _Responsible == NULL) {
    Atomic::replace_if_null(Self, &_Responsible);
  }
  // park当前线程
  if (_Responsible == Self || (SyncFlags & 1)) {
    Self->_ParkEvent->park((jlong) recheckInterval);  
    // 简单的退避算法，recheckInterval从1ms开始
    recheckInterval *= 8;
    if (recheckInterval > MAX_RECHECK_INTERVAL) {
      recheckInterval = MAX_RECHECK_INTERVAL;
    }
  } else {
    Self->_ParkEvent->park();
  }

// 尝试获取锁
  if (TryLock(Self) > 0)
    break;
  if ((Knob_SpinAfterFutile & 1) && TrySpin(Self) > 0)  
      break;

if (_succ == Self)
    _succ = NULL;
}
```

逻辑也不复杂，不断的`park`当前线程，被唤醒后尝试获取锁。需要关注`-XX:SyncFlags`的设置：

- 当`SyncFlags == 0`时，`synchronized`直接挂起线程；

- 当`SyncFlags == 1`时，`synchronized`将线程挂起指定时间。

**前者是挂起，需要被其它线程唤醒，而后者挂起指定的时间后自动唤醒**。

**Tips**：[关于线程你必须知道的8个问题（中）](https://mp.weixin.qq.com/s/tmjEbdst3Otz_Ls3aG1exw)聊到过`park`和`parkEvent`，底层是通过`pthread_cond_wait`和`pthread_cond_timedwait`实现的。

## 释放重量级锁

释放重量级锁的源码和注释非常长，我们省略大部分内容，只看关键部分。

### 重入锁退出

我们知道，重入是不断增加`_recursions`的计数，那么退出重入的场景就非常简单了：

```C++
void ObjectMonitor::exit(bool not_suspended, TRAPS) {
  Thread * const Self = THREAD;

// 第二次持有锁时，_recursions == 1
  // 重入场景只需要退出重入即可
  if (_recursions != 0) {
    _recursions--;
    return;
  }
  .....
}
```

不断的减少`_recursions`的计数。

### 释放和写入

JVM的实现中，当前线程是锁的持有者且没有重入时，**首先会释放自己持有的锁，接着将改动写入到内存中，最后还肩负着唤醒下一个线程的责任**。先来看释放和写入内存的逻辑：

```C++
// 置空锁的持有者
OrderAccess::release_store(&_owner, (void*)NULL);

// storeload屏障，
OrderAccess::storeload();

// 没有竞争线程则直接退出
if ((intptr_t(_EntryList)|intptr_t(_cxq)) == 0 || _succ != NULL) {
  TEVENT(Inflated exit - simple egress);
  return;
}
```

`storeload`屏障，对于如下语句：

```Shell
store1;
storeLoad;
load2
```

保证`store1`指令的写入在`load2`指令执行前，对所有处理器可见。

**Tips**：`volatile`中详细解释内存屏障。

### 唤醒的策略

执行释放锁和写入内存后，只需要唤醒下一个线程来“交接”锁的使用权。但是有两个“等待队列”：`cxq`和`EntryList`，该从哪个开始唤醒呢？

Java 11前，根据`QMode`来选择不同的策略：

- `QMode == 0`，默认策略，将`cxq`放入`EntryList`；

- `QMode == 1`，翻转`cxq`，并放入`EntryList`；

- `QMode == 2`，直接从`cxq`中唤醒；

- `QMode == 3`，将`cxq`移入到`EntryList`的尾部；

- `QMode == 4`，将`cxq`移入到`EntryList`的头部。

不同的策略导致了不同的唤醒顺序，现在你知道为什么说`synchronized`是非公平锁了吧？

[objectMonitor#ExitEpilog](https://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/share/runtime/objectMonitor.cpp#l1282)方法就很简单了，调用的是与`park`对应的`unpark`方法，这里就不多说了。

**Tips**：[Java 12的objectMonitor](https://hg.openjdk.java.net/jdk-updates/jdk12u/file/390566f1850a/src/hotspot/share/runtime/objectMonitor.cpp#l897)移除了`QMode`，也就是说只有一种唤醒策略了。

## 总结

我们对重量级锁做个总结。`synchronized`的重量级锁是`ObjectMonitor`，它使用到的关键技术有**CAS和park**。相较于[mutex#Monitor](https://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/share/runtime/mutex.hpp#l82)来说，它们的本质相同，对park的封装，但`ObjectMonitor`是做了大量优化的复杂实现。

我们看到了重量级锁是如何实现重入性的，以及唤醒策略导致的“不公平”。那么我们常说的`synchronized`保证了原子性，有序性和可见性，是如何实现的呢？

大家可以先思考下这个问题，下篇文章会做一个全方位的总结，给`synchronized`收下尾。

---

好了，今天就到这里了，Bye~~

ITPub博客

什么是synchronized的重量级锁？

最新文章