为什么JDK源代码要获取volatile实例的最终副本

Question 1

我阅读了有关ConcurrentHashMap的JDK源代码。

但是以下代码使我感到困惑：

public boolean isEmpty() {
    final Segment<K,V>[] segments = this.segments;
    ...
}

我的问题是：

声明“ this.segments”：

final Segment<K,V>[] segments;

因此，这里在方法的开头，声明了相同的类型引用，指向了相同的内存。

作者为什么要这样写？他们为什么不直接使用this.segments？有什么原因吗？

Question 2

这是涉及volatile变量的无锁代码的典型用法。在第一行中，您阅读了volatile一次，然后使用它。同时，另一个线程可以更新volatile，但是您只对最初读取的值感兴趣。

同样，即使所讨论的成员变量不是volatile而是final时，该习惯用法也与CPU缓存有关，因为从堆栈位置进行读取比从随机堆位置进行读取更易于缓存。本地var最终绑定到CPU寄存器的机会也更高。

对于后一种情况，实际上存在一些争议，因为JIT编译器通常会解决这些问题，但是Doug Lea是坚持一般原则的人之一。

Question 3

我想这是出于性能考虑，因此我们只需要检索一次字段值。

您可以从Joshua Bloch的有效Java引用单例成语。

他的单身人士在这里：

private volatile FieldType field;
FieldType getField() {
  FieldType result = field;
  if (result == null) { 
    synchronized(this) {
      result = field;
      if (result == null) 
        field = result = computeFieldValue();
    }
  }
  return result;
}

他写道：

此代码可能看起来有些混乱。特别是，对局部变量结果的需求可能不清楚。该变量的作用是确保在已初始化字段的常见情况下，该字段仅被读取一次。尽管不是严格必需的，但是这可以提高性能，并且通过应用于低级并发编程的标准可以更加优雅。在我的机器上，上述方法比不带局部变量的明显版本要快25％。

Question 4

它可能会减小字节代码的大小-访问本地变量的字节代码比访问实例变量的时间短。

运行时优化开销也可以减少。

但是这些都不重要。更多关于代码样式。如果您对实例变量感到满意，则一定可以。Doug Lea的可能感觉更舒适的交易与局部变量。