java - 当两个线程试图修改/访问 HashMap 中的同一个键时会发生什么？

Question

在并发环境中应该使用ConcurrentHashMap。但是 java 为普通的 HashMap promise 了什么？

Map map = new HashMap();

// thread 1
map.put("a", 1)

// thread 2
map.put("a", 2)

当尝试通过 map.get("a") 获取值时，是否会向我保证 map 不会损坏并且返回值必须在 1 或2?

Answer 1

如果我理解的话，问题是关于并发场景中会发生什么，而不是 HashMap 是否合适(众所周知的不合适)。

要了解在这种非常不受欢迎的情况下会发现什么样的问题，最好的方法是分析 the source code .比如在openjdk 1.6实现中:

public V More ...put(K key, V value) {
     if (key == null)
         return putForNullKey(value);
     int hash = hash(key.hashCode());
     int i = indexFor(hash, table.length);
     for (Entry<K,V> e = table[i]; e != null; e = e.next) {
         Object k;
         if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
             V oldValue = e.value;
             e.value = value;
             e.recordAccess(this);
             return oldValue;
         }
    }

     modCount++;
     addEntry(hash, key, value, i);
     return null;
 }

如果此方法和属性中没有同步机制，可能会出现以下一个或多个问题:

1) 非确定性返回

行:

return oldValue;

线程 1 的结果可以是旧值(在线程 1 和 2 调用之前)，可以是 2 或 null。它取决于 Thread 2 addEntry(hash, key, value, i) 是否完全运行。当然，线程 2 也有同样的问题。

2) 未确定的索引和重复的键

int i = indexFor(hash, table.length);

取决于 table.length。因此，根据此散列是否存在先前值，i 索引对于两个调用可能不同(取决于 addEntry(hash, key, value, i) 在另一个线程中的执行。

3) splinter 的大小和一致性

预计连续调用 put("a",...) 不会改变映射的大小(至少在没有键“a”的条目的第一次调用之后)。但是，取决于 race conditions在这两个线程中，映射大小的一致性可能会被打破，即 keyset 的大小与 map 大小的大小不同。用于对 key 进行哈希处理的其他变量，因为 modCount 可能会变得不一致，从而破坏 future 对 put 和 get 的调用。

因此，问题评论中的正确说法是，由于意外行为和内部结构损坏，在并发场景中使用 Map 是完全不受欢迎的。