前言：从"逻辑世界"到"物理现实"的跨越
在前四篇的连载中，我们犹如在 HashMap 的逻辑图纸上尽情探索，从 2 的幂次方设计、0.75 的加载因子，一路讲到了扩容机制、红黑树退化以及并发安全。我们掌握了它在内存中如何运转、如何应对极端场景。
然而，一个成熟的底层数据结构，不仅要应对内存中的逻辑挑战，还要跨越"持久化"的鸿沟（序列化），甚至在 JDK 的历次版本更迭中不断进化。更重要的是，在真实的工程架构中，HashMap 并非万能钥匙。
本篇章作为整个系列的收官之作，将带你跳出纯粹的逻辑推演，深入 JVM 的物理内存，揭开 HashMap 序列化重写的"黑魔法"，探索 JDK 9+ 的底层黑科技，并最终为你提供一份在复杂架构下的"终极选型指南"。
第十四章：内存布局------Node 对象在 JVM 中的物理形态
我们在源码中看到的是 Node<K,V>，但在 JVM 的堆内存中，它究竟长什么样？理解这一点，对于评估 HashMap 的内存开销至关重要。
14.1 一个 Node 究竟占用多少字节？
【定义】
在 64 位 JDK 且开启了指针压缩（默认开启）的环境下，一个普通的链表 Node 对象占用 32 字节。
【通俗讲解：内存的解剖学】
- 对象头（Object Header）：12 字节（8 字节 Mark Word + 4 字节 Klass Pointer）。
- 四个核心字段 ：
hash（int，4字节）、key（引用，4字节）、value（引用，4字节）、next（引用，4字节），共计 16 字节。 - 内存对齐 ：12 + 16 = 28 字节，根据 JVM 8 字节对齐规则，向上取整为 32 字节。
【深度追问：红黑树的 TreeNode 呢？】
TreeNode 继承自 LinkedHashMap.Entry，它不仅包含了 Node 的所有字段，还额外增加了 parent、left、right、color 等用于维护红黑树结构的指针和状态位。因此，一个 TreeNode 对象通常占用 48 字节甚至更多。这也从侧面印证了为什么 HashMap 只有在极端冲突下才舍得动用红黑树------因为它的内存成本极其高昂。
第十五章：序列化黑魔法------为什么 HashMap 要重写 writeObject？
在 Java 中，如果一个类实现了 Serializable 接口，默认情况下 JVM 会通过反射将对象的所有非瞬态字段原封不动地写入流中。但 HashMap 却偏偏重写了 writeObject 和 readObject。
15.1 拒绝"盲目"序列化
【定义】
HashMap 重写了序列化方法，拒绝序列化底层的 Node<K,V>[] table 数组 ，而是仅仅序列化了 size 和所有的 Key-Value 键值对。
【通俗讲解：为什么不能直接拷贝数组？】
- 空间浪费：由于 0.75 的加载因子，数组中永远有 25% 以上的空间是空的（null 槽位）。如果直接序列化整个数组，会写入大量无意义的 null，极其浪费网络带宽和磁盘空间。
- 版本兼容：HashMap 的底层结构在 JDK 7 和 JDK 8 之间发生了翻天覆地的变化（链表变红黑树）。如果直接序列化物理结构，跨版本反序列化将是一场灾难。
【反序列化的重生】
在 readObject 中，HashMap 会先读取 size，然后重新创建一个合适大小的空数组，接着逐个读取 Key-Value，调用内部的 putVal 方法重新计算哈希并插入。这确保了无论旧版本是什么结构，新版本都能完美还原。
第十六章：JDK 9+ 的隐秘优化------紧凑存储（Compact Storage）
HashMap 的进化从未停止。从 JDK 9 开始，为了应对海量小对象的内存压力，JDK 引入了"紧凑字符串"和"紧凑集合"的优化。
16.1 打破 2 的幂的绝对统治？
【定义】
在 JDK 9+ 中，当 HashMap 的元素被大量删除，导致实际元素数量远低于容量时，JVM 可能会在内部触发**"紧凑化（Compact）"**操作，将数组长度缩小到刚好能容纳现有元素的大小（甚至不再严格强制为 2 的幂，或者在内部采用更紧凑的数组表示）。
【通俗讲解：仓库的"断舍离"】
以前的 HashMap 只能"膨胀"不能"收缩"。如果你的 HashMap 曾经存过 100 万个元素（容量扩到了 200 万），后来删得只剩 100 个，那 200 万的巨大数组依然会死死占据内存。JDK 9+ 的紧凑存储机制，允许 JVM 在后台默默地将这个庞大的数组"缩水"，极大地缓解了内存泄漏和碎片化问题。
第十七章：终极选型指南------在复杂架构下的抉择
至此，我们已经把 HashMap 扒得连底裤都不剩了。但在真实的工程开发中，面对千变万化的业务需求，我们该如何在众多的 Map 实现中做出最正确的抉择？
17.1 需要保证插入/访问顺序？ -> LinkedHashMap
【适用场景】 ：LRU 缓存淘汰算法、按配置顺序读取 YAML/JSON 文件。
【底层原理】 ：它在 HashMap 的基础上，为每个 Node 增加了一对双向链表指针（before 和 after），将所有节点串联起来。
17.2 需要 Key 的自然排序？ -> TreeMap
【适用场景】 ：需要按照 Key 的范围进行查询（如时间轴数据）、排行榜。
【底层原理】 ：彻底抛弃了哈希表，底层采用红黑树 实现。查询时间复杂度稳定在 O(logn)O(\log n)O(logn)，但失去了 O(1)O(1)O(1) 的极致性能。
17.3 多线程高并发环境？ -> ConcurrentHashMap
【适用场景】 ：全局缓存、分布式会话共享、高频读写。
【底层原理】 ：JDK 8 采用 Node数组 + 链表/红黑树 + CAS + synchronized。它摒弃了 JDK 7 的 Segment 分段锁，将锁的粒度细化到了"桶（Node）"级别。在读操作时完全无锁，写操作时仅锁定当前桶的头节点，实现了极高的并发吞吐量。
17.4 分布式环境下的海量数据？ -> 分布式哈希表（DHT）
【适用场景】 ：Redis 集群、Elasticsearch 分片。
【底层原理】：当单机内存无法承载时，必须将 HashMap 的思想分布式化。通过**一致性哈希（Consistent Hashing）**算法，将海量 Key 均匀打散到多台物理节点上，彻底打破单机内存瓶颈。
终章：致敬数据结构的设计哲学
回顾这五篇连载，我们从一行行枯燥的源码中，看到了计算机科学家们对"极致性能"的狂热追求。
- 为了快，他们把取模变成了
& (n-1)的位运算； - 为了稳，他们设计了 8 与 6 的防抖动树化机制；
- 为了安全，他们从 JDK 7 的头插法血泪中涅槃，走向了 JDK 8 的尾插法与 CAS；
- 为了省，他们重写了序列化，拒绝了数组的盲目拷贝。
HashMap 绝不仅仅是一个用来存数据的容器，它是空间与时间的博弈，是概率与统计的艺术，更是工程妥协与极致优化的完美结晶。
希望这五篇连载，能让你在下一次敲下 new HashMap<>() 时，心中不仅有 API 的熟练，更有对底层宇宙的敬畏。
附：hashmap常见面试题
Q1：HashMap 的底层数据结构是什么？JDK 1.7 和 1.8 有什么核心区别？
答： JDK 1.7 底层是"数组 + 链表"；JDK 1.8 优化为"数组 + 链表 + 红黑树"。引入红黑树是为了解决极端哈希冲突下，链表过长导致查询时间复杂度从 O(1)O(1)O(1) 退化为 O(n)O(n)O(n) 的问题，树化后可将最坏查询时间优化为 O(logn)O(\log n)O(logn)。此外，JDK 1.8 将链表插入方式从头插法改为尾插法，解决了多线程扩容时的死循环问题，并简化了哈希扰动函数。
Q2：为什么 HashMap 的数组长度（容量）必须是 2 的幂次方？
答： 核心原因有三：一是为了利用位运算 hash & (n - 1) 替代低效的取模运算 hash % n，极大提升寻址效率；二是当 n 为 2 的幂时，n - 1 的二进制全为 1，能保证哈希值均匀分布，减少冲突；三是为 JDK 1.8 扩容时的"高低位拆分"算法提供便利，无需重新计算哈希即可确定元素新位置。
Q3：HashMap 的负载因子为什么默认是 0.75？
答： 0.75 是时间与空间成本的折中选择。如果设为 1（太高），数组过满会导致哈希冲突概率急剧上升，链表变长，查询性能严重退化；如果设为 0.5（太低），虽然查询极快，但会导致数组频繁扩容，且 50% 的内存空间被白白浪费。
Q4：HashMap 什么时候会触发扩容？JDK 1.8 的扩容机制有什么优化？
答： 当元素个数 size 超过阈值（capacity * loadFactor）时触发扩容，每次扩容容量翻倍。JDK 1.8 的核心优化在于：扩容时节点迁移无需重新计算哈希，只需通过 hash & oldCap 判断高位是 0 还是 1，即可决定元素留在原下标还是移动到"原下标 + 旧容量"，大幅提升了扩容效率。
Q5：为什么链表长度达到 8 才转为红黑树？且为什么要求数组容量 >= 64？
答： 根据泊松分布，在 0.75 的负载因子下，链表长度达到 8 的概率极低（约千万分之六），红黑树节点占用内存是链表的近两倍，因此只在极端冲突下才转树，以平衡空间开销。同时，当链表达到 8 但数组容量 < 64 时，HashMap 会优先选择扩容而不是树化，因为此时扩容更能有效缓解冲突。
Q6：红黑树的退化阈值为什么是 6，而不是 8？
答： 这是为了防止结构频繁切换带来的性能损耗（防抖动）。如果树化和退化阈值都是 8，当桶内元素在 8 个左右频繁增删时，底层会在链表和红黑树之间疯狂转换。设为 6 可以在 6、7、8 之间形成一个缓冲地带，保证数据结构的稳定性。
Q7：HashMap 是线程安全的吗？在多线程下使用会有什么问题？
答： 不是线程安全的。在 JDK 1.7 中，多线程并发扩容时由于采用头插法，极易导致链表形成环形结构，执行 get 时引发 CPU 100% 的死循环；在 JDK 1.8 中，虽然改为尾插法解决了死循环问题，但并发 put 时仍会导致数据覆盖（丢失更新）和 size 计数不准确等严重问题。
Q8：作为 HashMap 的 Key，重写 equals() 和 hashCode() 有什么要求？
答： 必须同时重写这两个方法，并遵守契约：如果两个对象 equals() 返回 true，它们的 hashCode() 必须完全相等。如果不重写，两个业务上相等的 Key 可能会因为默认的哈希值（基于内存地址）不同，被分配到不同的哈希桶中，导致重复插入或无法获取值，破坏键唯一性规则。
Q9：HashMap 的 put 方法完整执行流程是什么？
答： ① 计算 Key 的哈希值（null 键固定为 0）；② 若数组为空则先初始化；③ 通过 hash & (n-1) 定位目标桶；④ 若桶为空，直接新建节点放入；⑤ 若桶不为空，判断首节点是否匹配，匹配则覆盖旧值；⑥ 若不匹配且为链表，则遍历到尾节点尾插，若链表长度 ≥ 8 则尝试树化；若为红黑树节点，则调用树插入方法；⑦ 插入成功后 size++，若超过阈值则触发扩容。
Q10：为什么经常使用 String 作为 HashMap 的 Key？
答： 因为 String 是不可变类（Immutable），其内部的 char[] 被 final 修饰，且 hashCode 在首次计算后会被缓存。这保证了 Key 在存入 HashMap 后哈希值永远不会改变，完美契合了 HashMap 对 Key 的要求，避免了因 Key 属性修改导致的数据丢失。
Q11：如果所有的 Key 的 hashCode 都相同，HashMap 会怎样？
答： 所有的 Key 都会落入同一个桶，底层数组退化为一个巨大的单向链表。当链表长度达到 8 且数组长度 >= 64 时，会转为红黑树。但由于 Hash 相同，红黑树的比较将完全依赖 equals() 或 compareTo()，查询时间复杂度彻底退化为 O(logn)O(\log n)O(logn) 或 O(n)O(n)O(n)。
Q12：HashMap 和 ConcurrentHashMap 有什么区别？如何选择？
答： HashMap 是非线程安全的，适合单线程环境，性能极高；ConcurrentHashMap 是线程安全的，JDK 1.8 采用 CAS + synchronized 锁住链表头节点，锁粒度极细，适合高并发环境。在多线程读写场景下，应首选 ConcurrentHashMap，而不是使用全局锁的 Hashtable 或包装后的 synchronizedMap。
Q13：HashMap 的 key 和 value 可以为 null 吗？
答： 可以。HashMap 允许存储一个 Key 为 null 的元素（固定存储在数组下标 0 的位置），以及多个 Value 为 null 的元素。当 Key 为 null 时，HashMap 不走 hashCode() 方法，直接返回 0 作为哈希值。
Q14：HashSet 和 HashMap 有什么关系？
答： HashSet 底层就是基于 HashMap 实现的。HashSet 中的每个元素，实际上是作为 HashMap 的 Key 存储的，而 Value 则是一个固定的静态常量 PRESENT。
Q15：在 64 位 JDK 中，HashMap 的一个普通 Node 对象占用多少内存？
答： 占用 32 字节。包括 12 字节的对象头，16 字节的四个核心字段（hash、key、value、next 各 4 字节），以及 4 字节的内存对齐填充。而红黑树的 TreeNode 由于增加了 parent、left、right 等指针，通常占用 48 字节甚至更多。
Q16：HashMap 为什么重写了 writeObject 和 readObject？
答： 为了拒绝"盲目"序列化底层的 Node[] table 数组。因为数组中通常有大量 null 槽位，直接序列化极其浪费空间。重写后，仅序列化 size 和有效的 Key-Value 键值对，在反序列化时再通过 putVal 重新构建哈希表，既节省了空间，又保证了跨 JDK 版本的兼容性。
Q17：computeIfAbsent 在 HashMap 中是绝对安全的吗？
答： 不是。如果在 computeIfAbsent 的 Lambda 表达式内部，又对同一个 HashMap 进行了修改操作（如 put），会触发内部结构的并发修改，导致链表结构破坏、死循环或抛出 ConcurrentModificationException。
Q18：为什么大部分 hashCode 方法使用 31 作为乘数？
答： 因为 31 是一个不大不小的素数，且刚好等于 25−12^5 - 125−1。在底层计算时，31 * i 可以被 JVM 优化为 (i << 5) - i，利用位移运算极大地提升了计算效率，同时素数能有效降低哈希冲突的概率。
Q19：如果我指定 HashMap 的初始长度为 17，它会初始多大的长度？为什么？
答： 它会初始化为 32 。因为 HashMap 强制要求容量必须是 2 的幂。源码中通过 tableSizeFor(int cap) 方法，利用无符号右移和按位或运算，找到大于等于 17 的最小的 2 的幂，即 32。
Q20：已经存储到 HashMap 中的 Key 的对象属性是否可以修改？为什么？
答： 绝对不可以。如果该属性参与了 hashCode 的计算，修改后会导致 Key 的哈希值发生变化。而 HashMap 在 put 时已经根据旧的哈希值确定了存储位置，修改后调用 get 或 remove 时，会使用新的哈希值去查找，导致"找不到"数据，造成数据"凭空消失"。
Q21：HashMap 的哈希扰动函数 h ^ (h >>> 16) 有什么作用？
答： 核心作用是让哈希值的高 16 位也参与到索引计算中。因为数组长度通常较小，hash & (n-1) 实际上只用了哈希值的低位。通过高 16 位与低 16 位异或，能在不增加计算成本的前提下，让高位信息影响低位，大幅降低哈希冲突的概率。
Q22：HashMap 和 Hashtable 的核心区别是什么？
答： ① 线程安全：Hashtable 方法加了 synchronized，HashMap 没有；② Null 值：Hashtable 不允许 Key/Value 为 null，HashMap 允许；③ 初始容量：Hashtable 默认 11，HashMap 默认 16；④ 扩容机制：Hashtable 扩容为 2n + 1，HashMap 扩容为 2n；⑤ 底层结构：Hashtable 只有数组+链表，HashMap（JDK8）引入了红黑树。
Q23：HashMap 的 get 方法完整执行流程是什么？
答： ① 计算 Key 的哈希值；② 若数组为空或目标桶为空，直接返回 null；③ 若首节点匹配（hash 相同且 equals 为 true），直接返回；④ 若为红黑树节点，调用红黑树查找方法；⑤ 若为链表，则遍历链表逐个比对，找到则返回，遍历完未找到返回 null。
Q24：为什么 HashMap 的 remove 方法在删除后不立即缩容？
答： 因为缩容（缩小数组）需要重新计算所有元素的哈希并迁移，成本极高。HashMap 的设计哲学是"只增不减"，删除元素后仅将对应节点置为 null，数组容量保持不变。只有在极端场景下（如 JDK 9+ 的紧凑存储机制），JVM 才可能在后台进行优化。
Q25：HashMap 的 size() 方法是 O(1) 还是 O(n)？
答： 是 O(1) 。HashMap 内部维护了一个 size 变量，每次 put/remove 时都会同步更新，因此获取大小时直接返回该变量即可，无需遍历整个表。
Q26：为什么 HashMap 的 Node 类不实现 Comparable 接口，但红黑树却需要比较？
答： 因为 HashMap 本身不要求 Key 有序，Node 无需实现 Comparable。但在极端冲突转红黑树时，如果 Key 实现了 Comparable，红黑树会优先使用 compareTo 进行排序，避免仅靠 equals 导致的 O(n)O(n)O(n) 查找；若未实现，则退化为链表式的 O(n)O(n)O(n) 查找，这也是为什么建议 Key 实现 Comparable 的原因。
Q27：HashMap 在 JDK 9 之后有什么底层优化？
答： 引入了"紧凑存储（Compact Storage）"机制。当 HashMap 中大量元素被删除，实际元素数量远低于容量时，JVM 可能会在后台触发紧凑化操作，将数组缩小到刚好能容纳现有元素的大小，甚至不再严格强制为 2 的幂，极大缓解了内存碎片和浪费问题。
Q28：为什么 HashMap 的扩容阈值是 capacity * loadFactor，而不是固定值？
答： 因为 HashMap 的容量是动态变化的，每次扩容后容量翻倍。如果阈值是固定值，那么扩容后数组会长期处于半空状态，浪费空间；如果阈值随容量线性增长（即乘以负载因子），则能保证数组始终维持在一个合理的填充率，平衡查询性能与空间利用率。
Q29：HashMap 的 key 可以是可变对象吗？有什么风险？
答： 技术上可以，但极度危险。如果可变对象的属性参与了 hashCode 计算，且在 put 后被修改，会导致 get 时使用新的哈希值去查找，而数据实际存储在旧哈希值对应的桶中，造成数据"丢失"。因此，强烈建议使用不可变对象作为 Key。
Q30：HashMap 的 putAll 方法有什么性能陷阱？
答： 如果传入的 Map 元素数量极大，putAll 会逐个调用 putVal，可能触发多次扩容。优化建议：在 putAll 前，先调用 ensureCapacity 或手动初始化一个足够大的 HashMap，避免频繁扩容带来的数组拷贝开销。
Q31：HashMap 的 containsKey 和 get 有什么区别？
答： 逻辑上几乎一致，都是先算哈希、定位桶、再比对。区别在于返回值：containsKey 返回 boolean，get 返回 Value。但在极端情况下（Value 为 null），get 返回 null 无法区分是"Key 不存在"还是"Value 为 null"，而 containsKey 可以准确判断。
Q32：为什么 HashMap 的链表节点在 JDK 1.8 中改为尾插法？
答： 核心原因是为了解决 JDK 1.7 多线程扩容时的死循环问题。头插法在并发扩容时会反转链表顺序，极易形成环；尾插法保持原有顺序，从根本上杜绝了环形链表的产生。虽然 HashMap 本身仍非线程安全，但尾插法至少避免了最致命的 CPU 100% 死循环。
Q33：HashMap 的 merge 方法有什么作用？
答： merge(key, value, remappingFunction) 用于合并值。如果 Key 不存在，直接放入 Value；如果存在，则用 remappingFunction 计算新值（如 oldValue + newValue），若计算结果为 null 则删除该 Key。常用于词频统计、累加器等场景，比先 get 再 put 更安全高效。
Q34：HashMap 的 replace 和 put 有什么区别？
答： put 在 Key 不存在时会插入新键值对；replace 仅在 Key 已存在 时才更新 Value，若 Key 不存在则什么都不做。replace 更适合"仅更新已有配置"的场景，避免意外插入脏数据。
Q35：为什么 HashMap 的 hashCode 为 null 的 Key 固定放在下标 0？
答： 因为 null 没有 hashCode，无法进行 hash & (n-1) 运算。源码中对 null Key 做了特殊处理，直接返回 0 作为哈希值，因此 null Key 永远存储在数组的第一个位置（下标 0），查找时也直接定位到该位置，无需遍历。
Q36：HashMap 的 clear 方法是 O(1) 还是 O(n)？
答： 是 O(n) 。clear 方法会遍历整个 table 数组，将每个槽位的引用置为 null，以便 GC 回收。虽然不触发扩容，但元素越多，耗时越长。
Q37：为什么 HashMap 的 entrySet 返回的是视图而不是副本？
答： 为了节省内存。如果每次调用 entrySet 都拷贝一份，在海量数据下会引发 OOM。视图（View）直接引用底层数组，对视图的修改会直接反映到原 Map，但遍历时若原 Map 被修改，会抛出 ConcurrentModificationException（快速失败机制）。
Q38：HashMap 的 keySet 和 values 方法返回的集合有什么特点？
答： 它们都是底层 Map 的视图。keySet 是 Set（不允许重复），values 是 Collection（允许重复）。对它们的修改（如 remove）会直接作用于原 Map，但 add 操作会抛出 UnsupportedOperationException，因为无法仅通过 Key 或 Value 确定完整的键值对。
Q39：为什么 HashMap 的 hashCode 冲突时，不直接用链表长度判断，还要先比 hash？
答： 为了性能。equals 方法可能涉及复杂的业务逻辑（如字符串逐字符比较），而 hash 是 int 类型，比较成本极低。先比 hash 可以快速排除大部分不匹配的节点，只有在 hash 相同时才调用 equals，这是典型的"短路优化"。
Q40：HashMap 的 putIfAbsent 和 computeIfAbsent 有什么区别？
答： putIfAbsent 仅当 Key 不存在时才放入指定的 Value；computeIfAbsent 在 Key 不存在时，会执行一个 Lambda 函数来计算 Value。后者更适合 Value 需要动态计算（如数据库查询、复杂对象创建）的场景，避免了不必要的对象创建开销。
Q41：HashMap 的 forEach 方法在遍历过程中修改 Map 会怎样？
答： 会抛出 ConcurrentModificationException。HashMap 内部维护了 modCount 变量，每次结构修改都会递增。遍历时会检查 modCount 是否变化，若变化则立即抛出异常，防止遍历过程中数据结构被破坏导致不可预知的错误。
Q42：为什么 HashMap 的 size 变量不用 volatile 修饰？
答： 因为 HashMap 本身就不是线程安全的。即使 size 加了 volatile，也无法保证 put 和 size++ 的原子性，多线程下依然会丢失更新。因此，HashMap 的设计前提是单线程，无需为并发场景做额外的内存可见性保障。
Q43：HashMap 的 table 数组为什么用 transient 修饰？
答： 因为 table 是底层物理结构，包含大量 null 槽位，且结构随 JDK 版本变化。用 transient 阻止默认序列化，配合重写的 writeObject/readObject 实现自定义序列化，仅保存有效键值对，确保跨版本兼容和空间效率。
Q44：HashMap 的 loadFactor 可以在运行时修改吗？
答： 不可以。loadFactor 是构造时传入的 final 字段，一旦初始化就不可变。如果需要调整负载因子，必须创建一个新的 HashMap 并重新 putAll。
Q45：HashMap 的 threshold 变量有什么作用？
答： threshold 是扩容的临界值，等于 capacity * loadFactor。每次 put 后，若 size > threshold，则触发扩容。扩容后，threshold 会随之更新为新的 capacity * loadFactor，无需每次计算，提升性能。
Q46：为什么 HashMap 的 hash 方法不直接返回 key.hashCode()？
答： 因为 key.hashCode() 可能分布极不均匀（如所有 Key 的 hashCode 都相同）。扰动函数 h ^ (h >>> 16) 能让高位信息影响低位，使哈希值在数组范围内分布更均匀，降低冲突概率，这是 HashMap 性能的关键保障。
Q47：HashMap 的 Node 类为什么是静态内部类？
答： 因为 Node 不需要访问外部类 HashMap 的实例成员。静态内部类不持有外部类引用，可以独立创建，节省内存，也避免了潜在的外部类引用导致的内存泄漏。
Q48：HashMap 的 putVal 方法为什么是 private 的？
答： 因为 putVal 是内部核心逻辑，包含了哈希计算、桶定位、树化、扩容等复杂操作，不应暴露给外部。外部统一通过 put、putIfAbsent 等公开 API 调用，保证接口的稳定性和安全性。
Q49：HashMap 的 resize 方法在什么时候会被调用？
答： ① 初始化时（table 为 null）；② put 后 size > threshold 时；③ 链表长度 ≥ 8 但 capacity < 64 时（优先扩容而非树化）。resize 是 HashMap 动态调整容量的核心方法。
Q50：HashMap 的 treeifyBin 方法有什么前置条件？
答： ① 链表长度 ≥ 8；② 数组容量 ≥ 64。若容量 < 64，即使链表很长，也会优先调用 resize 扩容，而不是树化。这是为了避免在小数组上过早引入高内存开销的红黑树。
Q51：HashMap 的 untreeify 方法在什么时候触发？
答： 当红黑树节点数 ≤ 6 时，会调用 untreeify 将红黑树退化回链表。这是为了防止在临界值附近频繁转换结构，配合"防抖动"机制，保证数据结构稳定。
Q52：HashMap 的 TreeNode 为什么继承自 LinkedHashMap.Entry？
答： 因为 TreeNode 需要同时维护红黑树结构（parent/left/right）和链表结构（before/after），以支持 LinkedHashMap 的有序性。继承 LinkedHashMap.Entry 可以复用其双向链表指针