因为HashMap数组长度n恒为2的幂，故n−1二进制全为1，(n−1)&hash等价于取hash低log₂(n)位，效果同hash%n，但位运算比取模快一个数量级；且hash值经h^(h>>>16)扰动，使高位参与索引计算，降低哈希冲突。
为什么 (n - 1) & hash 能替代 hash % n
因为 HashMap 的数组长度 n 始终是 2 的幂（如 16、32、64），所以 n - 1 的二进制全是 1（如 15 → 0b1111）。此时 hash & (n - 1) 等价于取 hash 的低 log₂(n) 位，效果和 hash % n 完全一致，但位运算是 CPU 级别指令，比取模快一个数量级。
常见错误现象：HashMap 自定义初始容量传入 10 或 100，实际内部会调用 tableSizeFor(10) 变成 16，传 100 则变成 128。不理解这点，就容易误判索引分布逻辑。
关键点：
- 这个优化只在
n是 2 的幂时成立；一旦破坏（比如手动反射修改table长度），&就不再等价于取模，结果错乱 -
hash值本身不直接来自key.hashCode()，而是经过扰动后的值
hash() 函数到底做了什么
hash(Object key) 是 JDK 1.8 中的静态私有方法，它不是“加密”或“加盐”，就是一次轻量位运算：
static final int hash(Object key) {
int h;
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}作用很明确：把 hashCode() 的高 16 位异或到低 16 位，让高位信息“漏”下来参与索引计算。
典型场景：字符串 "A"、"B"、"C" 的 hashCode() 分别是 65、66、67，低 4 位全是 0001、0010、0011 —— 如果没扰动，它们在长度为 16 的表中全落在 table[1]、[2]、[3]，看似均匀；但若有一批 id=1000, 1016, 1032... 的对象（步长 16），hashCode() 低 4 位全为 0，就会全部挤进 table[0]，链表爆炸。
扰动后，哪怕低 4 位相同，高位异或也会大概率打散低位，显著降低碰撞概率。
扰动为什么只右移 16 位
不是随便选的数字。32 位 int 中，右移 16 位刚好把高半区对齐到低半区，异或后能最大限度混合高低位信息，又避免过度计算。右移 8 位太弱（高位影响不足），右移 24 位又太偏（只剩最高 8 位起作用）。
实操中你完全不需要、也不能重写 hash() 方法——它是 HashMap 内部实现细节。真正该关注的是：
- 自定义
key类时，hashCode()和equals()必须逻辑一致且稳定 - 如果
hashCode()返回常量（如始终返回1），扰动函数再强也无济于事，所有 key 全进同一个桶 -
nullkey 的哈希值固定为0，所以永远落在table[0]，这是设计使然，不是 bug
槽位计算全流程示例
假设 key="Java"，当前 table.length = 16：
- 调用
"Java".hashCode()→ 得到2301619（十进制）→ 二进制0x00231EC3 - 执行扰动：
h ^ (h >>> 16)→0x00231EC3 ^ 0x00000023 = 0x00231EE0 - 计算索引：
(16 - 1) & 0x00231EE0 = 0xF & 0x00231EE0 = 0x0（取低 4 位，结果为0）
整个过程没有分支、无内存分配、纯 CPU 运算，是 HashMap 高性能的关键一环。最容易被忽略的是：扰动发生在索引计算之前，且只做一次；后续扩容时，新索引由旧 hash 值直接重算，不重复扰动——因为扰动值已存入 Node.hash 字段。
