原文来自于：https://zha-ge.cn/java/34

0.75 的秘密：Java HashMap 为啥默认是这个负载因子？

一个普通周三的疑问

那是个普通的周三下午，我正在 Code Review 一位实习生小王的代码。突然，他指着屏幕上的一行代码问我：

“哥，这个 HashMap 为什么默认负载因子是 0.75？为啥不是 0.5 或者 1.0？感觉好奇怪的数字啊。”

我愣了一下。说实话，虽然用了这么多年 HashMap，但从来没深究过这个"0.75"背后的故事。于是，一场关于负载因子的探索之旅就此开始。

初探：什么是负载因子？

负载因子（Load Factor）简单来说就是：当前元素个数 ÷ 桶数组长度。

想象一下，HashMap 就像一个停车场，有很多停车位（桶）。负载因子就是告诉你：“嘿，停车场现在有多满了？”

• 负载因子 = 0.5：停车场半满
• 负载因子 = 0.75：停车场 3/4 满
• 负载因子 = 1.0：停车场全满

当负载因子达到阈值时，HashMap 会自动扩容（rehash），就像停车场要新建停车位一样。

对比实验：不同负载因子的较量

出于好奇，我写了个简单测试，看看不同负载因子下的表现：

// 测试不同负载因子的性能
Map<String, Integer> map1 = new HashMap<>(16, 0.5f);  // 保守派
Map<String, Integer> map2 = new HashMap<>(16, 0.75f); // 默认派
Map<String, Integer> map3 = new HashMap<>(16, 1.0f);  // 激进派

// 插入 1000 个元素，观察扩容次数和查询效率
for (int i = 0; i < 1000; i++) {
    String key = "key_" + i;
    // ... 插入操作
}

结果让人意外：

踩坑瞬间：理想很丰满，现实很骨感

最开始，我天真地以为：“负载因子越小越好啊，冲突少，查询快！”

但现实给了我一巴掌。

负载因子 0.5 的确查询很快，但内存浪费严重。想象一下，你的停车场只敢停一半车，剩下一半空着，多浪费啊！

负载因子 1.0 看起来很美好，内存利用率 100%，但哈希冲突变成了噩梦。就像停车场塞得满满当当，找个车位比登天还难。

转折：泊松分布的数学美学

真正的答案藏在概率论里。

HashMap 使用链表（或红黑树）处理哈希冲突。在理想情况下，哈希值分布符合泊松分布。

根据泊松分布的概率公式，当负载因子为 0.75 时：

// 泊松分布下，桶内元素个数的概率分布
// P(k) = (λ^k * e^(-λ)) / k!
// λ = 负载因子

// 当 λ = 0.75 时：
// P(0) ≈ 0.472  (空桶概率)
// P(1) ≈ 0.354  (单个元素)
// P(2) ≈ 0.133  (两个元素)
// P(3以上) ≈ 0.041 (长链表概率很小)

这意味着什么？大部分桶要么是空的，要么只有 1-2 个元素！

0.75 这个数字恰好在时间复杂度和空间复杂度之间找到了黄金平衡点：

• 时间效率：大部分查询只需要 1-2 次比较
• 空间效率：内存利用率达到 75%，不算浪费
• 扩容频率：既不会频繁扩容，也不会让链表过长

经验启示：工程中的智慧

这次探索让我明白了几个道理：

1. 没有完美，只有平衡

技术选择往往不是非黑即白，而是在多个维度间寻找最优解。0.75 不是最快的，也不是最省内存的，但它是综合最优的。

2. 数学是工程的底层逻辑

那些看似"拍脑袋"的经验值，背后往往有严谨的数学推导。Doug Lea 大神选择 0.75，绝不是随便拍的数字。

3. 理解比记忆更重要

与其死记"HashMap 负载因子是 0.75"，不如理解它为什么是 0.75。理解了原理，你就能在其他场景做出正确选择。

尾声：那个周三下午之后

回到那个周三下午，我把这些发现分享给小王。他恍然大悟：“原来如此！我还以为是 Java 设计者随便定的呢。”

现在，每当有人问起 HashMap 的负载因子，我都会说：

"0.75 不是一个随意的数字，它是时间与空间博弈后的数学诗篇。"

你呢？在日常开发中，还遇到过哪些"看似平常，实则精妙"的设计？欢迎评论区分享你的发现！