HashMap负载因子默认为0.75，是基于泊松分布建模得出的空间与时间平衡最优解；其决定扩容阈值（threshold = capacity × loadFactor），影响哈希冲突率、内存占用及查询性能。
Java 中 HashMap 的负载因子（load factor）直接决定扩容时机，是空间占用和查询时间之间的核心调节杠杆。调得低，冲突少、查得快，但内存浪费多；调得高，省空间，但链表易变长、查询变慢。调整不是拍脑袋，而是结合业务读写特征做取舍。
什么时候该调低负载因子（比如 0.5）
适合对响应延迟极度敏感、内存相对宽裕的场景，比如高频实时查询缓存、风控规则匹配表。
- 元素平均分布更稀疏，大部分桶里只有 0 或 1 个节点，链表几乎不形成，get/containsKey 基本一步到位
- 红黑树转化（链表≥8）概率大幅下降，避免 TreeNode 对象额外开销（比普通 Node 多约 24 字节）
- 注意代价：数组容量翻倍更快，例如预估存 1000 个元素，用 loadFactor=0.5 就得初始化 capacity ≥ 2000（向上取 2 的幂 → 2048），空引用占位更多
什么时候该调高负载因子（比如 0.8 或 0.9）
适合写多读少、内存受限、且能容忍轻微性能波动的场景，比如离线批处理中间状态聚合、日志临时归集。
- 减少扩容次数，避免 resize 过程中 rehash 和元素迁移带来的 CPU 突增与 GC 压力
- 相同元素量下数组更小，堆内存占用更低，尤其在大量小 HashMap 实例共存时效果明显
- 风险提示：负载因子到 0.9 时，平均每个桶近 1 个元素，但泊松分布下出现 3~4 个元素的桶概率显著上升；若 key 哈希不均，局部链表可能快速达到 8 触发树化，反而增加比较开销
怎么设才不踩坑：容量和负载因子要一起算
光调负载因子没用，必须配合初始容量。HashMap 在 size > capacity × loadFactor 时才扩容，所以两者共同决定第一次扩容点。
- 例如预估存 1200 个元素：用默认 0.75，需 capacity ≥ 1600（1200 ÷ 0.75 = 1600），取最近 2 的幂 → 2048；若改用 0.5，则需 capacity ≥ 2400 → 4096，内存翻倍
- 推荐公式：initialCapacity = (int) Math.ceil(expectedSize / loadFactor)，再手动确保是 2 的幂（HashMap 构造时会自动向上规整，但自己算清更可控）
- 不要盲目设超大 capacity（如 10 万）来“一劳永逸”——空桶太多会拖慢遍历（keySet()、entrySet()），也增加 GC 扫描压力
默认值 0.75 其实已经很稳
这不是随便定的数字。基于泊松分布建模，0.75 对应桶中元素数 ≤ 2 的概率合计超 95%，≥ 8 的概率低于千万分之一。它在大多数通用业务中做到了冲突率、内存、扩容频次三者的工程最优解。
除非你清楚知道自己的数据规模、访问模式和资源约束，否则别动它。真要调，建议先压测：对比 QPS、P99 延迟、Full GC 频次、堆内存曲线这四组指标，再下结论。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
