负载因子控制触发HashMap扩容的键值对数量阈值系数，即size > capacity × loadFactor时扩容；它不控制内存占比、桶内链表长度或哈希计算，仅构造时固化，默认0.75为时空折中。
负载因子（loadFactor）到底控制什么
负载因子不是内存占用比例，而是触发扩容的“键值对数量阈值系数”。HashMap在添加元素时，用 size > capacity * loadFactor 判断是否需要扩容。它不控制单个桶的链表长度，也不影响哈希计算本身。
默认值 0.75f 是时间与空间的折中：太小（如 0.5f）导致频繁扩容，数组重建开销大；太大（如 0.9f）虽节省空间，但链表/红黑树冲突概率上升，查找退化明显。
- 负载因子只在构造时传入并固化，后续不会动态调整
- 即使你 put 100 个元素后调用
putAll批量插入，判断逻辑仍基于当前size和已有capacity - 如果预估数据量稳定且读多写少，可设为
0.9f；若频繁增删，保持默认或略降（如0.6f）更稳妥
初始容量（initialCapacity）不是数组长度的直接指定
你传入的 initialCapacity 会被自动提升到“大于等于该值的最小 2 的幂”。例如传 10，实际初始化容量是 16；传 100，结果是 128。
这是为了配合哈希寻址的位运算优化：index = hash & (capacity - 1) 要求 capacity 是 2 的幂，否则位运算等价性不成立，会破坏散列分布。
立即学习“Java免费学习笔记（深入）”；
- 不要传奇数或非 2 幂值期望“刚好够用”，JVM 仍会向上取整
- 若明确知道要存约 1000 个键值对，按公式
expectedSize / loadFactor算：1000 / 0.75 ≈ 1334 → 取最近 2 的幂2048，构造时传2048 - 传
0或负数会抛IllegalArgumentException；传1会被转成1（合法的 2 的幂）
扩容（resize）时容量翻倍，但负载因子不变
扩容不是简单复制，而是重新计算每个 Node 的哈希值，并根据新容量决定放入新数组的哪个位置。由于新容量是旧容量的 2 倍，且仍是 2 的幂，每个元素最多只会在“原位置”或“原位置 + 旧容量”两个位置之一落位——这是 JDK 1.8 优化的关键。
int newCap = oldCap << 1; // 左移一位 = ×2 int newThr = oldThr << 1; // 阈值同步翻倍
注意：扩容后所有桶的链表/红黑树都会被遍历并重散列，所以高并发下应避免在循环中反复 put 导致隐式扩容。
- 扩容是阻塞操作，单次可能耗时几十微秒到毫秒级，取决于元素数量和哈希复杂度
-
loadFactor不参与 resize 过程，它只用于下次扩容前的阈值判断 - 使用
ConcurrentHashMap可规避单桶锁竞争，但它的扩容是渐进式分段进行，逻辑完全不同
为什么 put(null, value) 能成功，但 null 不参与哈希计算
HashMap 允许一个 null 键，是因为它把 null 特殊处理：固定放在数组索引 0 的位置，不调用 key.hashCode()。这绕过了空指针异常，也意味着 null 键永远不触发哈希冲突链表逻辑。
但这也带来副作用：如果你依赖 key.hashCode() 实现自定义对象的散列，而该对象可能为 null，必须在业务层提前判空，否则 get(null) 总是返回那个唯一 null 键的值，和其他键完全隔离。
-
get(null)不走常规哈希查找流程，直接查 table[0] 链表 - 多个
put(null, v1)、put(null, v2)是覆盖行为，不是冲突 - 如果业务中
null键有语义（如“未设置”），需格外注意它与其他键的隔离性——它不受负载因子和容量影响，也不参与 rehash
