共计 3406 个字符，预计需要花费 9 分钟才能阅读完成。
Java 的 HashMap 是非线程平安的，多线程下应该用 ConcurrentHashMap。
多线程下 [HashMap] 的问题（这里次要说死循环问题）：
- 多线程 put 操作后，get 操作导致死循环。
- 多线程 put 非 NULL 元素后，get 操作失去 NULL 值。
- 多线程 put 操作，导致元素失落。
1、为何呈现死循环？
在多线程下应用非线程平安的 HashMap，单线程基本不会呈现。
- HashMap 是采纳链表解决 Hash 抵触，因为是链表构造，那么就很容易造成闭合的链路，这样在循环的时候只有有线程对这个 HashMap 进行 get 操作就会产生死循环。
- 在单线程状况下，只有一个线程对 HashMap 的数据结构进行操作，是不可能产生闭合的回路的。
- 那就只有在多线程并发的状况下才会呈现这种状况，那就是在 put 操作的时候，如果
size>initialCapacity*loadFactor，那么这时候 HashMap 就会进行 rehash 操作，随之 HashMap 的构造就会产生天翻地覆的变动。很有可能就是在两个线程在这个时候同时触发了 rehash 操作，产生了闭合的回路。
2、如何产生的？
存储数据put()：
public V put(K key, V value)
{
......
// 算 Hash 值
int hash = hash(key.hashCode());
int i = indexFor(hash, table.length);
// 如果该 key 已被插入，则替换掉旧的 value（链接操作）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++;
// 该 key 不存在，须要减少一个结点
addEntry(hash, key, value, i);
return null;
}当咱们往 HashMap 中 put 元素的时候，先依据 key 的 hash 值得到这个元素在数组中的地位（即下标），而后就能够把这个元素放到对应的地位中了。
如果这个元素所在的地位上曾经寄存有其余元素了，那么在同一个位子上的元素将以链表的模式寄存，新退出的元素放在链头，而先前退出的放在链尾。
查看容量是否超标 addEntry：
void addEntry(int hash, K key, V value, int bucketIndex)
{Entry<K,V> e = table[bucketIndex];
table[bucketIndex] = new Entry<K,V>(hash, key, value, e);
// 查看以后的 size 是否超过了咱们设定的阈值 threshold，如果超过，须要 resize
if (size++ >= threshold)
resize(2 * table.length);
}如果当初 size 曾经超过了 threshold，那么就要进行 resize 操作, 新建一个更大尺寸的 hash 表，而后把数据从老的 Hash 表中迁徙到新的 Hash 表中。
调整 Hash 表大小 resize：
void resize(int newCapacity)
{Entry[] oldTable = table;
int oldCapacity = oldTable.length;
......
// 创立一个新的 Hash Table
Entry[] newTable = new Entry[newCapacity];
// 将 Old Hash Table 上的数据迁徙到 New Hash Table 上
transfer(newTable);
table = newTable;
threshold = (int)(newCapacity * loadFactor);
}当 table[]数组容量较小，容易产生哈希碰撞，所以，Hash 表的尺寸和容量十分的重要。
一般来说，Hash 表这个容器当有数据要插入时，都会查看容量有没有超过设定的 thredhold，如果超过，须要增大 Hash 表的尺寸，这个过程称为 resize。
多个线程同时往 HashMap 增加新元素时，屡次 resize 会有肯定概率呈现死循环，因为每次 resize 须要把旧的数据映射到新的哈希表，这一部分代码在HashMap#transfer() 办法，如下：
void transfer(Entry[] newTable)
{Entry[] src = table;
int newCapacity = newTable.length;
// 上面这段代码的意思是：// 从 OldTable 里摘一个元素进去，而后放到 NewTable 中
for (int j = 0; j < src.length; j++) {Entry<K,V> e = src[j];
if (e != null) {src[j] = null;
do {
Entry<K,V> next = e.next;// 取出第一个元素
int i = indexFor(e.hash, newCapacity);
e.next = newTable[i];
newTable[i] = e;
e = next;
} while (e != null);
}
}
}标红代码是导致多线程应用 hashmap 呈现 CUP 使用率骤增，呈现死循环，从而多个线程阻塞的罪魁祸首。另外举荐：Java 进阶视频资源
3、图解 HashMap 死循环：
失常的 ReHash 的过程（单线程）：假如了咱们的 hash 算法就是简略的用 key mod 一下表的大小（也就是数组的长度）。
最下面的是 old hash 表，其中的 Hash 表的 size=2, 所以 key = 3, 7, 5，在 mod 2 当前都抵触在table[1] 这里了。接下来的三个步骤是 Hash 表 resize 成 4，而后所有的<key,value> 从新 rehash 的过程。
并发下的 Rehash（多线程）
1）假如咱们有两个线程。
do {
Entry<K,V> next = e.next; // <-- 假如线程一执行到这里就被调度挂起了，执行其余操作
int i = indexFor(e.hash, newCapacity);
e.next = newTable[i];
newTable[i] = e;
e = next;
} while (e != null);而咱们的线程二执行实现了。于是咱们有上面的这个样子：
留神，因为 Thread1 的 e 指向了 key(3)，而 next 指向了 key(7)，其在线程二 rehash 后，指向了线程二重组后的链表。咱们能够看到链表的程序被反转后。在这里线程一变成了操作通过线程二操作后的 HashMap。另外，多线程系列面试题和答案全副整顿好了，微信搜寻Java 技术栈，在后盾发送：面试，能够在线浏览。
2）线程一被调度回来执行。
- 先是执行
newTalbe[i] = e; - 而后是
e = next，导致了 e 指向了key(7)， - 而下一次循环的
next = e.next导致了 next 指向了key(3)。
3）所有安好。
线程一接着工作。把 key(7) 摘下来，放到 newTable[i] 的第一个，而后把 e 和 next 往下移。这个元素所在的地位上曾经寄存有其余元素了，那么在同一个位子上的元素将以链表的模式寄存，新退出的放在链头，而先前退出的放在链尾。
4）环形链接呈现。
e.next = newTable[i] 导致 key(3).next 指向了 key(7)。
留神：此时的
key(7).next曾经指向了key(3)，环形链表就这样呈现了。
于是，当咱们的线程一调用到，HashTable.get(11)时，喜剧就呈现了——Infinite Loop。
这里介绍了在多线程下为什么 HashMap 会呈现死循环，不过在实在的生产环境下，不会应用线程不平安的 HashMap 的。
原文链接：https://blog.csdn.net/dingjia…
版权申明：本文为 CSDN 博主「powerfuler」的原创文章，遵循 CC 4.0 BY-SA 版权协定，转载请附上原文出处链接及本申明。
近期热文举荐：
1.1,000+ 道 Java 面试题及答案整顿(2021 最新版)
2. 别在再满屏的 if/ else 了，试试策略模式，真香！！
3. 卧槽！Java 中的 xx ≠ null 是什么新语法？
4.Spring Boot 2.5 重磅公布，光明模式太炸了！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！
