// Works with acquire/release semantics for volatile in Java 1.5 and later 
// Broken under Java 1.4 and earlier semantics for volatile 
class Foo {
    private volatile Helper helper;
    public Helper getHelper() {
        Helper result = helper;
        if (result == null) {
            synchronized(this) {
                result = helper;
                if (result == null) {
                    helper = result = new Helper();
                }
            }
        }
        return result;
    }
// other functions and members... }

Note the local variable result, which seems unnecessary. The effect of this is that in cases where helper is already initialized (i.e., most of the time), the volatile field is only accessed once (due to "return result;" instead of "return helper;"), which can improve the method's overall performance by as much as 25 percent.[6]

If the helper object is static (one per class loader), an alternative is the initialization on demand holder idiom[7] (See Listing 16.6[8] from the previously cited text.)

-------Wikipedia

在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