我在“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
设置之后,就什么都没有了(可以强加同步语义)。发生数据竞争?
嗯,鉴于这本书的权威性和经过全面测试的代码,我想到了两种可能性:
设置
owner = current
之前的完整屏障(无论是 mfence 还是“锁定”指令)都会执行隐藏工作。但是从我从几篇著名文章中了解到,完整的屏障更关心它之前的写入以及它之后的读取。那么,如果这种可能性成立,那么“JCIP”中的某些句子可能表述不当。我注意到在代码片段中
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
在做功课和搜索互联网后,我未能得出令人满意的结论。
如果这太冗长或不清楚(英语不是我的母语),请原谅。请帮我解决这个问题,我们将不胜感激。
最佳答案
您怀疑 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
。
关于java - ReentrantLock.Sync 中当前线程变量的搭载是如何工作的?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18732088/