HashMap 容量必须是2的幂，是为了用高效位运算 hash & (n - 1) 替代慢速取模 hash % n，确保索引计算快且分布均匀；同时支持扩容时仅通过 (hash & oldCap) == 0 判断节点去向，避免重复哈希。
理解 HashMap 底层原理，关键不是死记源码，而是抓住「它怎么把 key 快速变成数组下标」和「冲突之后怎么不拖慢查询」这两个核心问题。JDK 1.8 的结构已经稳定多年，掌握以下几点就能应对绝大多数开发和面试场景。
数组容量为什么必须是 2 的幂次方
这是为了用位运算替代取模，提升索引计算效率。HashMap 实际通过 hash & (n - 1) 得到数组下标（n 是数组长度），前提是 n 是 2 的幂。比如容量为 16（即 2⁴），n−1 就是 15（二进制 1111），& 运算天然截断高位，效果等同于 hash % 16，但快得多。如果容量不是 2 的幂，这套逻辑就失效，所以构造时会自动扩容到最近的 2 的幂。
哈希值为什么要扰动：h ^ (h >>> 16)
Java 的 hashCode() 返回的是 32 位 int，但低 16 位往往承载了更多有效区分信息，高 16 位可能大量重复（尤其对字符串等常见 key）。扰动函数让高半区参与低位运算，使最终 hash 值更均匀分布，显著降低桶冲突概率。例如：
原始 hash = 0xABCDEF01（低 16 位是 EF01），右移 16 位得 0x0000ABCD，异或后得到新 hash，高低特征混合，散列质量更高。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
链表何时转红黑树？不只是长度 ≥ 8
两个条件必须同时满足：
• 当前桶中链表节点数 ≥ 8
• 整个 HashMap 的数组容量 ≥ 64
缺一不可。设计意图很明确：小容量数组本身桶少、冲突多，盲目树化反而增加维护成本；只有在大表且局部严重冲突时，才值得用红黑树换 O(log n) 查询。反过来，当树中节点 ≤ 6 时，会自动退化回链表——避免“为了一点点性能提升，长期扛着树结构开销”。
扩容机制如何影响性能与线程安全
扩容发生在 size > threshold（即 capacity × loadFactor，默认 16×0.75=12）时。新数组容量翻倍（如 16→32），所有元素 rehash 重分配。这个过程：
• 是全量复制，耗时明显，应尽量在初始化时预估容量（如 new HashMap(1024)）
• JDK 1.8 改为尾插法，避免 1.7 头插法在并发扩容中导致的环形链表和死循环
• 单线程下安全，但多线程 put 可能丢失数据或引发无限扩容，所以非线程安全不是口号，是实打实的底层限制
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
