0.75是HashMap负载因子的统计最优解，由泊松分布推导得出，兼顾空间利用率与查询效率：16容量时第13个元素触发扩容，使约47%桶为空、35%含1元素、13%含2元素，≥3元素桶仅占5%，确保多数操作O(1)。
因为 0.75 是在空间利用率和查询效率之间取得实际可行平衡的数值，不是凭空定的，而是由泊松分布推导出的统计最优解。
负载因子直接决定扩容时机
HashMap 的扩容阈值 = 当前容量 × 负载因子。比如默认初始容量 16，0.75 就意味着第 13 个元素插入时触发扩容（16 × 0.75 = 12，size 超过 12 即扩容）。这个阈值控制着：
- 太早扩容（如 loadFactor=0.5）→ 容量翻倍频繁，内存浪费明显，rehash 开销增加；
- 太晚扩容（如 loadFactor=1.0）→ 桶中堆积变多，链表拉长，查找退化为 O(n)，红黑树转换也更易触发；
- 0.75 让扩容节奏适中，既避免过度迁移，又防止桶严重过载。
0.75 对应低冲突概率的数学依据
当哈希函数均匀时，每个桶中元素数量近似服从泊松分布，λ = 负载因子。取 λ = 0.75 时：
- 约 47% 的桶为空；
- 约 35% 的桶有 1 个元素（理想状态）；
- 约 13% 的桶有 2 个元素（仍可快速遍历）；
- ≥3 个元素的桶合计仅占约 5%，≥8 的概率几乎为零（避免频繁树化）。
这意味着绝大多数操作落在 O(1) 范围内，极少数需遍历短链表，整体性能稳定。
立即学习“Java免费学习笔记（深入）”；
工程实践验证的折中结果
0.75 不是理论极限值，而是兼顾通用场景的实测经验值：
- 比 0.5 更省内存：同样存 100 个元素，0.75 下所需初始容量更小，减少预分配浪费；
- 比 0.9 更稳性能：冲突增长非线性，0.9 时平均桶长接近 1，但长链出现概率显著上升；
- JDK 团队在大量真实业务数据和随机键分布下反复验证，0.75 在吞吐、延迟、GC 压力等维度表现均衡。
可按需调整，但默认值足够健壮
你完全可以用 new HashMap(16, 0.5f) 或 0.9f 来定制，但前提是明确场景约束：
- 写少读多 + 内存敏感 → 可略提高（如 0.8–0.9）；
- 高频增删 + 响应敏感 → 可略降低（如 0.6–0.75）；
- 绝大多数业务逻辑没那么极端，0.75 已覆盖大部分时间-空间权衡需求。
