HashMap底层是数组+链表+红黑树的混合结构：哈希值经扰动运算后与（长度-1）按位与得索引；冲突时用链表，满足≥8节点且数组≥64则转红黑树；null键固定存于tab[0]；重写equals必须重写hashCode以保证哈希一致；非线程安全，并发下易出错。
HashMap底层用数组加链表/红黑树存储键值对
Java的HashMap不是单纯哈希表，而是一个“数组 + 链表 + 红黑树”的混合结构。它把key.hashCode()经过扰动运算后取模，映射到数组索引位置；冲突时先用链表串连节点，当链表长度≥8且数组长度≥64，就转为红黑树优化查找性能。
常见误解是“哈希值直接当索引”，其实会做两步处理：(h = key.hashCode()) ^ (h >>> 16)（高位参与运算），再& (table.length - 1)（等价于取模，但要求table.length必须是2的幂）。
- 数组长度永远是2的幂（如16、32、64），扩容时翻倍
- 链表转红黑树有双重条件：链表节点数≥8 且
table.length >= 64，缺一不可 - 红黑树退化回链表的阈值是节点数≤6（不是7）
put()过程中如何计算hash、定位桶、处理冲突
调用map.put(key, value)时，核心流程是：算hash → 定位tab[i] → 若为空直接插入；否则遍历链表/树，检查key.equals()；相同则覆盖value；不同则尾插或树插入。
注意key为null是特例：它固定被哈希为0，存在数组第0个位置（tab[0]），且只允许一个null键。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
-
hash()函数对null返回0，对非null对象执行高位异或扰动 - 数组索引计算用
hash & (length - 1)，不是%，所以初始容量必须是2的幂 - 链表插入是头插（JDK 7）还是尾插（JDK 8+）？JDK 8起统一为尾插，避免多线程扩容时死循环
为什么重写equals()必须重写hashCode()
如果两个对象equals()返回true，但hashCode()不同，它们会被分配到HashMap不同桶里，导致get()永远找不到——因为查找时先比哈希值，哈希不等直接跳过后续equals()判断。
典型错误：只重写equals()，没同步更新hashCode()逻辑，尤其在使用IDE自动生成时漏掉字段。
- 所有参与
equals()比较的字段，都必须参与hashCode()计算 - 推荐用
Objects.hash(f1, f2, f3)生成hashCode()，安全且简洁 - 字段含可变对象（如
List）时，要确认其hashCode()行为稳定（比如用ImmutableList）
并发场景下HashMap可能崩溃的三个关键点
HashMap本身不保证线程安全，多线程put()可能引发数据丢失、死循环（JDK 7）、或树化异常（JDK 8）。根本原因在于resize()和节点插入都未加锁，且依赖共享状态（如size、modCount、链表指针）。
即使只读操作，在扩容中途也可能看到不一致的结构（如部分桶已迁移，部分未迁移）。
- JDK 7中多线程put可能触发环形链表，
get()陷入死循环 - JDK 8中虽改用尾插，但并发resize仍可能导致节点丢失或重复
-
ConcurrentHashMap才是正确选择：JDK 8起用synchronized锁单个桶，而非全局锁
实际用的时候，别只盯着“存得快”，更要盯住hashCode()一致性、null键边界、以及是否真需要并发安全——很多所谓“并发问题”，其实是误用了非线程安全容器。
