0.75是空间利用率与查询/插入性能的平衡点：设为1.0会导致哈希冲突激增、链表变长、查找退化；设为0.5则内存浪费大、扩容频繁；该值经泊松分布验证，兼顾缓存友好性与树化开销。
HashMap 的加载因子设为 0.75，是空间利用率和查询/插入性能之间一个被广泛验证的平衡点。
为什么不是 1.0？——避免哈希冲突激增
加载因子 = 元素个数 / 桶数组长度。若设为 1.0，意味着等数组填满才扩容。但哈希函数无法完全避免碰撞，实际中即使负载刚过 0.5，链表长度就开始明显增长；到 0.75 时，平均冲突仍可控（理想情况下接近泊松分布，期望链长 ≈ 0.75）；而到 1.0 时，平均链长会升至约 1.0，最坏情况可能接近 O(n) 查找。
- 哈希表查找时间主要花在定位桶 + 遍历桶内链表/红黑树上
- 链表越长，比较次数越多，缓存局部性也越差
- 实验和理论分析表明，0.75 附近冲突增长开始加速，再往上性价比断崖式下降
为什么不是 0.5？——减少不必要的空间浪费
设为 0.5 确实能进一步压低冲突率（平均链长约 0.5），但代价是内存占用翻倍：同样存 100 个元素，0.5 要开 200 个桶，0.75 只需约 134 个（向上取整为 128 或 256，取决于初始容量）。JVM 堆内存宝贵，尤其在大量 HashMap 实例场景下，过度保守的空间策略会显著增加 GC 压力和内存 footprint。
- 扩容是昂贵操作：需新建数组、重新哈希所有元素、搬运链表节点
- 0.5 会导致更频繁扩容，反而抬高平均写入成本
- 现代 CPU 缓存对中等密度的数组更友好，0.75 在缓存行利用率和冲突间取得较好折中
0.75 是经验值，但也经得起数学推导
该值源于经典哈希理论：假设哈希均匀，n 个元素放入 m 个桶，空桶比例约为 e−n/m。当 n/m = 0.75 时，空桶率 ≈ 47%，即近一半桶非空但未严重堆积；同时，单桶含 ≥3 个元素的概率仅约 3.4%（泊松分布 λ=0.75），足够低到多数桶保持链表结构，避免提前树化开销。
- Java 8 中链表转红黑树阈值是 8，0.75 下极少触发，兼顾了简单性与最坏保障
- 若加载因子过高（如 0.9），≥8 冲突概率跃升至 ~15%，树化频次大增，反而降低平均性能
- 0.75 不是绝对最优，但在通用场景下，它让“均摊时间复杂度稳定在 O(1)”的保证更可靠
可调，但需谨慎
构造时可传自定义加载因子，比如确定数据量小且 key 分布极均匀，可设为 0.9 以省空间；若 key 哈希质量差或对读性能极度敏感，可设为 0.6。但非常规值往往需要配套调整初始容量，并做真实场景压测——盲目改动容易因小失大。
- 修改加载因子不改变已有 HashMap 行为，只影响后续扩容时机
- 过低（如 0.2）导致数组膨胀快、指针冗余多、GC 更频繁
- 过高（如 0.95）虽省空间，但一旦哈希稍有偏差，性能抖动剧烈，调试困难
它不是一个魔法数字，而是综合哈希理论、硬件特性、典型负载和工程实践得出的稳健选择。
