0.75 是 HashMap 综合时间效率、空间利用率与哈希冲突的工程最优解，由实测与泊松分布建模验证为稳定拐点；它决定扩容阈值 threshold = (int)(capacity × 0.75)，兼顾精度与索引安全，并使约47%桶为空、35%含1元素，链表树化概率极低。
0.75 是 HashMap 在时间效率、空间利用率和哈希冲突三者之间反复权衡后确定的工程最优解，不是数学唯一解，而是大量实测与泊松分布建模共同验证出的稳定拐点。
它本质是扩容阈值的“调节器”
加载因子直接决定 threshold（扩容阈值）：threshold = (int)(capacity × loadFactor)。例如初始容量 16，0.75 → 阈值为 12，第 13 个元素触发扩容。这个截断取整的设计兼顾了精度与索引安全，避免浮点误差导致阈值漂移。
- 设为 0.5：16×0.5=8，存到第 9 个就扩容 → 内存浪费约 50%，扩容频次翻倍，GC 压力明显上升
- 设为 0.9：16×0.9=14.4 → 截断为 14，接近填满才扩 → 桶内平均元素数升高，链表变长，红黑树触发更早
- 0.75 对应约 25% 的预留空间，既压制了高频扩容开销，又把大多数桶控制在 0–1 个元素，维持 O(1) 查找均值
泊松分布支撑的冲突概率模型
在理想哈希下，各桶元素数量近似服从泊松分布，λ ≈ loadFactor。当 loadFactor = 0.75 时：
- 约 47% 的桶为空（P(0) ≈ e⁻⁰·⁷⁵ ≈ 0.472）
- 约 35% 的桶含 1 个元素（P(1) ≈ 0.75 × e⁻⁰·⁷⁵ ≈ 0.354）
- 含 2 个元素的桶占 13%，含 3 个的仅约 3.3%
- 链表长度达到树化阈值 8 的概率低于 10⁻⁷，基本可忽略
偏离 0.75 的边际收益快速衰减
实测表明，小幅调整会打破平衡：
立即学习“Java免费学习笔记（深入）”；
- 0.6：空间浪费升至约 40%，扩容次数增加近一倍，小数据量下延迟波动不明显但 GC 频次显著上升
- 0.8：P(≥2) 超过 20%，平均查找跳表次数上升，尤其在 key 分布不均时，部分桶链表长度快速突破 5
- 0.75 恰好落在“单位空间增益换得最小性能损失”的缓坡区，适配绝大多数通用业务场景
不复杂但容易忽略
