JDK1.8 之前 HashMap 底层是 数组和链表， 之后在之前基础上加上红黑树。
相比于之前的版本， JDK1.8 之后在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树）时，将链表转化为红黑树，以减少搜索时间。
HashMap 在容量不够进行 resize 时由于高并发可能出现死链，导致 CPU 飙升，为了避免这种情况的发生，建议在高并发场景下，可以使用其他数据结构来替代 HashMap，比如 ConcurrentHashMap，它是一种线程安全的哈希表实现，在高并发情况下能够保证并发性能和数据一致性。另外，还可以通过加锁的方式来避免死链的发生，比如使用 ReentrantLock 等锁机制，来保证对 HashMap 的操作是线程安全的。
HashMap 在高并发场景下可能出现的性能问题以及如何规避这些问题
首先，HashMap 是一种常用的哈希表实现，它用于存储 key-value 键值对，并提供了快速的插入、删除和查找操作。在 HashMap 中，元素的存储位置是根据 key 的哈希值来计算的，相同哈希值的元素会被放置在同一个桶（bucket）中。当 HashMap 中的元素个数达到了负载因子（load factor）所设置的阈值时，就需要对 HashMap 进行扩容操作，从而保证 HashMap 的性能。
但是，在进行扩容操作时，由于需要重新计算元素的哈希值，重新放置元素的位置，以及调整桶的大小等操作，可能会导致多个线程同时对同一个桶进行操作，从而发生死链（链表死循环）的情况。当发生死链时，CPU 的使用率会急剧飙升，严重影响系统的性能。
为了避免这种情况的发生，建议在高并发场景下，可以使用其他数据结构来替代 HashMap，比如 ConcurrentHashMap，它是一种线程安全的哈希表实现，在高并发情况下能够保证并发性能和数据一致性。另外，还可以通过加锁的方式来避免死链的发生，比如使用 ReentrantLock 等锁机制，来保证对 HashMap 的操作是线程安全的。
综上所述，为了避免 HashMap 在高并发情况下出现死链的情况，我们可以选择使用其他数据结构，或者采取加锁等措施来保证对 HashMap 的操作是线程安全的，从而避免CPU飙升的情况。
死链问题
死链问题通常是指在HashMap中的链表或树形结构中的某个元素失去了对其他元素的正确引用，导致链表或树的结构破裂。这通常在高并发场景下出现，因为多个线程同时对HashMap进行操作时可能会导致数据结构不一致。让我们通过一个简单的例子来说明死链问题。
假设我们有一个HashMap，其初始容量为16，哈希函数为hash(key) % 16。假设现在有两个线程A和B，它们同时对HashMap执行以下操作：
在线程A和线程B并发操作时，假设以下操作顺序发生：
线程A插入(key1, value1)，将其放入bucket 1。
线程A开始插入(key2, value2)，检查bucket 1并发现已存在一个元素，因此需要将(key2, value2)放在bucket 1的链表头部。此时，线程A已经获取了链表头部的引用。
在线程A完成插入操作之前，线程B开始插入(key3, value3)。线程B检查bucket 1并发现已存在一个元素，因此需要将(key3, value3)放在bucket 1的链表头部。线程B完成了插入操作。
线程A继续完成插入(key2, value2)，但此时链表的结构已被线程B修改。由于线程A之前已经获取了链表头部的引用，它会将(key2, value2)插入到原始链表头部的下一个位置。这样，链表中的元素顺序将变为：(key3, value3) -> (key2, value2) -> (key1, value1)。
在这个例子中，虽然(key2, value2)没有丢失，但由于线程A和线程B的并发操作，链表的最终顺序可能与预期不符。在某些情况下，这可能会导致性能下降，例如在查找元素时需要遍历更长的链表。要避免这种问题，可以使用线程安全的数据结构，如ConcurrentHashMap。
https://javaguide.cn/java/collection/java-collection-questions-02.html#hashmap-多线程操作导致死循环问题看这个
文章整理自互联网，只做测试使用。发布者：Lomu，转转请注明出处：https://www.it1024doc.com/5325.html
