搜尋

首頁  >  問答  >  主體

并发 - Java的AQS.Node源码疑惑

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

大家讲道理大家讲道理2778 天前854

全部回覆(2)我來回復

  • 迷茫

    迷茫2017-04-17 18:02:30

    雷雷

    注意局部變數 result,這似乎是不必要的。這樣做的效果是,在helper 已經初始化的情況下(即大多數情況下),易失性字段僅被訪問一次(由於“return result;”而不是“return helper;”),這可以改善方法的整體性能提高了25%。 [6]

    如果輔助物件是靜態的(每個類別載入器一個),另一種方法是按需初始化持有者習慣用法[7](請參閱前面引用的文字中的清單 16.6[8]。)

    -----維基百科

    回覆
    0
  • 伊谢尔伦

    伊谢尔伦2017-04-17 18:02:30

    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,請參閱:
    Java Language Spec volatile keyword
    https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.3.1.4

    回覆
    0
  • 取消回覆