在Java集合框架中，HashMap的线程安全问题是一个常被讨论却容易被忽略的隐患。JDK 7版本下，多线程扩容极易导致CPU飙升，这一问题既经典又隐蔽。JDK 8虽然通过头插改尾插、引入红黑树等措施修复了环形链表和死循环问题，但需要注意——它依然不是线程安全的容器。并发put操作可能引发数据丢失，size()方法的返回值也不准确，迭代器依然遵循fail-fast机制。因此，真正需要并发读写的场景，仍需使用ConcurrentHashMap。 --- JDK 7的多线程扩容为何会导致CPU满载？核心原因在于头插法在并发条件下形成了环形链表。resize()内部调用的transfer()方法，针对每个桶的链表采用头插方式迁移到新数组：原始链表A→B→null，头插后变成B→A→null——顺序被反转。这种“倒着插”的逻辑在单线程环境下完全正常；但一旦多线程并发，指针重写完全依赖执行时序。 请看下面典型的交错场景： - 线程T1读取了e=A、next=B，正准备将A插入新桶，随后被挂起。 - 线程T2趁机完成了整个迁移，新桶里已经是B→A→null。 - T1恢复后，仍然拿着旧的next（B）继续执行：将A的next设为B，而此时B的next已经指向A。 - 结果：A.next == B 且 B.next == A —— 环形链表就此形成。 环一旦存在，任何对该桶的get()或containsKey()调用都会陷入无限循环： ``` for (Entry e = table[i]; e != null; e = e.next) ``` 因为e永远不为null，循环体持续执行指针跳转和条件判断——没有I/O、没有锁等待、没有异常抛出，指令极轻却永不退出。因此CPU长时间处于满载状态，而jstack中线程状态始终为RUNNABLE，堆栈反复卡在getEntry或transfer中的e = e.next那一行。GC照常运行，jstat -gc也没有异常，极易被误判为外部依赖慢或配置问题。接口超时、日志静默，重启后暂时恢复，过一段时间又复现。 当然，这并非概率事件，而是特定条件下必然发生的逻辑错误。需要同时满足三个硬条件才会触发： - 多个线程共享同一个未同步的HashMap实例（例如Spring单例Bean、static字段）。 - 多个线程几乎同时达到扩容阈值（默认容量16×0.75=12，第13次put就可能触发）。 - 被迁移的旧桶中链表长度≥2（哈希冲突集中，单节点桶不会成环）。 缺一不可。 --- 那么JDK 8做了哪些改进？它把头插改为尾插，迁移过程保持了节点相对顺序，从根本上消除了成环的可能——get不会死循环，CPU也不会因此满载。但别高兴太早，并发put仍然可能丢失数据：两个线程同时计算同一位置，后写覆盖前写；size()返回值可能不准，因为计数没有同步；迭代器依然是fail-fast，不提供强一致性保证。 因此，如果需要在多线程环境下安全使用HashMap，无脑选择ConcurrentHashMap即可。如果只是读多写少，也可以考虑Collections.synchronizedMap，但迭代时仍需额外同步。记住这个原则就行。