[面试题] JDK1.7的HashMap存在什么问题？

📖 版块 A：知识讲解版 (温故知新)

• 底层数据结构：JDK 1.7 的 HashMap 采用的是“数组 + 链表”的结构。

• 核心缺陷分析：

  1. 并发死循环 (Infinite Loop)：这是最致命的问题。在多线程环境下，触发扩容（rehash）时，由于采用“头插法”迁移数据，会导致链表成环，后续的 get 操作会陷入死循环，CPU 飙升至 100%。
  2. 数据丢失：在多线程 put 操作时，如果发生哈希碰撞，两个线程可能同时操作同一个链表头节点，导致其中一个线程写入的数据被覆盖。
  3. 性能退化：当大量数据的 Hash 值相同时，哈希表会退化成一个长链表。此时查询的时间复杂度从 O(1) 直接退化到 O(n)，导致性能急剧下降。
  4. 安全隐患 (Hash Collision Attack)：由于 1.7 的 Hash 算法相对简单，攻击者可以通过构造大量相同 Hash 值的参数（如大量的字符串请求），故意造成哈希碰撞，触发上述的性能退化，实现拒绝服务攻击（DoS）。

🎤 版块 B：面试实战版 (高手逐字稿)

Q：JDK1.7 的 HashMap 存在什么问题？

💬 高手逐字稿：

JDK 1.7 的 HashMap 在设计上主要存在三个核心问题：并发安全风险、极端情况下的性能抖动，以及潜在的安全漏洞。

首先，最广为人知的就是多线程环境下的死循环问题。在 1.7 版本中，扩容迁移数据使用的是“头插法”。这种设计在单线程下没问题，但在多线程并发扩容时，由于它会改变链表中元素的原有顺序，多个线程同时调整指针指向，极易导致链表节点形成环路。一旦成环，后续任何查询该位置的操作都会陷入死循环，直接导致 CPU 负载爆表。同时，并发写操作还会导致数据覆盖，造成数据丢失。

其次是查询性能的稳定性。1.7 的结构是纯粹的数组加链表。如果 Hash 算法选取的种子不当，或者数据特征分布不均，就会导致某些桶位上的链表过长。在这种情况下，HashMap 的查询效率会从常数级别 O(1) 退化为线性级别 O(n)，这对高性能要求的系统是不可接受的。

最后一点，也是很多开发者容易忽略的，是 Hash 碰撞攻击。由于 1.7 处理碰撞的方式非常单一，黑客可以构造大量 Hash 值相同的请求参数，强行让服务端的 HashMap 退化成多个长链表，从而耗尽服务器 CPU 资源，实现 DoS 攻击。

💡 高手自问自答： 既然提到了头插法导致的死循环，我再稍微拆解一下底层的细节。其实根本原因在于 transfer 方法里，旧链表迁移到新数组时，指针 e 和 next 的指向逻辑在并发时被破坏了。比如线程 A 刚记录了 e 和 next 的位置就被挂起，而线程 B 完成了扩容并反转了链表顺序，等线程 A 恢复后，它所指向的 next 节点其实已经变成了 e 的父节点，这样一处理，环就形成了。

所以，这也是为什么 JDK 1.8 彻底废弃了头插法，改用尾插法，并引入了红黑树来解决 O(n) 退化问题。当然，即使解决了死循环，HashMap 依然不是线程安全的，并发场景下我们还是得用 ConcurrentHashMap。