AbstractQueuedSynchronizer
的Node
内部类中,对volatile Node prev
成员变量获取方法predecessor()
如下
final Node predecessor() throws NullPointerException {
Node p = prev;
if (p == null)
throw new NullPointerException();
else
return p;
}
在源码中,这里对volatile
类型的成员变量prev
的返回,是先把他赋值给一个中间变量p,然后拿p返回。
这种设计在AQS
的源码中很多地方都有涉及到,包括在其它源码中也经常看到对volatile
类型的变量先赋值给另外一个变量,然后把这个变量返回.
这样设计的目的是什么?
雷雷
-----维基百科
在
predecessor()
这个方法里,Node p
的效果不那么明显。请允许我把例子变得更极端一些:predecessor()
这个方法里,Node p
的效果不那么明显。请允许我把例子变得更极端一些:假定有100个threads调用会改动prev的值,则在#L1到#L4之间,任何对于shared variable -- prev的改动都对extremePredecessor()是可见的。
这会有以下问题:
和同步锁很类似,对
prev
的同步更新,会造成性能损耗,prev就成了整个Queue就有了bottleneck。在#L1到#L4之间的prev的值可能是inconsistent的,因为别的thread改动了他。这使得理解code的难度大大增加。
如果使用
Node p = prev;
那么#L0之后,就不需要同步p
的值了。#L1到#L4的p
也是consistent的。对于
volatile
rrreee假定有100个threads调用会改动prev的值,则在#L1到#L4之间,任何对于shared variable -- prev的改动都对extremePredecessor()是可见的。
这会有以下问题:
prev
的同步更新,会造成性能损耗,prev就成了整个Queue就有了bottleneck。🎜Node p = prev;
那么#L0之后,就不需要同步p
的值了。#L1到#L4的p
也是consistent的。🎜 🎜对于volatile
,请参见: 🎜Java Language Spec volatile keyword🎜https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.3.1.4🎜