java - ReentrantLock.Sync 中当前线程变量的搭载是如何工作的？

Question

我在“Java Concurrency in Practice”14.6.1 节中阅读了 ReentrantLock 的一些实现细节，注释中的某些内容让我感到困惑:

Because the protected state-manipulation methods have the memory semantics of a volatile read or write and ReentrantLock is careful to read the owner field only after calling getState and write it only before calling setState, ReentrantLock can piggyback on the memory semantics of the synchronization state, and thus avoid further synchronization see Section 16.1.4.

它引用的代码:

protected boolean tryAcquire(int ignored) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c ==0) {
        if (compareAndSetState(0, 1)) {
             owner = current;
             return true;
        }
     } else if (current == owner) {
         setState(c+1);
         return true;
     }
     return false;
}

我相信这是 ReentrantLock.Sync 中 nonfairTryAcquire 的简化代码。

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);
        return true;
    }
    return false;
}

因此，令人困惑的部分是 owner 的设置如何对 else 可见，owner 只是 AbstractOwnableSynchronizer 中的普通实例变量，如果 (current = = owner) 在其他线程中。事实上，owner 的读取是在调用 getState() 之后(并且 state 是一个 volatile 限定的AQS的变量)，但是在owner设置之后，就什么都没有了(可以强加同步语义)。发生数据竞争？

嗯，鉴于这本书的权威性和经过全面测试的代码，我想到了两种可能性:

1. 设置 owner = current 之前的完整屏障(无论是 mfence 还是“锁定”指令)都会执行隐藏工作。但是从我从几篇著名文章中了解到，完整的屏障更关心它之前的写入以及它之后的读取。那么，如果这种可能性成立，那么“JCIP”中的某些句子可能表述不当。

2. 我注意到在代码片段中 setState(c+1) 确实在“地理上”位于 owner = current 之后，尽管它在另一个分支中如果别的。如果评论说的是事实，是否意味着 setSate(c+1) 插入的屏障可以在另一个分支中对 owner = current 施加同步语义？

我是这方面的新手，一些很棒的博客帮助我理解了 JVM 的底层(无顺序):

• http://mechanical-sympathy.blogspot.com/
• http://preshing.com/
• http://bartoszmilewski.com
• http://psy-lob-saw.blogspot.com/

以及永远的壮丽:http://g.oswego.edu/dl/jmm/cookbook.html

在做功课和搜索互联网后，我未能得出令人满意的结论。

如果这太冗长或不清楚(英语不是我的母语)，请原谅。请帮我解决这个问题，我们将不胜感激。

Answer 1

您怀疑 owner = current;(在 CAS 之后)和 if (current == owner)(在读取状态并检查是否它是 >0)。

单独来看这段代码，我认为你的推理是正确的。但是，您还需要考虑 tryRelease:

 123:         protected final boolean tryRelease(int releases) {
 124:             int c = getState() - releases;
 125:             if (Thread.currentThread() != getExclusiveOwnerThread())
 126:                 throw new IllegalMonitorStateException();
 127:             boolean free = false;
 128:             if (c == 0) {
 129:                 free = true;
 130:                 setExclusiveOwnerThread(null);
 131:             }
 132:             setState(c);
 133:             return free;
 134:         }

这里在state设置为0之前，owner设置为null。为了初始获取锁，state必须为0，所以owner为null .

因此，

• 如果线程到达 if (current == owner) 且 c=1，
  • 它可以是拥有线程，在这种情况下，所有者是正确的并且状态会递增。
  • 它可以是另一个线程，它可以看到或看不到新的所有者。
    • 如果它看到了，那么一切都很好。
    • 如果不是，它将看到 null，这也很好。
• 如果线程到达 if (current == owner) 且 c>1，
  • 它可以是拥有线程，在这种情况下，所有者是正确的并且状态会递增。
  • 它可以是另一个线程，但所有者肯定是正确的。

我同意 JCIP 中的脚注“仅在调用 getState 之后读取所有者字段并且仅在调用 setState 之前写入”具有误导性。它在 tryRelease 中调用 setState 之前写入 owner，但不是 tryAcquire。