为什么 Java 中 HashMap 的默认负载因子是 0.75？
- 标签：Java 集合、Java
🏛 业务架构师
0.75 是空间利用率与 rehash 成本的经验平衡点，可以两层理解：
- 数学层：泊松分布下，负载因子 0.75 时桶的碰撞概率在可接受范围，同时扩容频率不至于过高；0.5 浪费一半空间但碰撞少，1.0 空间省满但冲突急剧上升——0.75 处在拐点附近的"甜点区"；
- 成本层：负载因子决定"多久扩容一次"（越小扩容越频繁，拷贝成本高）与"查询多快"（越大冲突越多，链表变长）。0.75 是 JDK 作者对典型业务负载的取舍结论。
业务架构视角，我从中提炼的是**"默认值经济学"**：
- 默认值是给大多数普通场景调的优，不是给你的业务调的优。缓存容量预估明确时，直接
new HashMap<>(expected/0.75f + 1)消灭扩容——大促前批量预热本地缓存，这个习惯能显著降低启动耗时和毛刺； - 真正的特殊场景可以也应该改：内存极度敏感的嵌入式/端上场景，调大负载因子牺牲查询换空间；时延敏感的核心路径，调小换冲突概率。但前提是有压测数据支撑，而不是凭感觉；
- 推广到一切技术决策：默认值背后是"通用场景最优"，识别出"自己不是通用场景"本身就是架构能力。面试和评审里我会追问一句：你的业务画像和默认假设哪里不一样？答得出来的团队，参数调优才是有的放矢；答不出来，就老实用默认值，别乱动。
0.75 这个数字会过时，"先懂默认值的适用边界再改"的方法论不会。
🏗 系统架构师
0.75 是空间利用率与冲突率的数学折中，可以从泊松分布角度理解：
HashMap 默认容量 16，扩容阈值 = capacity × 0.75。负载因子越高，空间越省（触发扩容晚）但桶冲突概率越高；越低则冲突少但内存浪费、rehash 频繁。0.75 时桶内节点数近似服从参数 0.5 的泊松分布，单个桶超过 8 个元素的概率约千万分之六——正好衔接"链表长度 8 树化"的设计假设（树化是极罕见兜底）。同时 0.75 = 3/4，capacity 为 2 的幂时，threshold 计算可以用位运算，工程实现干净。
换个角度：如果设 1.0，冲突加剧，查找退化频发；设 0.5，一半空间闲置且扩容次数翻倍，rehash 是全量搬迁的大动作，得不偿失。0.75 让"期望冲突成本"和"空间/扩容成本"近似平衡。
我会延伸到实践：这个默认值适合通用场景，特殊场景可以显式指定——已知量小且读极敏感的映射可压到 0.5 换冲突率；超大缓存想省内存可到 1.0 并接受更多树查找。类似的"默认参数=典型工作负载的均衡点"思想贯穿 JDK，读源码时我更关注设计者背后的权衡逻辑而不是数字本身。
💻 全栈开发专家
本质是"空间/时间"的折中经验值，0.75 是冲突概率和内存浪费的平衡点：
- 调大（如 1.0）：空间利用率高，但碰撞概率陡增，链表变长查询变慢，还会更早树化；
- 调小（如 0.5）：冲突少性能好，但大量桶空着，内存浪费且扩容更频繁（rehash 是全量搬迁，很贵）。
0.75 时泊松分布下桶中节点数概率：0 个约 0.6，长度 8 的概率约 0.00000006——这正是 JDK 8 树化阈值取 8 的依据：正常情况几乎不会树化，一旦树化说明 hash 质量有问题或遭遇碰撞攻击，红黑树是防御手段而非常规路径。
我的引申（面试提升）：
- 这个值和
tableSizeFor配合，让扩容成本可预期； - 泊松分布的前提是 hash 均匀分布（容量 2 的幂 + 扰动函数保证），自定义 key 的 hashCode 写得差会破坏这个前提；
- 能预估大小时初始化就传容量：
new HashMap<>((int)(expected / 0.75f) + 1)，一次性算好，避免中途扩容——解析大文件/大 JSON 时的标准优化。