并发 - Java的AQS.Node源码疑惑
大家讲道理
大家讲道理 2017-04-17 18:00:30
0
2
852

AbstractQueuedSynchronizerNode内部类中,对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类型的变量先赋值给另外一个变量,然后把这个变量返回.
这样设计的目的是什么?

大家讲道理
大家讲道理

光阴似箭催人老,日月如移越少年。

全部回复(2)
迷茫

雷雷

注意局部变量 result,这似乎是不必要的。这样做的效果是,在 helper 已经初始化的情况下(即大多数情况下),易失性字段仅被访问一次(由于“return result;”而不是“return helper;”),这可以改善方法的整体性能提高了 25%。[6]

如果辅助对象是静态的(每个类加载器一个),另一种方法是按需初始化持有者习惯用法[7](请参阅前面引用的文本中的清单 16.6[8]。)

-----维基百科

伊谢尔伦

predecessor()这个方法里,Node p的效果不那么明显。请允许我把例子变得更极端一些:predecessor()这个方法里,Node p的效果不那么明显。请允许我把例子变得更极端一些:

final Node extremePredecessor() throws NullPointerException {
    // #L0: Node p = prev;
    // #L1
    if (crazyConditional_1(prev))  {
      ...
    }
    // #L2
    else if (crazyConditional_2(prev))  {
      ...
    }        
    // #L3
    else if (crazyConditional_3(prev)) {
      ...
    }
    // #L4
    else {
      return prev;
    }
}

假定有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。🎜
  • 🎜在#L1到#L4之间的prev的值可能是inconsistent的,因为别的thread改动了他。这使得理解code的难度大大增加。🎜
🎜如果使用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🎜
热门教程
更多>
最新下载
更多>
网站特效
网站源码
网站素材
前端模板