关于java:HashMap为什么线程不安全

4次阅读

共计 3254 个字符，预计需要花费 9 分钟才能阅读完成。

1、HashMap 线程不平安起因：

起因：

JDK1.7 中，因为多线程对 HashMap 进行扩容，调用了 HashMap#transfer()，具体起因：某个线程执行过程中，被挂起，其余线程曾经实现数据迁徙，等 CPU 资源开释后被挂起的线程从新执行之前的逻辑，数据曾经被扭转，造成死循环、数据失落。
JDK1.8 中，因为多线程对 HashMap 进行 put 操作，调用了 HashMap#putVal()，具体起因：假如两个线程 A、B 都在进行 put 操作，并且 hash 函数计算出的插入下标是雷同的，当线程 A 执行完第六行代码后因为工夫片耗尽导致被挂起，而线程 B 失去工夫片后在该下标处插入了元素，实现了失常的插入，而后线程 A 取得工夫片，因为之前曾经进行了 hash 碰撞的判断，所有此时不会再进行判断，而是间接进行插入，这就导致了线程 B 插入的数据被线程 A 笼罩了，从而线程不平安。

改善：

数据失落、死循环曾经在在 JDK1.8 中曾经失去了很好的解决，如果你去浏览 1.8 的源码会发现找不到 HashMap#transfer()，因为 JDK1.8 间接在 HashMap#resize() 中实现了数据迁徙。

2、HashMap 线程不平安的体现：

JDK1.7 HashMap 线程不安整体当初：死循环、数据失落
JDK1.8 HashMap 线程不安整体当初：数据笼罩

1、JDK1.7 扩容引发的线程不平安

HashMap 的线程不平安次要是产生在扩容函数中，其中调用了 JDK1.7 HshMap#transfer()：

void transfer(Entry[] newTable, boolean rehash) {
    int newCapacity = newTable.length;
    for (Entry<K,V> e : table) {while(null != e) {
            Entry<K,V> next = e.next;
            if (rehash) {e.hash = null == e.key ? 0 : hash(e.key);
            }
            int i = indexFor(e.hash, newCapacity);
            e.next = newTable[i];
            newTable[i] = e;
            e = next;
        }
    }
}
复制代码

这段代码是 HashMap 的扩容操作，从新定位每个桶的下标，并采纳头插法将元素迁徙到新数组中。头插法会将链表的程序翻转，这也是造成死循环的关键点。了解了头插法后再持续往下看是如何造成死循环以及数据失落的。

2、扩容造成死循环和数据失落

假如当初有两个线程 A、B 同时对上面这个 HashMap 进行扩容操作：

失常扩容后的后果是上面这样的：

然而当线程 A 执行到下面 transfer 函数的第 11 行代码时，CPU 工夫片耗尽，线程 A 被挂起。即如下图中地位所示：

此时线程 A 中：e=3、next=7、e.next=null

当线程 A 的工夫片耗尽后，CPU 开始执行线程 B，并在线程 B 中胜利的实现了数据迁徙

重点来了，依据 Java 内存模式可知，线程 B 执行完数据迁徙后，此时主内存中 newTable 和 table 都是最新的，也就是说：7.next=3、3.next=null。

随后线程 A 取得 CPU 工夫片继续执行 newTable[i] = e，将 3 放入新数组对应的地位，执行完此轮循环后线程 A 的状况如下：

接着继续执行下一轮循环，此时 e =7，从主内存中读取 e.next 时发现主内存中 7.next=3，此时 next=3，并将 7 采纳头插法的形式放入新数组中，并继续执行完此轮循环，后果如下：

此时没任何问题。

上轮 next=3，e=3，执行下一次循环能够发现，3.next=null，所以此轮循环将会是最初一轮循环。

接下来当执行完 e.next=newTable[i] 即 3.next= 7 后，3 和 7 之间就相互连接了，当执行完 newTable[i]= e 后，3 被头插法从新插入到链表中，执行后果如下图所示：

下面说了此时 e.next=null 即 next=null，当执行完 e =null 后，将不会进行下一轮循环。到此线程 A、B 的扩容操作实现，很显著当线程 A 执行完后，HashMap 中呈现了环形构造，当在当前对该 HashMap 进行操作时会呈现死循环。

并且从上图能够发现，元素 5 在扩容期间被莫名的失落了，这就产生了数据失落的问题。

3、JDK1.8 中的线程不平安

下面的扩容造成的数据失落、死循环曾经在在 JDK1.8 中曾经失去了很好的解决，如果你去浏览 1.8 的源码会发现找不到 HashMap#transfer()，因为 JDK1.8 间接在 HashMap#resize() 中实现了数据迁徙。

为什么说 JDK1.8 会呈现数据笼罩的状况？ 咱们来看一下上面这段 JDK1.8 中的 put 操作代码：

其中第六行代码是判断是否呈现 hash 碰撞，假如两个线程 A、B 都在进行 put 操作，并且 hash 函数计算出的插入下标是雷同的，当线程 A 执行完第六行代码后因为工夫片耗尽导致被挂起，而线程 B 失去工夫片后在该下标处插入了元素，实现了失常的插入，而后线程 A 取得工夫片，因为之前曾经进行了 hash 碰撞的判断，所有此时不会再进行判断，而是间接进行插入，这就导致了线程 B 插入的数据被线程 A 笼罩了，从而线程不平安。

除此之前，还有就是代码的第 38 行处有个 ++size，咱们这样想，还是线程 A、B，这两个线程同时进行 put 操作时，假如以后 HashMap 的 zise 大小为 10，当线程 A 执行到第 38 行代码时，从主内存中取得 size 的值为 10 后筹备进行 + 1 操作，然而因为工夫片耗尽只好让出 CPU，线程 B 高兴的拿到 CPU 还是从主内存中拿到 size 的值 10 进行 + 1 操作，实现了 put 操作并将 size=11 写回主内存，而后线程 A 再次拿到 CPU 并继续执行 (此时 size 的值仍为 10)，当执行完 put 操作后，还是将 size=11 写回内存，此时，线程 A、B 都执行了一次 put 操作，然而 size 的值只减少了 1，所有说还是因为数据笼罩又导致了线程不平安。

应用 Collections.synchronizedMap(map)，包装成同步 Map，原理就是在 HashMap 的所有办法上 synchronized。

例如：Collections.SynchronizedMap#get()

public V get(Object key) {synchronized (mutex) {return m.get(key);
    }
}
复制代码

1、HashMap 线程不平安起因：

起因：

JDK1.7 中，因为多线程对 HashMap 进行扩容，调用了 HashMap#transfer()，具体起因：某个线程执行过程中，被挂起，其余线程曾经实现数据迁徙，等 CPU 资源开释后被挂起的线程从新执行之前的逻辑，数据曾经被扭转，造成死循环、数据失落。
JDK1.8 中，因为多线程对 HashMap 进行 put 操作，调用了 HashMap#putVal()，具体起因：假如两个线程 A、B 都在进行 put 操作，并且 hash 函数计算出的插入下标是雷同的，当线程 A 执行完第六行代码后因为工夫片耗尽导致被挂起，而线程 B 失去工夫片后在该下标处插入了元素，实现了失常的插入，而后线程 A 取得工夫片，因为之前曾经进行了 hash 碰撞的判断，所有此时不会再进行判断，而是间接进行插入，这就导致了线程 B 插入的数据被线程 A 笼罩了，从而线程不平安。

改善：