这个问题不是关于 HashMap 不是线程安全的众所周知和记录的事实，而是关于它在 HotSpot 和 JDK 代码上的特定故障模式。我很惊讶这段代码很容易因 NPE 而失败:

public static void main(String[] args) {
    Map<Integer, Integer> m = new HashMap<>(0, 0.75f);
    IntStream.range(0, 5).parallel().peek(i -> m.put(i, i)).map(m::get).count();
}

NPE 的来源并不神秘:在 .map(m::get) 步骤中，同时尝试对 null 进行拆箱。它在 5 次运行中大约有 4 次失败。

在我的机器上 Runtime#availableProcessors() 报告 8，所以大概长度为 5 的范围被分成 5 个子任务，每个子任务只有一个成员。我还假设我的代码以解释模式运行。它可能会调用 JIT 编译的 HashMap 或 Stream 方法，但解释了顶层，因此排除了加载 HashMap 状态的任何变体进入线程本地内存(寄存器/堆栈)，从而延迟另一个线程对更新的观察。如果五个 put 操作中的一些操作在不同的内核上同时执行，我不认为它会破坏 HashMap 的内部结构。鉴于工作量很少，单个任务的时间安排必须非常精确。

真的是精确的时间(commonPool 的线程必须取消停放)，还是有其他途径导致 Oracle/OpenJDK HotSpot 失败？我现在的版本是

java version "1.8.0_72"
Java(TM) SE Runtime Environment (build 1.8.0_72-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.72-b15, mixed mode)

更新:我发现即使只进行 两次 插入也有同样高的失败率:

IntStream.range(0, 2).parallel().peek(i -> m.put(i, i)).map(m::get).count();

最佳答案

首先，它不会可靠地失败。我设法进行了一些没有发生异常的运行。然而，这并不意味着生成的 map 是正确的。也有可能每个线程都见证了自己的值被成功放置，而生成的映射错过了几个映射。

但确实，NullPointerException 失败了经常发生。我创建了以下调试代码来说明 HashMap的工作:

static <K,V> void debugPut(HashMap<K,V> m, K k, V v) {
    if(m.isEmpty()) debug(m);
    m.put(k, v);
    debug(m);
}
private static <K, V> void debug(HashMap<K, V> m) {
    for(Field f: FIELDS) try {
        System.out.println(f.getName()+": "+f.get(m));
    } catch(ReflectiveOperationException ex) {
        throw new AssertionError(ex);
    }
    System.out.println();
}
static final Field[] FIELDS;
static {
    String[] name={ "table", "size", "threshold" };
    Field[] f=new Field[name.length];
    for (int ix = 0; ix < name.length; ix++) try {
        f[ix]=HashMap.class.getDeclaredField(name[ix]);
    }
    catch (NoSuchFieldException ex) {
        throw new ExceptionInInitializerError(ex);
    }
    AccessibleObject.setAccessible(f, true);
    FIELDS=f;
}

将它与简单的顺序 for(int i=0; i<5; i++) debugPut(m, i, i); 一起使用打印:

table: null
size: 0
threshold: 1

table: [Ljava.util.HashMap$Node;@70dea4e
size: 1
threshold: 1

table: [Ljava.util.HashMap$Node;@5c647e05
size: 2
threshold: 3

table: [Ljava.util.HashMap$Node;@5c647e05
size: 3
threshold: 3

table: [Ljava.util.HashMap$Node;@33909752
size: 4
threshold: 6

table: [Ljava.util.HashMap$Node;@33909752
size: 5
threshold: 6

如您所见，由于 0 的初始容量，即使在顺序操作期间也会创建三个不同的后备数组。每增加一次容量，就有更高的机会出现并发put错过数组更新并创建自己的数组。

这与空映射的初始状态和尝试放置其第一个键的多个线程特别相关，因为所有线程都可能遇到 null 的初始状态表并创建自己的。此外，即使在读取第一个已完成状态时 put ，为第二个 put 创建了一个新数组也是。

但逐步调试显示出更多的破坏机会:

Inside the method putVal ，我们看到在结尾:

++modCount;
if (++size > threshold)
    resize();
afterNodeInsertion(evict);
return null;

换句话说，在成功插入新键之后，如果新的大小超过 threshold，表将被调整大小。 .所以在第一个 put , resize()在开始时调用，因为表是 null并且由于您指定的初始容量是0 ，即太低而无法存储一个映射，新容量将为 1和新的 threshold将是 1 * loadFactor == 1 * 0.75f == 0.75f , 四舍五入为 0 .所以就在第一个 put 的末尾, 新 threshold超过了另一个 resize()操作触发。所以初始容量为0 ，第一个put已经创建并填充了 两个 数组，如果多个线程同时执行此操作，则会有更高的中断机会，所有线程都会遇到初始状态。

还有一点。望 into the resize() operation我们看到 the lines :

 @SuppressWarnings({"rawtypes","unchecked"})
 Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
 table = newTab;
 if (oldTab != null) {
     … (transfer old contents to new array)

换句话说，新的数组引用在被旧条目填充之前被存储到堆中，所以即使没有重新排序读取和写入，另一个线程也有可能读取该引用没有看到旧条目，包括它之前自己编写的条目。实际上，减少堆访问的优化可能会降低线程在紧随其后的查询中看不到自己更新的机会。

不过，还必须指出，一切都在这里解释运行的假设是没有根据的。从 HashMap JRE 在内部也使用它，即使在您的应用程序启动之前，使用 HashMap 时也有可能遇到已经编译的代码.

关于java - 是什么实现细节让这段代码如此容易失败？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/40927934/