0.75 是 hashmap 综合时间效率、空间利用率与哈希冲突权衡得出的默认加载因子，基于泊松分布建模与实测验证，兼顾扩容开销与 o(1) 查找性能。
0.75 是 HashMap 在实际工程中对时间效率、空间利用率和哈希冲突三者反复权衡后确定的默认加载因子——它不是纯数学推导出的唯一解，而是结合泊松分布建模与大量实测验证得出的稳定拐点。
空间与时间的双向拉锯
加载因子直接影响扩容频率和桶内拥挤程度：
- 设为 0.5：每存一半容量就扩容，内存浪费约 50%，但查找几乎无冲突，性能稳定
- 设为 0.9：接近填满才扩容，空间利用率高，但链表变长、红黑树触发更频繁，平均查找退化明显
- 0.75 对应约 25% 的预留空间，既抑制了高频扩容开销，又把大部分桶控制在 0–1 个元素，维持 O(1) 查找均值
泊松分布支撑的冲突概率模型
理想哈希下，桶中元素数量服从泊松分布，参数 λ ≈ 0.5（对应实际平均负载）。此时：
- 约 47% 的桶为空（P(0) ≈ e⁻⁰·⁷⁵ ≈ 0.472）
- 约 35% 的桶含 1 个元素（P(1) ≈ 0.75 × e⁻⁰·⁷⁵ ≈ 0.354）
- 含 2 个元素的桶占 13%，含 3 个的仅约 3.3%
- 链表长度达到树化阈值 8 的概率低于 10⁻⁷，基本可忽略
扩容阈值的工程落地细节
阈值 threshold = (int)(capacity × loadFactor)，采用截断而非四舍五入：
- 初始容量 16 × 0.75 = 12.0 → 阈值为 12，第 13 个元素触发扩容
- 若容量为 13（非 2 的幂），13 × 0.75 = 9.75 → 截断为 9，提前扩容，避免过度堆积
- 浮点计算配合 int 强转，兼顾精度与整数索引安全
为什么不是 0.6 或 0.8？
实测表明，偏离 0.75 后边际收益快速衰减：
- 0.6：空间浪费升至约 40%，扩容次数增加近一倍，GC 压力上升
- 0.8：冲突率跳升，P(≥2) 超过 20%，小规模数据下查询延迟波动显著
- 0.75 恰好落在“单位空间增益换得最小性能损失”的缓坡区，适配绝大多数业务场景
