0.75 是 HashMap 默认负载因子，是权衡空间占用与查询效率的经验值；它使扩容频率适中，在保证 O(1) 查找性能的同时避免内存浪费或冲突激增。

0.75 是 HashMap 默认负载因子，它不是随意定的数字，而是对空间占用和查询效率反复权衡后得出的经验值。

为什么是 0.75，而不是 0.5 或 0.9？

负载因子 = 元素个数 / 桶数组容量。它直接影响两个关键表现：

• 太小（如 0.5）：桶数组过早扩容，内存浪费明显，但冲突少、查询快
• 太大（如 0.9）：空间利用率高，但哈希冲突概率显著上升，链表或红黑树变长，平均查找时间退化
• 0.75 处于一个“拐点区间”：泊松分布建模表明，此时单个桶中元素 ≥8 的概率低于千万分之一，仍能稳定维持 O(1) 平均查找性能

0.75 如何触发扩容？

HashMap 初始容量为 16，按 0.75 计算，阈值 = 16 × 0.75 = 12。当第 13 个元素 put 进去时，就会触发扩容——数组长度翻倍（变为 32），所有元素 rehash 重新分布。

• 扩容代价高：涉及重新计算 hash、遍历旧数组、搬运节点，是典型的“以空间换时间”操作
• 0.75 让扩容频率足够低，又不至于让单次扩容前的性能明显下滑

你可以改，但得有依据

通过构造函数可自定义 loadFactor，比如：

new HashMap(16, 0.5f); // 更保守，适合读多写少、内存宽裕场景
new HashMap(16, 0.9f); // 更激进，适合内存敏感、数据分布极均匀的场景

• 调低负载因子 → 提前扩容 → 内存开销增大，但查询更稳定
• 调高负载因子 → 推迟扩容 → 节省内存，但需确保哈希函数质量高，否则冲突陡增
• 生产中若已知 key 分布特征（如 UUID 随机性强），可适度提高；若 key 有明显规律（如连续整数），建议保持 0.75 或更低

它不只是 HashMap 的事

类似设计在其他哈希结构中也存在：

• C++ unordered_set 默认 max_load_factor() 也是 1.0，但实践中常设为 0.7–0.8
• 数据库索引（如 MySQL 的 Hash Index）或缓存系统（如 Redis 的 dict）同样依赖负载因子控制桶膨胀节奏
• 核心逻辑一致：用可控的空间冗余，换取确定性的时间性能