hash()函数对非null键执行(h = key.hashCode()) ^ (h >>> 16)扰动以改善低位散列，null则直接返回0；数组长度需为2的幂以使(n-1)&hash等价于取模并保留高位信息。
hash() 函数到底做了什么？
它就是 JDK 1.8 中那个 hash(Object key) 方法：如果 key 为 null，返回 0；否则取 key.hashCode()，再跟自己右移 16 位的结果做异或——(h = key.hashCode()) ^ (h >>> 16)。
这不是“加盐”也不是加密，就是一次轻量级的位运算扰动。原始 hashCode 是 32 位整数，高位往往在字符串、对象地址等场景下变化不敏感（比如小字符串的 hashCode 高位全是 0），直接拿低位参与索引计算，等于只用了 4–5 个 bit 做散列，碰撞率飙升。
实操建议：
- 别手动重写
hash()——它是 HashMap 内部私有逻辑，你改不了，也不该改 - 如果你自定义 key 类，重点是正确实现
hashCode()和equals()，确保逻辑一致，否则扰动函数再好也救不了 - 注意：String、Integer 等 JDK 自带类的
hashCode()已高度优化，配合扰动效果很好；但你自己写的 POJO 若只用 id 字段算 hash，高位长期为 0，扰动后仍可能聚集
为什么数组长度必须是 2 的幂？
因为索引计算靠的是位运算：tab[i = (n - 1) & hash]，其中 n 是数组长度。只有当 n 是 2 的幂时，n - 1 才是一串连续的 1（比如 16→15→0b1111），& 运算才能等价于取模，且只保留 hash 的低几位。
如果不用 2 的幂，就得用 hash % n，慢；更糟的是，% 运算会让高位信息彻底丢失——而扰动函数费劲把高位“混进”低位，就是为了在这一步被用上。
常见错误现象：
- 手写哈希表时误设容量为 10、100 等非 2 幂值，导致
&失效，退化成取模，扰动白做，碰撞激增 - 调用
new HashMap(int initialCapacity)传入 100，实际初始化容量却是 128（JDK 自动找最近的 2 幂），这点容易被忽略
扰动真能降低碰撞？看一个直观例子
假设两个 String："Aa" 和 "BB"，它们的 hashCode() 分别是 2112 和 2112（经典碰撞案例）。原始值一样，扰动后当然还一样——扰动解决不了这种“天然碰撞”，但它大幅减少了“因低位雷同导致的伪碰撞”。
更典型的场景：一批以递增 ID 为 key 的对象（如 new User(1), new User(2)…），若 ID 的 hashCode() 就是自身，那原始 hash 序列就是 1,2,3,4…，低位规律极强。不做扰动，映射到长度 16 的 table 就全挤在 index=1~4；加上 ^ (h >>> 16) 后，低位被高位“搅乱”，分布立刻松散。
性能影响很小：一次右移 + 一次异或，CPU 几个周期的事；但对负载因子 >0.75 的表，平均链长可能从 5 降到 2，红黑树触发概率显著下降。
和 JDK 1.7 比，1.8 的扰动简化了，是不是更弱了？
不是更弱，是更务实。JDK 1.7 的 hash 实现用了 4 次位移 + 5 次异或（共 9 次扰动），理论更“充分”，但实测提升微乎其微，反而增加 CPU 开销。1.8 改成单次 ^ (h >>> 16)，兼顾了速度、实现简洁性与效果。
真正关键的升级不在扰动本身，而在后续机制：
- 链表长度 ≥8 且数组长度 ≥64 时，自动转红黑树——这比“拼命防碰撞”更治本
- 扰动 + 2 的幂容量 + 树化，三者是组合拳；单独看扰动，只是让前两步更有效
容易被忽略的一点：扰动函数对 null key 是特例处理（返回 0），所以 map.put(null, "v") 永远落在 table[0]，这个位置从不参与扰动计算——如果你的应用高频使用 null key，得意识到它天然就是热点槽。
