哈希值分布均匀性直接决定HashMap桶负载均衡性；JDK通过h ^ (h >>> 16)扰动函数使高位参与索引计算，避免低位集中导致冲突；自定义hashCode需全面参与equals字段、禁用简单模运算，优先用Objects.hash；容量应按预期元素数÷0.75向上取最近2的幂，以保障桶利用率和O(1)性能。
键对象的哈希值分布是否均匀，直接决定hashmap中各桶（bucket）的负载是否均衡。分布越集中，冲突越多，链表越长，查找就从o(1)退化为o(n)；分布越散开，桶利用率越高，性能越接近理论最优。
哈希值高位参与运算很关键
HashMap底层用 (n - 1) & hash 计算索引，而n是2的幂（如16、32、64），所以实际只取hash低几位。如果key.hashCode()仅低位变化大、高位恒定（比如ID连续递增），那大量键会落在同一组桶里。
JDK的扰动函数 h ^ (h >>> 16) 就是为解决这个问题：把高16位“混入”低16位，让高位差异也能影响索引位置。
自定义类重写hashCode()时，应确保：
- 所有参与equals判断的字段都参与哈希计算
- 避免用模运算简化（如
id % 100），这会人为制造周期性碰撞 - 优先使用
Objects.hash(f1, f2, f3)，它内部已做良好混合
键类型选择直接影响分布质量
String、Integer、UUID等JDK标准类的hashCode实现经过长期验证，离散性好，适合作为键。
立即学习“Java免费学习笔记（深入）”；
而以下情况容易导致分布差：
- 自定义类未重写hashCode()，直接继承Object，默认返回内存地址，不同实例哈希值可能高度相关
- 重写后只返回固定值（如
return 1;），所有实例全进同一个桶 - 用Date对象作键，若只截取到秒级且批量创建，毫秒部分被忽略，易聚集
容量与数据规模要匹配
即使哈希值本身均匀，若数组太小，也会被迫“挤”在一起。例如1000个键填进默认容量16的HashMap，平均每个桶62个元素，必然严重退化。
合理预估方式：
- 按预期元素数 ÷ 负载因子（0.75）向上取最近2的幂
- 存1000个元素 → 1000 ÷ 0.75 ≈ 1334 → 取2048（2¹¹）
- 初始化写成
new HashMap(2048, 0.75f)
链表转红黑树不是万能解药
当某个桶链表长度≥8且总容量≥64时，会树化——但这只是缓解最坏情况，并不消除根本问题。
如果多数桶都接近8个节点，说明哈希分布或容量设置仍有缺陷。树化还带来额外开销：节点结构更重、比较需调用compareTo()、非Comparable类型无法树化仍走链表。
真正有效的做法是：先让哈希分布更开，再配合适当容量，让绝大多数桶保持1～3个节点。
