负载因子是冲突与空间的权衡杠杆，值越小查询越快但内存占用越高，越大则相反；默认0.75是平均查找长度、内存浪费与扩容频次的实测折中点。
负载因子不是固定值，而是你主动设置的平衡杠杆——调低它，查询快但占内存；调高它，省空间但查得慢。关键不在“怎么调”，而在“为什么这么调”。
负载因子的本质是冲突与空间的权衡
负载因子（load factor）= 当前元素个数 / 数组容量。它决定 HashMap 什么时候扩容。默认 0.75 意味着：数组填到 75% 就触发两倍扩容。这不是经验值，而是大量实测后在平均查找长度、内存浪费、扩容频次三者间找到的折中点。
低于 0.75（如 0.5）→ 更早扩容 → 桶更空 → 链表/红黑树更短 → get/put 平均更快，但内存可能多用近一倍；
高于 0.75（如 0.9）→ 更晚扩容 → 桶更满 → 冲突概率上升 → 长链表变多，甚至提前树化 → 单次 get 可能退化到 O(log n)，且 put 时哈希再计算压力更大。
立即学习“Java免费学习笔记（深入）”；
根据场景调整负载因子的实用建议
- 高频读、低内存压力：比如缓存用户会话（Session Cache），读远多于写，可用 0.5～0.6。桶稀疏，get 几乎总走数组直达，避免链表遍历开销。
- 写多读少、内存敏感：比如日志聚合临时计数（Key 是日志标签，Value 是次数），可设为 0.8～0.85。允许适度冲突，减少扩容次数和内存占用，写入吞吐更重要。
- 数据量已知且稳定：比如加载固定配置项（约 200 条），直接初始化容量：new HashMap(256, 0.75)，让 threshold = 192，刚好覆盖不扩容。此时负载因子保持默认即可，不必硬调。
比调负载因子更重要的事：先设对初始容量
负载因子只有在发生扩容时才起作用。如果一开始就知道要放 N 个元素，优先用构造函数指定初始容量：
✅ 推荐写法：new HashMap((int) Math.ceil(N / 0.75)) —— 这样 threshold ≈ N，基本避免首次扩容；
❌ 避免写法：new HashMap(N) —— 因为 HashMap 会把传入的 initialCapacity 向上取整到最近的 2 的幂，且真正阈值仍是 capacity × 0.75，容易误判。
例如预估存 100 个键值对，直接传 100，HashMap 实际建容量为 128，threshold = 96 → 第 97 个元素就扩容。而传 134（ceil(100/0.75)），容量取 128 或 256 更合理，取决于你是否接受一次扩容。
不建议随意修改负载因子的几种情况
- 通用工具类或框架内部使用的 HashMap：保持默认 0.75，避免影响上下游行为一致性；
- 元素数量波动极大（如从 10 到 10 万）、无法预估：与其调负载因子，不如用 ConcurrentHashMap 或考虑分段缓存策略；
- Key 的 hashCode() 实现质量差（大量碰撞）：这时调负载因子治标不治本，应优先重写 equals/hashCode 或换 Key 类型。
