HashMap底层是数组+链表+红黑树的复合结构：数组为桶主体，链表解决哈希冲突，当链表长≥8且数组长度≥64时转红黑树以优化查询；put过程含hash扰动、位运算定位、碰撞处理、树化判断与扩容检查五步。
直接说重点：面试官问 HashMap，不是考你背了多少八股文，而是看你会不会拆解问题、能不能讲清设计背后的权衡。应对连环炮的关键，是把底层逻辑串成一条线——从“怎么放进去”，到“怎么找出来”，再到“放不下怎么办”“多人抢着放会怎样”。
一、先稳住第一问：HashMap 底层结构是什么？
别只答“数组加链表”。要带上下文：
- 主体是一个叫 table 的 Node 数组，每个位置叫一个“桶（bucket）”
- 桶里存的是 Node 节点，包含 key、value、hash 值和 next 引用
- 发生哈希碰撞时，节点以链表形式尾插在同一个桶下（JDK 8 起）
- 当链表长度 ≥ 8 且 数组长度 ≥ 64 时，链表转为红黑树；节点 ≤ 6 时再退化回链表
二、被追问“为什么用红黑树，而不是 AVL 或跳表？”
这不是比技术参数，而是考你理解设计意图：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 红黑树的插入/删除平均性能比 AVL 更平稳，更适合写多读少的 Map 场景
- 它比跳表内存更紧凑（不用维护多层指针），也更容易和现有链表结构兼容
- 树化阈值设为 8 是因为泊松分布计算表明：随机 hash 下，链表长度达到 8 的概率仅约千万分之六，是个统计上极小的“异常信号”
- 要求容量 ≥ 64 才树化，是因为此时扩容收益变小，而树化能更有效地缓解局部冲突
三、再深一层：“put 过程到底做了什么？”
按执行顺序讲清楚五个关键动作：
立即学习“Java免费学习笔记（深入）”；
- hash 计算：取 key.hashCode()，再做扰动 h ^ (h >>> 16)，让高位参与索引计算，减少低位重复导致的碰撞
- 定位桶位：用 (n - 1) & hash 替代取模，前提是数组长度为 2 的幂（如 16、32、64）
- 判空入桶：桶为空，直接新建 Node 放入
- 处理碰撞：桶非空，先比 hash，再用 equals 判断 key 是否相同；相同则覆盖 value；不同则尾插或走树化逻辑
- 触发扩容：插入后 size > capacity × 0.75（默认加载因子），且当前容量未达最大值（1
四、压轴题：“多线程 put 为什么可能死循环？”
这题直击 JDK 7 和 JDK 8 的根本差异：
- JDK 7 使用头插法，扩容时多个线程并发 rehash，可能造成链表节点反向闭环，get 时无限遍历
- JDK 8 改为尾插法，消除了该死循环风险，但仍不线程安全：put 可能覆盖、size 统计不准、甚至丢失数据
- 正确方案不是“自己加锁”，而是用 ConcurrentHashMap —— 它通过分段锁（JDK 7）或 CAS + synchronized（JDK 8+）保证安全，且保留了高并发下的性能
