锁释放-获取的示例代码：

package com.lizba.p1;

/**

•  锁示例代码
  

• @Author: Liziba

• @Date: 2021/6/10 21:43

*/

public class MonitorExample {

int a = 0;

public synchronized void writer() { // 1;

a++;

《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享

// 2;

} // 3;

public synchronized void reader() { // 4;

int i = a; // 5;

System.out.println(i);

} // 6;

}

假设线程A执行writer()方法，随后线程B执行reader()方法。根据happens-before规范，这个过程包含的happens-before关系可以分为3类。

1. 根据程序次序规则：1 happens-before 2，2 happens-before 3, 4 happens-before 5，5 happens-before 6

2. 根据监视器锁规则：3 happens-before 4

3. 根据happens-before的传递性，2 happens-before 5

​

上述happens-before关系的图形化表现形式如图：

总结：

线程A在释放锁之前所有可见的共享变量，在线程B获取同一个锁之后，将立即变得对B线程可见。

​

2、锁释放和获取的内存语义

当线程释放锁时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存中。以上述MonitorExample程序为例，A线程释放锁后，共享数据的状态示意图如下所示：

共享数据的状态示意图

当线程获取锁时，JMM会把该线程对应的本地内存置为无效。从而使得被监视器锁保护的临界区代码必须从主内存中读取共享变量。

锁获取的状态示意图

对比锁释放-获取锁的内存语义与volatile写-读的内存语义可以看出：锁释放与volatile写有相同的内存语义；锁获取与volatile读有相同的内存语义。

总结：

• 线程A释放锁，实质上是线程A向接下来要获取这个锁的某个线程发出了（线程A对共享变量所做修改的）消息。

• 线程B获取锁，实质上是线程B接受了之前某个线程发出的（在释放这个锁对共享变量锁做的修改的）消息。

• 线程A是否锁，随后线程B获取这个锁，这个过程实质上是线程A通过主内存向线程B发送消息。

3、锁内存的语义实现

分析ReentrantLock的源代码，来分析锁内存语义的具体实现机制。

示例代码：

package com.lizba.p1;

import java.util.concurrent.locks.ReentrantLock;

/**

•   ReentrantLock示例代码
  

• @Author: Liziba

• @Date: 2021/6/10 22:17

*/

public class ReentrantLockExample {

int a = 0;

ReentrantLock lock = new ReentrantLock();

public void writer() {

lock.lock(); // 获取锁

try {

a++;

} finally {

lock.unlock(); // 释放锁

}

}

public void reader() {

lock.lock(); // 获取锁

try {

int i = a;

System.out.println(i);

} finally {

lock.unlock(); // 释放锁

}

}

}

在ReentrantLock中，调用lock()方法获取锁；调用unlock()方法释放锁。

ReentrantLock的实现依赖于Java同步器框架AbstractQueuedSynchronized(AQS)。AQS使用一个整型的volatile变量（state）来维护同步状态，这个volatile变量是ReentrantLock内存语义实现的关键。

ReetrantLock的类图

ReentrantLock分为公平锁和非公平锁，首先分析公平锁。

使用公平锁时，加锁方法lock()的调用轨迹如下。

1. ReentrantLock: lock()

2. FairSync: lock()

3. AbstractQueuedSynchronizer: acquire(int arg)

4. ReentrantLock: tryAcquire(int acquires)

第4步开始真的加锁，下面是该方法的源代码：

protected final boolean tryAcquire(int acquires) {

final Thread current = Thread.currentThread();

// 获取锁开始，首先读取volatile变量state

int c = getState();

if (c == 0) {

if (!hasQueuedPredecessors() &&

compareAndSetState(0, acquires)) {

setExclusiveOwnerThread(current);

return true;

}

}

else if (current == getExclusiveOwnerThread()) {

int nextc = c + acquires;

if (nextc < 0)

throw new Error(“Maximum lock count exceeded”);

setState(nextc);

return true;

}

return false;

}

从上面的代码中可以看出，加锁方法首先读取volatile变量state。

​

在使用公平锁时，解锁方法unlock()调用轨迹如下：

1. ReentrantLock: unlock()

2. AbstractQueuedSynchronizer: release(int arg)

3. Sync: tryRelease(int release)

第3步开始真的释放锁，下面是该方法的源代码：

protected final boolean tryRelease(int releases) {

int c = getState() - releases;

if (Thread.currentThread() != getExclusiveOwnerThread())

throw new IllegalMonitorStateException();

boolean free = false;

if (c == 0) {

free = true;

setExclusiveOwnerThread(null);

}

// 释放锁的最后，写volatile变量state

setState©;

return free;

}

从上面的代码中可以看出，释放锁的最后写volatile变量state。

总结公平锁：

根据volatile的happens-before规则，释放锁的线程在写volatile变量之前可见的共享变量，在获取锁的线程读取到同一个volatile变量后将立即变得对获取锁的线程可见。

​

现在分析非公平锁：

注意，非公平锁的释放和公平锁的释放完全一致，都是上面的源代码。所以下面只分析非公平锁的获取过程。

​

使用非公平锁，加锁方法lock()的调用轨迹如下：

1. ReentrantLock: lock()

2. NonfairSync: lock()

3. AbstractQueuedSynchronizer: compareAndSetState(int expect, int update)

第3步开始真的加锁，下面是该方法的源代码：

// 方法1

final boolean nonfairTryAcquire(int acquires) {

final Thread current = Thread.currentThread();

int c = getState();

if (c == 0) {

// 此方法中开始加锁

if (compareAndSetState(0, acquires)) {

setExclusiveOwnerThread(current);

return true;

}

}

else if (current == getExclusiveOwnerThread()) {

int nextc = c + acquires;

if (nextc < 0) // overflow

throw new Error(“Maximum lock count exceeded”);

setState(nextc);