《HashMap 核心原理全解（讲解四）：极端场景、可变对象灾难与高级 API 陷阱》

前言：从"理想世界"到"残酷现实"

在前三篇的连载中，我们从源码的静态常量出发，剖析了 2 的幂次方设计、0.75 的加载因子、8 与 6 的树化防抖动机制，并彻底打通了哈希扰动函数、下标计算、扩容与树化的双重触发机制，最后回顾了 JDK 7 多线程扩容导致的死循环血泪史。

至此，HashMap 在"理想状态"下的底层运转逻辑已经完美闭环。然而，在实际的工程开发中，我们往往无法保证输入数据的完美，也无法保证业务逻辑的绝对严谨。当开发者传入了恶意的 Key，或者在 put 之后修改了 Key 的属性，HashMap 会做出怎样的反应？

本篇章将带你走出"理想世界"，直面 HashMap 在极端场景下的退化、可变对象作为 Key 的灾难，以及高级 API 在并发环境下的隐秘陷阱。

第十章：极端场景------当所有 Key 的 hashCode 都相同时

在正常的随机哈希算法下，元素会均匀分布在各个桶中。但如果我们故意传入一批 hashCode() 完全相同的 Key，HashMap 会怎样？

10.1 链表的终极退化

【定义】

如果所有的 Key 的 hashCode 都相同，那么经过扰动函数和 & (n-1) 运算后，它们最终都会落入同一个桶（同一个下标位置）。此时，HashMap 底层的数组将退化为一个巨大的单向链表。

【深度追问：这会触发树化吗？】

会，但有前提。

正如我们在第二篇中详细推演的"双重触发机制"：

当这个桶内的链表长度达到 8 ，且数组总长度 < 64 时，HashMap 会优先选择扩容（一直扩容到 64）。
当数组总长度 >= 64 时，这个长达 8 的链表才会被转化为红黑树。

【通俗讲解：最坏情况下的性能灾难】

即使触发了树化，由于所有元素的 Hash 值相同，它们在红黑树中的比较将完全依赖 compareTo() 或 equals() 方法。此时，HashMap 的查询时间复杂度从理想的 O(1)O(1)O(1) 彻底退化为 O(log⁡n)O(\log n)O(logn)（红黑树）或 O(n)O(n)O(n)（链表）。这也是为什么 JDK 8 引入了 Comparable 接口作为红黑树排序的辅助手段，以防止恶意数据导致的性能攻击。

第十一章：可变对象灾难------数据"凭空消失"的底层逻辑

这是日常开发中最隐蔽、最致命的 Bug 之一：使用自定义对象作为 Key，在 put 之后修改了该对象的属性，导致后续 get 时返回 null。

11.1 为什么数据会"消失"？

【定义】

HashMap 在存储和查找时，依赖的是 Key 的 hashCode() 和 equals()。如果 Key 是可变对象，且在 put 之后其参与计算 hashCode 的属性被修改，那么它的 hashCode 就会发生改变。

【通俗讲解：换了门牌号的住户】

假设你把 Key（对象 A）放进了 HashMap，此时对象 A 的 hashCode = 100，HashMap 把它放在了下标为 100 的桶 里。

随后，你修改了对象 A 的某个属性，导致它的 hashCode 变成了 200 。

当你再次调用 map.get(A) 时，HashMap 会重新计算 Key 的哈希值，得到 200，然后去下标为 200 的桶 里找。

结果可想而知：200 的桶里空空如也，而真正的数据依然静静地躺在 100 的桶里。数据并没有丢失，只是**"找不到"**了。

11.2 不可变对象：HashMap 的最佳搭档

为了避免这种灾难，HashMap 的 Key 强烈建议使用不可变对象（Immutable Object） ，例如 String、Integer 或自定义的 final 类。不可变对象的 hashCode 在创建时就被固定，永远保证了"存入的位置"和"查找的位置"绝对一致。

第十二章：高级 API 的陷阱------computeIfAbsent 并非绝对安全

JDK 8 为 HashMap 引入了一系列优雅的函数式 API，如 computeIfAbsent、merge 等。它们看起来是原子操作，但实际上暗藏杀机。

12.1 computeIfAbsent 的并发陷阱

【定义】

computeIfAbsent(key, mappingFunction) 的作用是：如果 Key 不存在，则执行函数计算 Value 并放入 Map。很多开发者误以为这是一个"检查并放入"的原子操作，但在单线程的 HashMap 中，它依然不是绝对安全的。

【深度追问：为什么在单线程中也可能出问题？】

问题出在**"递归调用"上。
如果你在 mappingFunction（Lambda 表达式）内部，又对同一个 HashMap** 进行了 put 或 computeIfAbsent 操作，就会触发 HashMap 的内部状态修改。

在 JDK 8 的早期版本中，这会导致底层链表/红黑树的结构在遍历过程中被修改，从而引发 ConcurrentModificationException，甚至导致死循环 或数据丢失。

【通俗讲解：在装修房间的同时拆承重墙】

computeIfAbsent 正在遍历或修改某个桶的结构，而你的 Lambda 函数又在内部触发了扩容或结构改变。这就好比你在装修房间的同时，还在拆承重墙，整个数据结构必然会崩溃。因此，绝对不要在 computeIfAbsent 的 Lambda 内部修改同一个 Map。

第十三章：历史回眸------HashMap 与 Hashtable 的底层本质区别

在面试和实际选型中，我们经常会将 HashMap 与它的老前辈 Hashtable 进行对比。除了众所周知的"线程安全"与"线程不安全"，它们在底层实现上还有哪些本质区别？

13.1 对 null 的处理策略

HashMap ：允许 Key 为 null，也允许 Value 为 null。当 Key 为 null 时，HashMap 会将其特殊处理，固定放在数组的下标 0 的位置（因为 null 没有 hashCode，无法进行位运算）。
Hashtable ：不允许 Key 为 null，也不允许 Value 为 null。如果传入 null，会直接抛出 NullPointerException。

13.2 初始容量与扩容机制

HashMap ：默认初始容量为 16 ，加载因子为 0.75 ，扩容时容量变为原来的 2 倍（且强制保持 2 的幂）。
Hashtable ：默认初始容量为 11 ，加载因子为 0.75 ，扩容时容量变为原来的 2n + 1（例如 11 -> 23 -> 47）。

【深度追问：为什么 Hashtable 不采用 2 的幂？】

Hashtable 诞生于 JDK 1.0 时代，当时的设计并没有考虑到利用位运算 & (n-1) 来优化取模运算。它老老实实地使用了 hash % n。因此，Hashtable 的容量不需要是 2 的幂，甚至为了避免某些哈希分布的规律，它特意选择了奇数（2n+1）作为扩容策略。这也是为什么 Hashtable 的性能在海量数据下远不如 HashMap 的根本原因。

结语与后续预告

在第四部分的讲解中，我们走出了理想状态，直面了 HashMap 在极端场景下的退化、可变对象作为 Key 的灾难、高级 API 的递归陷阱，并彻底厘清了 HashMap 与 Hashtable 的底层本质区别。

至此，我们已经从静态常量、动态机制、并发演进、极端场景等多个维度，构建了一个极其庞大且严密的 HashMap 知识体系。但在后续的《HashMap 核心原理全解（讲解五）》中，我们还将继续向更深处探索：

内存模型与对象头：HashMap 底层的 Node 对象在 JVM 内存中究竟长什么样？
序列化与反序列化 ：为什么 HashMap 重写了 writeObject 和 readObject？它在序列化时做了哪些特殊处理？
JDK 9+ 的隐秘优化：从 JDK 9 开始，HashMap 引入了"紧凑存储（Compact Storage）"机制，这又是怎样的黑科技？
终极选型指南：在实际架构中，HashMap、LinkedHashMap、TreeMap、ConcurrentHashMap 究竟该如何抉择？