手写hashmap实战：1.定义node与table数组，用math.abs(hash)%len算索引；2.用"aa"/"bb"触发冲突并观察链表；3.小容量触发扩容，验证rehash后节点分散；4.避坑：key须不可变、禁多线程put、预设容量、null key走特殊分支。
写一个实用、可落地的 HashMap 实战教程，关键不是堆砌概念，而是带人动手走通“存—取—冲突—扩容”这一完整链路，同时暴露真实开发中会踩的坑。下面分四块展开，每块都对应一个必须亲手验证的动作。
从零手写一个能跑通的数组+链表版
先跳过红黑树和并发安全，聚焦最核心逻辑：
- 定义一个 Node
静态内部类，含 key、value、next 字段 - 声明 Node
[] table 数组，默认长度 16；构造时直接 new 出来 - 哈希计算别直接用
k.hashCode() % table.length—— 负数取模会出负索引，改用(k.hashCode() & 0x7fffffff) % table.length或更稳妥的Math.abs(k.hashCode()) % table.length - put 时：算出 index → 检查 table[index] 是否为空 → 空则新建 Node 直接放；不为空则遍历链表比 key（先判 == 再判 equals）→ 找到就覆盖 value，没找到就头插或尾插新节点
- get 时：同样算 index → 从 table[index] 开始逐个比 key → 找到返回 value，否则返回 null
亲手制造并解决一次哈希冲突
光讲“冲突不可避免”太虚，得让人亲眼看到：
- 准备两个 key："Aa" 和 "BB" —— 它们的
hashCode()在 Java 中恰好都是 2112，用默认长度 16 时都会落到 index=0 - 往 map 里先后 put 这两个键值对，再用 debugger 或打印 table[0] 链表结构，确认它确实是两个节点串起来的
- 故意在 get("BB") 前把第一个节点的 key 改成 null（模拟误操作），观察是否因 equals 判空失败而查不到 —— 这就是为什么 key 必须不可变、且 equals/hashCode 要配套重写
让扩容过程“看得见”
扩容是 HashMap 性能拐点，但多数人只记“size > capacity × 0.75”，却不知它怎么动：
- 初始化时传入小容量，比如
new MyHashMap(4)，负载因子保持 0.75 - 连续 put 4 个不同 key（确保不冲突），第 4 个插入后 size=4，threshold=4×0.75=3，触发扩容
- 在扩容方法里加日志：
System.out.println("扩容前 size=" + size + ", table.length=" + table.length)，再打印新 table.length - 重点验证 rehash：旧 table[0] 的链表节点，扩容后是否真的散到了新 table[0] 和 table[4]（假设新长度为 8）？手动算 (oldHash & 7) 和 (oldHash & 15) 对比即可
实战避坑清单（不是理论，是真会报错的点）
这些不是“可能有问题”，而是上线后立刻抛异常或丢数据：
- key 用了 ArrayList：插入后修改 list 内容 → hashCode 变了 → get 时算出的 index 和 put 时不一致 → 查不到。解法：key 必须是 String、Integer 等不可变类型，或自定义类时严格重写 hashCode/equals 且不暴露可变字段
- 多线程 put 同一个 key：没加锁时，两个线程都判断 table[i] 为空，都新建 Node 赋值 → 后者覆盖前者 → 数据丢失。不要自己加 synchronized，高并发直接换 ConcurrentHashMap
- 初始化容量乱设：要存 1000 个元素却用默认 16 → 触发 5 次扩容（16→32→64→128→256→512），每次 rehash 搬数据，CPU 拉满。应预估：1000 ÷ 0.75 ≈ 1334 → 取最近 2 的幂 2048
- 误以为 null key 是特殊处理：其实 null key 的 hash 固定为 0，永远存在 table[0]，但 get 时会单独走 if (key == null) 分支 —— 所以你重写的 hashCode 方法里千万别对 null 抛 NPE
