线程安全，无易失性

Question

谁能解释为什么这个例子是线程安全的，没有易失性？

http://www.cs.umd.edu/~pugh/java /memoryModel/DoubleCheckedLocking.html

事实上，假设computeHashCode函数总是返回相同的结果并且没有副作用（即幂等），您甚至可以摆脱所有

// Lazy initialization 32-bit primitives
// Thread-safe if computeHashCode is idempotent
class Foo { 
  private int cachedHashCode = 0;
  public int hashCode() {
    int h = cachedHashCode;
    if (h == 0) {
      h = computeHashCode();
      cachedHashCode = h;
      }
    return h;
    }
  // other functions and members...
  }

更多：我明白了，我们不关心该值是否被计算两次（因此它不是真正的线程安全）。我还想知道计算哈希码后创建的新线程是否能保证看到新的哈希码？

Answer 1

这是如履薄冰，但这里有解释。可见性问题意味着某些线程可能会看到旧版本，而另一些线​​程可能会看到新版本。在我们的例子中，一些线程看到 0，而其他线程则看到 cachedHashCode。

调用 hashCode() 并查看 cachedHashCode 的线程将仅返回它（if (h == 0) 条件不满足）并且一切正常。

但是看到 0 的线程（尽管 cachedHashCode 可能已经被计算过）只会再次重新计算。

换句话说，在最坏的情况下，每个线程都会进入第一次看到 0 的分支（就像它是 ThreadLocal 一样）。

由于computeHashCode() 是幂等的（非常重要），多次调用它（通过不同的线程）并将其重新分配给同一个变量不应该有任何副作用。

Answer 2

这里重要的信息是

computeHashCode 函数始终返回相同的结果

如果这是真的，那么computeHashCode 就被认为是有效不可变的，并且由于它始终是相同的值，因此您永远不会遇到并发问题。

至于使cachedHashCode易失性。就线程安全而言，这不会产生任何影响，因为您总是分配并返回一个线程局部变量 h ，它将是一个非零的计算哈希码。

Answer 3

这就是所谓的“活泼的单一检查习惯用法”。当计算值是幂等的（每次返回相同的值；推论：类型必须是不可变的）并且便宜（如果不小心重新计算多次也没关系）时，使用它。这总是采取某种形式

class Foo {
  private Value cacheField; // field holding the cached value; not volatile!

  public Value getValue() {
    Value value = cacheField; // very important!
    if (value == 0 or null or whatever) {
      value = computeValue();
      cacheField = value;
    }
    return value;
  }
}

，或者或多或少等价的东西。如果您的实现不是幂等的，或者不便宜，那么您应该使用另一种习惯用法；有关详细信息，请参阅有效的 Java 第 71 条。但重点是，线程最多对 cacheField 进行一次读取，如果它们看到 cacheField 处于尚未计算值的状态，它们就会重新计算该值。

例如，正如《Effective Java》中提到的，这就是 String.hashCode() 的实现方式。

Answer 4

仅当 Foo 对于贡献哈希码的字段是不可变的时，这才是正确的。 （这是满足“假设computeHashCode函数总是返回相同结果”所必需的）

否则我不同意它是线程安全的。

• 线程 1 进入 Hashcode()，完成一半，并在返回答案 5 之前暂停（例如）。
• 线程 2 进入computeHashCode() 并在中途暂停。
• 线程 3 以影响哈希码的方式修改对象。
• 线程 1 重新启动，将 hashcode 设置为 5，并将该对象作为键放入 hashmap 中。
• 线程 2 重新启动，将哈希码设置为 78392。

线程 1 稍后可能能够也可能无法在哈希映射中找到该键，具体取决于 jvm 选择如何处理该 cachedHashCode。如果愿意，jvm 可以选择保留非易失性字段的单独副本。易失性仅确保 jvm 不会这样做，并且所有线程始终看到相同的值。