扰动函数通过(h = key.hashcode()) ^ (h >>> 16)将高16位异或到低16位，使高位信息参与索引计算，缓解因低位重复导致的桶分布不均；它必须搭配2的幂长度才能生效，因只有此时(n-1)&hash才等价取模并保留扰动后的低位随机性。
HashMap 的 hash() 扰动函数本身不直接“消除”碰撞，而是让原本容易聚集的哈希值在低位更分散，从而降低因低位重复导致的伪碰撞。
扰动函数做了什么
它对非 null 的 key 执行：(h = key.hashCode()) ^ (h >>> 16)
也就是把原始 32 位 hashCode 的高 16 位，异或到低 16 位上。
很多对象（比如小字符串、自增 ID 的 POJO）的 hashCode() 高位长期为 0 或变化极小，低位却呈现明显规律（如 1, 2, 3, 4…）。如果直接用这些低位参与索引计算，相当于只用了 4–5 个 bit 做散列，大量 key 会挤进少数几个桶里。
扰动后，高位信息被“搅”进低位，让最终参与寻址的低位更随机，分布更均匀。
为什么必须搭配 2 的幂长度
索引真正靠的是：i = (n - 1) & hash
- 只有当 n 是 2 的幂时，
n - 1才是形如0b111...1的数，& 运算才等价于取模且能保留扰动后的低位信息 - 如果 n=10，就得用
hash % 10，高位扰动完全白费——% 运算只看数值整体，不保留位模式 - new HashMap(100) 实际容量会自动变成 128，这是为了确保满足 2 的幂要求
它不能解决什么
扰动函数不是万能的：
- 无法避免“天然碰撞”，比如
"Aa"和"BB"的hashCode()本来就是一样的，扰动后还是相同 - 如果你的
hashCode()实现太弱（比如只返回固定值或仅依赖一个恒定字段），扰动再强也救不了分布 - 它不替代正确实现
equals()和hashCode()的责任——这两者必须逻辑一致，否则 HashMap 行为不可预测
实际效果举例
假设你用 new User(1), new User(2), ..., new User(16) 作 key，且 User.hashCode() 直接返回 id：
- 原始 hash 序列：1, 2, 3, …, 16
- 数组长度 16 → 索引全为
hash & 15→ 结果就是 1, 2, 3, …, 0 → 每个桶一个元素，看似均匀，但只要扩容到 32，新索引仍是低位直落，规律仍在 - 扰动后，比如 1 →
1 ^ 0 = 1，但 65537 →65537 ^ 1 = 65536，& 15 后从 1 变成 0 ——高位变化开始影响结果，打破线性映射惯性
这种“打破惯性”的能力，才是它降低中长期碰撞率的关键。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
