扰动函数不解决哈希冲突，仅通过 h ^ (h >>> 16) 将高位信息混入低位，缓解因桶索引仅用低 k 位导致的聚集性冲突；它非银弹，需配合合理容量、高质量 hashCode 等措施。
扰动函数本身不解决哈希冲突，它只让原始 hashCode 的高位信息参与桶索引计算，从而在取模（或位与）时减少因低位重复导致的聚集性冲突。
为什么必须用 h ^ (h >>> 16) 而不是直接取模？
因为 HashMap 桶数组长度始终是 2 的幂（如 16、32、64），索引计算用的是 (n - 1) & hash，等价于 hash % n，但只保留了 hash 的低 k 位（比如 n=16 → 保留低 4 位）。如果 key 的 hashCode 低位规律性强（如连续 Integer、小范围 ID），就会大量映射到同一桶。
扰动函数把高 16 位右移后与低 16 位异或，相当于让高位“搅”进低位——哪怕原始 hashCode 低位全一样，异或后低位也会因高位不同而不同。
常见错误现象：
– 自定义 key 的 hashCode() 只依赖一个递增字段（如 id++），未重写 hashCode 或仅返回 id；
– 插入大量 new Person(1), new Person(2)… 后发现前几个桶特别长，其余桶几乎为空。
hash() 函数在 JDK 1.8 中的完整逻辑
源码中实际调用的是这个静态方法：
static final int hash(Object key) {
int h;
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}注意三点：
- 空 key 直接映射到桶 0，不走扰动
-
h >>> 16是无符号右移，确保高位补 0，避免负数干扰 - 异或（
^）是可逆、均匀、硬件友好的混合操作：相同值异或得 0，不同值异或结果分布接近随机
使用场景：当你怀疑哈希分布不均时，可以临时打印 key.hashCode() 和 HashMap.hash(key) 对比，看高位是否真的被“带下来”了。
扰动函数对不同 key 类型的实际影响
不是所有 key 都需要扰动，效果取决于原始 hashCode 的低位质量：
-
String：JDK 自带的hashCode已经是加权累加（s[0]*31^(n-1) + ...），低位较随机，扰动收益小但无害 -
Integer：hashCode就是自身值，连续整数 → 低位高度重复 → 扰动后明显分散（例如 1 和 65537 原本低 4 位都是 1，扰动后异或结果不同） - 自定义类只重写了
equals没重写hashCode：默认继承Object.hashCode()，通常基于内存地址，高位变化大，扰动作用有限
性能影响几乎为零：一次右移 + 一次异或，比任何分支判断都快；兼容性上，该逻辑从 JDK 1.8 一直沿用至今，无变更风险。
容易忽略的关键点：扰动只是前置步骤，不是银弹
扰动函数无法弥补以下问题：
- 桶数组太小（如初始容量 16）且负载因子过高（如 0.9）→ 冲突必然多，扰动只能缓解，不能根除
- 大量 key 的
hashCode经扰动后仍碰撞（例如两个不同字符串算出相同hash()值）→ 此时靠链表或红黑树兜底 - 并发写入未加锁 → 即使哈希分布完美，也可能因扩容重哈希或链表头尾插混乱引发数据丢失或死循环（JDK 1.7 头插法已淘汰，但线程安全仍需外部保证）
真正要压低冲突率，得组合动作：合理预估容量、重写高质量 hashCode、必要时调大 initialCapacity 或降低 loadFactor。扰动函数只是那个默默把高位“借”来救场的配角。
