HashMap底层是数组+链表+红黑树：数组提供O(1)定位，链表解决哈希冲突，链表长度≥8且数组容量≥64时树化为红黑树以维持O(log n)查询效率，避免过度树化开销。
想在技术面试中把 HashMap 底层原理讲透、讲稳、讲出区分度，关键不是堆砌术语，而是用一条清晰的逻辑线串起“结构—行为—设计权衡—实战陷阱”四个层次。下面这几点，是面试官真正想听的“三层深挖”内容，也是多数人翻车的盲区。
一、底层结构不能只说“数组+链表+红黑树”
这句话人人会背，但面试官接着就会问：“为什么是这三个结构组合？能不能只用数组？链表什么时候转成红黑树？阈值为什么是8？”
- 数组是哈希桶（bucket）的载体，提供 O(1) 定位能力；但哈希冲突不可避免，所以需要链表兜底
- 链表过长（默认≥8）会导致查找退化为 O(n)，于是 JDK 8 引入红黑树优化最坏情况，降到 O(log n)
- 但红黑树开销大，所以不是“一冲突就上树”，而是先检查数组总长度是否 ≥64——不够长就先扩容，避免小表频繁树化
- 注意：树化阈值 8 和扩容阈值 0.75 是独立控制的两个参数，别混为一谈
二、哈希计算和索引定位要讲清两步关键转换
很多人只记得 hash(key) % table.length，但这是错的。JDK 8 实际用的是：
- 先调用 key.hashCode() 得到原始 hash 值（注意：null 键被特殊处理为 0）
- 再执行 (h = key.hashCode()) ^ (h >>> 16) —— 高低位异或，让低16位也参与扰动，减少低位哈希冲突
- 最后用 (n - 1) & hash 替代取模（要求 table.length 必须是 2 的幂），既快又均匀
如果 key 自定义了 hashCode() 但没重写 equals()，或者重写了 equals() 却忘了重写 hashCode()，放进 HashMap 就可能查不到——这是高频踩坑点。
立即学习“Java免费学习笔记（深入）”；
三、扩容机制必须说清“谁在扩、怎么扩、扩时风险在哪”
扩容不是简单复制，而是一次重新哈希（rehash）过程：
- 触发条件：size > threshold（即 capacity × loadFactor，默认 16×0.75=12）
- 新容量 = 旧容量 × 2，新 threshold = 新容量 × 0.75
- 每个桶里的节点要重新计算位置：原索引位置 or 索引 + 旧容量（因为新表长度翻倍，高位多了一位）
- JDK 7 扩容可能引发死循环（头插法+多线程），JDK 8 改为尾插法，规避该问题——这也是为什么 ConcurrentHashMap 在 JDK 8 不再用分段锁，而是用 CAS + synchronized 控制单个桶
四、结合场景反推设计意图，体现系统思维
面试官喜欢问：“为什么 HashMap 不是线程安全的？ConcurrentHashMap 又是怎么解决的？” 这是在考你能不能从问题出发倒推设计逻辑：
- HashMap 舍弃线程安全，换来了极致读写性能；ConcurrentHashMap 则用“锁粒度下沉”策略——JDK 8 中只对发生冲突的单个桶加锁，而不是锁整个 map
- 再往下挖一层：为什么不用 ReentrantLock 而用 synchronized？因为 synchronized 在 JDK 6+ 有锁升级优化，轻量级锁开销极小，更适合短临界区
- 延伸一句实际建议：业务中若只是读多写少且能保证单线程写，可用 Collections.synchronizedMap；真高并发场景才上 ConcurrentHashMap
不复杂但容易忽略。
