hashmap底层是动态演化结构：空数组→初始化为16→冲突挂链表→链表≥8且数组≥64才树化→节点≤6退化回链表；哈希值经高位扰动后用(n-1)&hash定位，要求容量为2的幂；线程不安全具结构性，涉及成环、丢失更新等；初始容量应按(int)(n/0.75)+1预估。
别把“数组+链表+红黑树”当成静态拼图
很多人一说HashMap底层，脱口就是“JDK8是数组加链表再加红黑树”。这没错，但错在把它理解成固定结构。实际它是动态演化的：初始是空数组；第一次put后初始化为长度16的数组；发生哈希冲突时挂链表；当某个桶中链表长度≥8 且 数组长度≥64时，才触发树化；而树节点≤6时又会退化回链表。
面试中被问“为什么不是7或9”，核心不在数字本身，而在泊松分布——哈希均匀前提下，链表长度达到8的概率约6×10⁻⁸，几乎只会在哈希函数失效（比如key重写了错误的hashCode）时出现。所以树化不是常态优化，而是兜底机制。
别混淆“哈希值”和“数组下标”的计算逻辑
Key的hashCode()返回的是32位int，但HashMap不会直接用它当数组下标。JDK8中先做高位扰动：(h = key.hashCode()) ^ (h >>> 16)，再用(n-1) & hash代替取模运算定位桶位置。这个设计有两个关键点：
- 扰动是为了让高16位也参与索引计算，缓解低位相同导致的聚集问题（比如对象默认hashCode只依赖内存地址低几位）
- (n-1) & hash能正确工作的前提是数组长度必须是2的幂——扩容始终翻倍，保证了n-1是形如111...1的二进制数
别以为“线程不安全”只是不能并发put
HashMap的线程不安全远不止数据覆盖那么简单。JDK7中多线程扩容可能引发链表成环，导致get()无限循环；JDK8虽修复了成环，但依然存在丢失更新、size不准、甚至数据不一致等问题。
重点在于：它的不安全是结构性的——没有原子性保障、无可见性控制、put操作本身也不是一个不可分割的动作（计算hash→找桶→插入→可能扩容→可能树化）。所以不能靠“我只读不写”或“我加了synchronized块”来侥幸，该用ConcurrentHashMap就用，该用Collections.synchronizedMap就明确包装。
别忽略容量设置和负载因子的实际影响
默认初始容量16、负载因子0.75看似随意，实则权衡了空间与时间：0.75是在哈希分布较均匀时，链表平均长度约1~2的临界点，此时冲突可控，查找仍接近O(1)。
常见误区是认为“设大点就省事”。但初始容量过大浪费内存；过小又频繁扩容（每次扩容要rehash全部元素）。更务实的做法是预估key数量N，按(int)(N / 0.75) + 1设置初始容量，避免前几次扩容。
例如存1000个用户ID，建议写：new HashMap(1334)，而不是new HashMap(1000)或直接new HashMap()。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
