扰动函数的核心作用是将hashcode高16位异或到低16位，使高位信息参与低位索引计算，弥补(n−1)&hash仅依赖低位导致的分布不均问题，从而降低哈希冲突概率。
扰动函数不是让哈希值更“随机”，而是让高位信息落到低位，补上索引计算时被忽略的部分。HashMap 用 (n−1) & hash 算下标，本质只看 hash 的低几位——如果原始 hashCode 高位千差万别、低位却高度重复，就会大量挤进相同桶里。扰动函数正是为解决这个短板而生。
为什么只靠 hashCode 容易撞桶？
Java 中 key.hashCode() 返回一个 32 位 int，理论有约 40 亿种取值。但实际 HashMap 初始容量通常只有 16、32 或 64。数组长度 n 是 2 的幂，(n−1) & hash 实际等价于取 hash 的低 log₂n 位。比如 n=16（即 2⁴），就只取 hash 最低 4 位——高位再丰富也完全没参与索引运算。
常见问题：
- String 的 hashCode 计算中，低位容易受结尾字符影响，而高位反映开头字符；若一批 key 仅结尾不同（如 order1、order2…），低位趋同，高位虽异但被丢弃 → 撞桶集中
- Integer 类型的 key 若是连续小整数（1, 2, 3…），hashCode 就是自身，二进制低位规律性强 → 大量映射到相邻甚至同一桶
扰动函数怎么“补位”？
核心代码：hash = h ^ (h >>> 16)，其中 h 是原始 hashCode。
这个操作把高 16 位右移后与低 16 位异或，结果仍为 32 位整数，但关键变化是：原高 16 位的信息被“折叠”进了低 16 位。即使原始 hash 低位雷同，只要高位有差异，异或后低位也会产生差异。
举个简例（用 8 位示意）：
- keyA.hashCode = 1011 0001（高4位 1011，低4位 0001）
- keyB.hashCode = 1100 0001（高4位 1100，低4位相同：0001）
- 右移 4 位后：keyA→0000 1011，keyB→0000 1100
- 异或结果：keyA→1011 0001 ^ 0000 1011 = 1011 1010；keyB→1100 0001 ^ 0000 1100 = 1100 1101
- 现在低 4 位变成 1010 和 1101 —— 不再相同，后续
& (n−1)更可能分到不同桶
它和扩容、链表/红黑树是什么关系？
扰动函数是第一道防线，作用在哈希值生成阶段；扩容和结构升级是后续兜底手段：
- 扰动函数不改变桶数量，也不建链表，只让现有桶承载更均衡
- 当负载因子超阈值（默认 0.75），扩容将数组长度翻倍 →
(n−1)二进制多一位，索引能多用一位 hash 位，配合扰动效果进一步放大 - 单桶链表过长（≥8）且数组够大（≥64）时转红黑树，这是冲突已发生后的组织优化，非预防手段
这不是万能解药，也有边界
扰动函数轻量高效，但不能突破哈希函数本身的质量限制：
- 若 key 自定义的 hashCode 始终返回固定值（如始终 return 42），扰动后还是 42 → 所有 key 进同一桶
- 若大量 key 的 hashCode 高低位完全镜像对称（极少见），异或后可能归零或趋同 → 理论上存在弱化场景，实践中几乎不发生
- 它只改善分布均匀性，不解决“不同 key 映射到同一 hash”的根本碰撞；真要杜绝，得用完美哈希或增大空间，不现实
