JDK 1.8 HashMap 通过尾插法避免了 JDK 1.7 的链表成环死循环，但未实现线程安全；红黑树并发操作仍可能导致 parent 循环引用，引发 get() 无限递归，CPU 飙高。
Java 8 的 HashMap 并没有“彻底解决”多线程死循环问题，而是**规避了 JDK 1.7 中最典型、最易触发的链表成环型死循环**。它通过尾插法降低了风险，但并未让 HashMap 变成线程安全容器——死循环在特定并发条件下依然可能发生。
尾插法如何避免链表成环
核心在于插入顺序和指针操作的可预测性：
- 不反转链表结构：尾插法将旧链表节点按原始顺序依次追加到新桶的链表尾部（如 A→B→C 迁移后仍是 A→B→C），不会像头插法那样把链表倒过来（C→B→A），从而断开了“T1 按旧顺序操作、T2 已改写结构”导致环的逻辑链条
- next 指针引用更稳定：每个节点插入时只修改尾节点的 next，不反复重置头节点的引用；即使两个线程并发迁移同一链表，它们各自构建的新链表虽可能丢失部分数据，但一般不会互相篡改对方正在写的 next 字段，难以形成 A→B→A 这类闭环
- 扩容过程拆分更清晰：JDK 1.8 把一个桶内的链表按 hash 高位是否为 1 拆成“低位链”和“高位链”，分别挂到新数组的两个位置，整个过程是单向遍历+单向链接，减少了指针交错机会
但为什么 JDK 1.8 仍可能死循环？
尾插法只管住了链表层，却没覆盖红黑树层的并发风险：
- 红黑树节点 parent 指针互指：当链表转为红黑树后，多线程同时触发树化、旋转或 move 操作时，若两个线程交叉修改 parent、left、right 引用，可能造成两个 TreeNode 的 parent 字段互相指向（A.parent = B，B.parent = A）
- get() 遍历时陷入无限递归：HashMap.get() 在红黑树中查找时会沿 parent 向上回溯（比如判断是否为根或调整颜色），一旦遇到 parent 循环引用，就会卡在 TreeNode.root() 或 find() 的向上遍历逻辑里，CPU 持续 100%
- 问题隐蔽、难复现：这类死循环依赖极精细的指令交错时机，通常只在高并发+频繁扩容+树化临界点同时发生，堆栈常停在 TreeNode.getTreeNode() 或 balanceInsertion 内部，不像 JDK 1.7 那样有明确的链表遍历循环痕迹
真正安全的做法不是靠尾插法“修复”，而是规避
别指望 HashMap 本身能扛住并发——它的设计目标从来就不是线程安全：
立即学习“Java免费学习笔记（深入）”；
- 优先用 ConcurrentHashMap：它对桶级别加锁（JDK 1.8 改为 CAS + synchronized 单个 Node），读操作完全无锁，写操作粒度细、性能好，且内部已全面防御扩容、树化、迁移等所有并发路径
- 必要时加外部同步：如果必须用 HashMap，确保所有读写操作都在同一个锁（如 synchronized 或 ReentrantLock）保护下，相当于退化为串行访问
- 避免共享可变 HashMap 实例：例如用 ThreadLocal 给每个线程独立副本，或构造后设为 final 并只读使用
尾插法是个务实改进，但它只是把“大概率崩”变成了“小概率崩”。生产环境里，不能赌那万分之一的侥幸。
