java 内存模型 java 锁 ReentrantLock-07_综合

锁的释放和获取

锁是 java 并发编程中最重要的同步机制。

锁除了让临界区互斥执行外，还可以让释放锁的线程向获取同一个锁的线程发送消息。

实例

MonitorExample.java

class MonitorExample {
    int a = 0;public synchronized void writer() {
      //1a++;                             //2}                                    //3public synchronized void reader() {
      //4int i = a;                       //5//……}                                    //6
}

假设线程 A 执行 writer() 方法，随后线程 B 执行 reader() 方法。

根据 happens-before 规则，这个过程包含的 happens-before 关系可以分为两类：

根据程序次序规则，1 happens before 2, 2 happens before 3; 4 happens before 5, 5 happens before 6。
根据监视器锁规则，3 happens before 4。
根据 happens before 的传递性，2 happens before 5。

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

锁释放和获取的内存语义

当线程释放锁时，JMM 会把该线程对应的本地内存中的共享变量刷新到主内存中。

以上面的 MonitorExample 程序为例，A 线程释放锁后，共享数据的状态示意图如下：

线程 A

本地内存 A: a = 1;(写入到主内存)主内存：a = 1;

当线程获取锁时，JMM 会把该线程对应的本地内存置为无效。

从而使得被监视器保护的临界区代码必须要从主内存中去读取共享变量。

下面是锁获取的状态过程：

在线程 A 写入主内存之后。

线程之间通信：线程 A 向 B 发送消息

线程 B

主内存：a = 1;(从主内存中读取)本地内存 B: a = 1;

和 volatile 内存语义对比

对比锁释放-获取的内存语义与 volatile 写-读的内存语义，

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

总结

下面对锁释放和锁获取的内存语义做个总结：

线程 A 释放一个锁，实质上是线程A向接下来将要获取这个锁的某个线程发出了（线程A对共享变量所做修改的）消息。
线程 B 获取一个锁，实质上是线程 B 接收了之前某个线程发出的（在释放这个锁之前对共享变量所做修改的）消息。
线程 A 释放锁，随后线程 B 获取这个锁，这个过程实质上是线程 A 通过主内存向线程 B 发送消息。

锁内存语义的实现

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

ReentrantLockExample.java

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;//……} finally {
    lock.unlock();  //释放锁}}
}

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

源码实现

ReentrantLock 的实现依赖于 java 同步器框架 AbstractQueuedSynchronizer（本文简称之为AQS）。

AQS 使用一个整型的 volatile 变量（命名为state）来维护同步状态，马上我们会看到，这个 volatile 变量是 ReentrantLock 内存语义实现的关键。

public class ReentrantLock implements Lock, java.io.Serializable {
    /*** Base of synchronization control for this lock. Subclassed* into fair and nonfair versions below. Uses AQS state to* represent the number of holds on the lock.*/abstract static class Sync extends AbstractQueuedSynchronizer {
    //...}/*** Sync object for non-fair locks*/static final class NonfairSync extends Sync {
    //...}/*** Sync object for fair locks*/static final class FairSync extends Sync {
    //... }
}

公平锁

lock()

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

ReentrantLock : lock()
FairSync : lock()
AbstractQueuedSynchronizer : acquire(int arg)
ReentrantLock : tryAcquire(int acquires)

在第 4 步真正开始加锁，下面是该方法的源代码(JDK 1.8)：

/*** Fair version of tryAcquire. Don't grant access unless* recursive call or no waiters or is first.*/
protected final boolean tryAcquire(int acquires) {
    final Thread current = Thread.currentThread();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()

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

ReentrantLock : unlock()
AbstractQueuedSynchronizer : release(int arg)
Sync : tryRelease(int releases)

在第 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);}setState(c);return free;
}

在释放锁的最后写 volatile 变量 state。

公平锁在释放锁的最后写 volatile 变量 state；在获取锁时首先读这个 volatile 变量。

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

非公平锁

非公平锁的释放和公平锁完全一样，所以这里仅仅分析非公平锁的获取。

lock()

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

ReentrantLock : lock()
NonfairSync : lock()
AbstractQueuedSynchronizer : compareAndSetState(int expect, int update)

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

/*** Atomically sets synchronization state to the given updated* value if the current state value equals the expected value.* This operation has memory semantics of a {@code volatile} read* and write.** @param expect the expected value* @param update the new value* @return {@code true} if successful. False return indicates that the actual* value was not equal to the expected value.*/
protected final boolean compareAndSetState(int expect, int update) {
    // See below for intrinsics setup to support thisreturn unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}

该方法以原子操作的方式更新 state 变量，本文把 java 的 compareAndSet() 方法调用简称为CAS。

JDK文档对该方法的说明如下：如果当前状态值等于预期值，则以原子方式将同步状态设置为给定的更新值。此操作具有 volatile 读和写的内存语义。

总结

现在对公平锁和非公平锁的内存语义做个总结：

公平锁和非公平锁释放时，最后都要写一个 volatile 变量 state。
公平锁获取时，首先会去读这个 volatile 变量。
非公平锁获取时，首先会用 CAS 更新这个 volatile 变量,这个操作同时具有 volatile 读和 volatile 写的内存语义。

从本文对 ReentrantLock 的分析可以看出，锁释放-获取的内存语义的实现至少有下面两种方式：

利用 volatile 变量的写-读所具有的内存语义。
利用 CAS 所附带的 volatile 读和 volatile 写的内存语义。

concurrent 包

由于 java 的 CAS 同时具有 volatile 读和 volatile 写的内存语义，因此 java 线程之间的通信现在有了下面四种方式：

A 线程写 volatile 变量，随后B线程读这个 volatile 变量。
A 线程写 volatile 变量，随后 B 线程用 CAS 更新这个 volatile 变量。
A 线程用 CAS 更新一个 volatile 变量，随后 B 线程用 CAS 更新这个 volatile 变量。
A 线程用 CAS 更新一个 volatile 变量，随后B线程读这个 volatile 变量。

ps: 简而言之，volatile 和 CAS 的读写组合。

Java 的 CAS 会使用现代处理器上提供的高效机器级别原子指令，这些原子指令以原子方式对内存执行读-改-写操作，这是在多处理器中实现同步的关键（从本质上来说，能够支持原子性读-改-写指令的计算机器，是顺序计算图灵机的异步等价机器，因此任何现代的多处理器都会去支持某种能对内存执行原子性读-改-写操作的原子指令）。

同时，volatile 变量的读/写和CAS可以实现线程之间的通信。

把这些特性整合在一起，就形成了整个 concurrent 包得以实现的基石。

通用模式

如果我们仔细分析 concurrent 包的源代码实现，会发现一个通用化的实现模式：

首先，声明共享变量为 volatile；

然后，使用 CAS 的原子条件更新来实现线程之间的同步；

同时，配合以 volatile 的读/写和CAS所具有的 volatile 读和写的内存语义来实现线程之间的通信。

AQS

AQS，非阻塞数据结构和原子变量类（java.util.concurrent.atomic 包中的类）

这些 concurrent 包中的基础类都是使用这种模式来实现的，而 concurrent 包中的高层类又是依赖于这些基础类来实现的。

参考资料

JSR 133
other

http://www.infoq.com/cn/articles/java-memory-model-5