Java 8+中，幂等32位原语无同步DCL结论是否有效？computeHashCode仅调用一次？

好问题！这个是并发编程里的经典场景，咱们结合Java内存模型的演变来一步步说清楚：

1. 线程安全性结论在Java 8+中依然成立 #

首先要明确：这里的“线程安全”指的是最终所有线程都会得到正确的哈希值，不会出现错误结果。在Java 8+中这个结论是成立的，核心原因有两点：

• 32位int类型的赋值操作是原子性的：不管有没有同步机制，对cachedHashCode的赋值都不会出现“部分写入”的情况，线程读到的要么是初始值0，要么是computeHashCode()返回的完整正确值。
• computeHashCode()具备幂等性：即使多个线程同时进入if (h == 0)分支，各自调用computeHashCode()得到的结果完全一致，后续对cachedHashCode的多次赋值也都是同一个值。最终所有线程读到的cachedHashCode都会是正确的哈希值，不会出现不一致的错误。

2. computeHashCode() 并不会仅被调用一次 #

这是很多人容易误解的点：虽然线程安全成立，但无法保证computeHashCode()只执行一次。
因为cachedHashCode既没有被volatile修饰，也没有同步块的可见性保障，高并发场景下会出现这样的情况：

• 线程A进入hashCode()方法，读到cachedHashCode为0，开始执行computeHashCode()；
• 在线程A把计算结果赋值给cachedHashCode之前，线程B也进入hashCode()方法，此时线程B可能看不到线程A即将写入的新值，依然读到cachedHashCode为0，也会执行computeHashCode()。

也就是说，computeHashCode()可能会被多个线程重复调用多次——不过因为它是幂等的，这些重复调用不会影响最终结果的正确性，只是会带来一些不必要的计算开销。

补充：Java 4 vs Java 8+的差异 #

Java 4的内存模型相对松散，但32位原语的原子性依然有保障；Java 5及以后（包括8+）更新了内存模型，强化了volatile和同步块的可见性语义，但这个场景里没有用到这些特性，核心逻辑的线程安全性依然依赖于int的原子性和方法的幂等性，所以结论在Java 8+中依然有效——只是要区分清楚：“线程安全”不代表“避免重复计算”。

内容的提问来源于stack exchange，提问作者gstackoverflow