Java メモリ モデルの詳細な分析: ロック

ロックの解放 - 関係が確立される前に起こります

ロックは、Java 並行プログラミングで最も重要な同期メカニズムです。ロックを使用すると、クリティカル セクションの相互排他的実行が可能になるだけでなく、ロックを解放するスレッドが同じロックを取得するスレッドにメッセージを送信できるようになります。

以下はロック解放・取得のサンプルコードです:

class MonitorExample {
    int a = 0;

    public synchronized void writer() {  //1
        a++;                             //2
    }                                    //3

    public synchronized void reader() {  //4
        int i = a;                       //5
        ……
    }                                    //6
}

スレッドAがwriter()メソッドを実行し、次にスレッドBがreader()メソッドを実行するとします。前発生ルールによると、このプロセスに含まれる前発生関係は 2 つのカテゴリに分類できます:
プログラム順序ルールによると、1 は 2 の前に発生し、2 は 3 の前に発生します。4 は 5 の前に発生し、5 は 6 の前に発生します。
監視ロックのルールによれば、3は4の前に発生します。
「前に起こる」の推移的性質によると、「2」は「5」の前に起こります。

上記の発生前関係のグラフィック表現は次のとおりです:

上の図では、各矢印でリンクされている 2 つのノードは発生前関係を表しています。黒い矢印はプログラム順序ルールを表し、オレンジ色の矢印はモニター ロック ルールを表し、青い矢印はこれらのルールを組み合わせることによって提供される前発生保証を表します。

上の図は、スレッド A がロックを解放した後、続いてスレッド B が同じロックを取得することを示しています。上の図では、2 が 5 の前に発生します。したがって、ロックを解放する前にスレッド A に表示されていたすべての共有変数は、スレッド B が同じロックを取得した後、すぐにスレッド B に表示されるようになります。

ロックの解放と取得のメモリ セマンティクス

スレッドがロックを解放すると、JMM はスレッドに対応するローカル メモリ内の共有変数をメイン メモリに更新します。上記の MonitorExample プログラムを例にとると、スレッド A がロックを解放した後、共有データの状態図は次のようになります。

スレッドがロックを取得すると、JMM はスレッドに対応するローカル メモリを無効化します。その結果、モニターによって保護されているクリティカル セクションのコードは、メイン メモリから共有変数を読み取る必要があります。以下は、ロック取得のステータスの概略図です:

ロックの解放 - 取得のメモリ セマンティクスと、揮発性書き込み - 読み取りのメモリ セマンティクスを比較すると、ロックの解放と揮発性書き込みが同じであることがわかります。メモリ セマンティクス。ロックの取得と揮発性読み取りは同じメモリ セマンティクスを持ちます。

以下はロック解放とロック取得のメモリセマンティクスの概要です:
スレッド A はロックを解放します。本質的に、スレッド A は次にロックを取得するスレッドにメッセージを送信します (スレッド A が共有スレッドに対して行うこと)。変数が変更されました) メッセージ。
スレッド B はロックを取得します。本質的に、スレッド B は前のスレッドによって送信されたメッセージを受信します (ロックを解放する前の共有変数の変更)。
スレッド A がロックを解放し、次にスレッド B がロックを取得します。このプロセスは基本的に、スレッド A がメイン メモリを介してスレッド B にメッセージを送信します。

ロック メモリ セマンティクスの実装

この記事では、ReentrantLock のソース コードを使用して、ロック メモリ セマンティクスの具体的な実装メカニズムを分析します。

以下のサンプルコードをご覧ください:

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 は、整数の揮発性変数 (名前付き状態) を使用して同期状態を維持します。この揮発性変数が ReentrantLock メモリ セマンティクスの実装の鍵であることがすぐにわかります。 以下は ReentrantLock のクラス図です (この記事に関係する部分のみを描画しています):

ReentrantLock は公平なロックと不公平なロックに分けられます。 まず公平なロックを分析します。

フェアロックを使用する場合、ロックメソッドlock()のメソッド呼び出しトレースは以下の通りです。
ReentrantLock:lock()
FairSync:lock()
AbstractQueuedSynchronizer:acquire(int arg)
ReentrantLock:tryAcquire(intacquire)

ステップ 4 で、実際にロックが開始されます。メソッドのソース コードは次のとおりです。

protected final boolean tryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();   //获取锁的开始，首先读volatile变量state
    if (c == 0) {
        if (isFirst(current) &&
            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 変数の状態を読み取ることがわかります。

フェアロックを使用する場合、ロック解除メソッド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);           //释放锁的最后，写volatile变量state
    return free;
}

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

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

现在我们分析非公平锁的内存语义的实现。

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

使用公平锁时，加锁方法lock()的方法调用轨迹如下：
ReentrantLock : lock()
NonfairSync : lock()
AbstractQueuedSynchronizer : compareAndSetState(int expect, int update)

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

protected final boolean compareAndSetState(int expect, int update) {
    return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}

该方法以原子操作的方式更新state变量，本文把java的compareAndSet()方法调用简称为CAS。JDK文档对该方法的说明如下：如果当前状态值等于预期值，则以原子方式将同步状态设置为给定的更新值。此操作具有 volatile 读和写的内存语义。

这里我们分别从编译器和处理器的角度来分析,CAS如何同时具有volatile读和volatile写的内存语义。

前文我们提到过，编译器不会对volatile读与volatile读后面的任意内存操作重排序；编译器不会对volatile写与volatile写前面的任意内存操作重排序。组合这两个条件，意味着为了同时实现volatile读和volatile写的内存语义，编译器不能对CAS与CAS前面和后面的任意内存操作重排序。

下面我们来分析在常见的intel x86处理器中，CAS是如何同时具有volatile读和volatile写的内存语义的。

下面是sun.misc.Unsafe类的compareAndSwapInt()方法的源代码：

public final native boolean compareAndSwapInt(Object o, long offset,
                                              int expected,
                                              int x);

可以看到这是个本地方法调用。这个本地方法在openjdk中依次调用的c++代码为：unsafe.cpp，atomic.cpp和atomicwindowsx86.inline.hpp。这个本地方法的最终实现在openjdk的如下位置：openjdk-7-fcs-src-b147-27jun2011\openjdk\hotspot\src\oscpu\windowsx86\vm\ atomicwindowsx86.inline.hpp（对应于windows操作系统，X86处理器）。下面是对应于intel x86处理器的源代码的片段：

// Adding a lock prefix to an instruction on MP machine
// VC++ doesn't like the lock prefix to be on a single line
// so we can't insert a label after the lock prefix.
// By emitting a lock prefix, we can define a label after it.
#define LOCK_IF_MP(mp) __asm cmp mp, 0  \
                       __asm je L0      \
                       __asm _emit 0xF0 \
                       __asm L0:

inline jint     Atomic::cmpxchg    (jint     exchange_value, volatile jint*     dest, jint     compare_value) {
  // alternative for InterlockedCompareExchange
  int mp = os::is_MP();
  __asm {
    mov edx, dest
    mov ecx, exchange_value
    mov eax, compare_value
    LOCK_IF_MP(mp)
    cmpxchg dword ptr [edx], ecx
  }
}

如上面源代码所示，程序会根据当前处理器的类型来决定是否为cmpxchg指令添加lock前缀。如果程序是在多处理器上运行，就为cmpxchg指令加上lock前缀（lock cmpxchg）。反之，如果程序是在单处理器上运行，就省略lock前缀（单处理器自身会维护单处理器内的顺序一致性，不需要lock前缀提供的内存屏障效果）。

intel的手册对lock前缀的说明如下：
确保对内存的读-改-写操作原子执行。在Pentium及Pentium之前的处理器中，带有lock前缀的指令在执行期间会锁住总线，使得其他处理器暂时无法通过总线访问内存。很显然，这会带来昂贵的开销。从Pentium 4，Intel Xeon及P6处理器开始，intel在原有总线锁的基础上做了一个很有意义的优化：如果要访问的内存区域（area of memory）在lock前缀指令执行期间已经在处理器内部的缓存中被锁定（即包含该内存区域的缓存行当前处于独占或以修改状态），并且该内存区域被完全包含在单个缓存行（cache line）中，那么处理器将直接执行该指令。由于在指令执行期间该缓存行会一直被锁定，其它处理器无法读/写该指令要访问的内存区域，因此能保证指令执行的原子性。这个操作过程叫做缓存锁定（cache locking），缓存锁定将大大降低lock前缀指令的执行开销，但是当多处理器之间的竞争程度很高或者指令访问的内存地址未对齐时，仍然会锁住总线。
禁止该指令与之前和之后的读和写指令重排序。
把写缓冲区中的所有数据刷新到内存中。

上面的第2点和第3点所具有的内存屏障效果，足以同时实现volatile读和volatile写的内存语义。

经过上面的这些分析，现在我们终于能明白为什么JDK文档说CAS同时具有volatile读和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变量。

Java的CAS会使用现代处理器上提供的高效机器级别原子指令，这些原子指令以原子方式对内存执行读-改-写操作，这是在多处理器中实现同步的关键（从本质上来说，能够支持原子性读-改-写指令的计算机器，是顺序计算图灵机的异步等价机器，因此任何现代的多处理器都会去支持某种能对内存执行原子性读-改-写操作的原子指令）。同时，volatile变量的读/写和CAS可以实现线程之间的通信。把这些特性整合在一起，就形成了整个concurrent包得以实现的基石。如果我们仔细分析concurrent包的源代码实现，会发现一个通用化的实现模式：
首先，声明共享变量为volatile；
然后，使用CAS的原子条件更新来实现线程之间的同步；
同时，配合以volatile的读/写和CAS所具有的volatile读和写的内存语义来实现线程之间的通信。

AQS，非阻塞数据结构和原子变量类（java.util.concurrent.atomic包中的类），这些concurrent包中的基础类都是使用这种模式来实现的，而concurrent包中的高层类又是依赖于这些基础类来实现的。从整体来看，concurrent包的实现示意图如下：

 以上就是Java内存模型深度解析：锁的内容，更多相关内容请关注PHP中文网（www.php.cn）！