java hashmap扩容是当size超过threshold（capacity×loadfactor）时自动触发的两倍扩容过程，通过位运算高效重哈希迁移元素，负载因子0.75是空间与时间平衡的统计最优解。
Java 中 HashMap 扩容（resize）是自动发生的结构调整过程，核心目的是在元素增多、哈希冲突加剧时，通过扩大底层数组容量来维持平均 O(1) 的查询性能。负载因子（load factor）则是控制这一行为的关键阈值参数，它不是随意设定的 magic number，而是空间利用率与查询效率之间的量化平衡点。
扩容触发条件：看 size 是否超过 threshold
HashMap 不是等数组填满才扩容，而是在元素个数 size 超过 threshold（扩容阈值） 时立即触发 resize。这个 threshold 计算方式为：
- threshold = capacity × loadFactor
- 默认初始 capacity 是 16，loadFactor 是 0.75 → threshold = 12
- 也就是说，第 13 个元素 put 进去后，就会触发第一次扩容
注意：JDK 1.8 是先完成插入，再判断是否超阈值；JDK 1.7 是先检查、再插入。两者逻辑顺序不同，但触发条件一致。
扩容具体怎么操作：两倍扩容 + 位运算重分配
扩容不是简单复制，而是高效重哈希的过程：
- 新数组容量 = 原容量 × 2（如 16 → 32，32 → 64），且始终是 2 的幂次方
- 利用 hash & oldCap 判断每个节点在新数组中的位置：
- 若 (e.hash & oldCap) == 0 → 节点留在原索引位置
- 若 (e.hash & oldCap) != 0 → 节点移到 原索引 + oldCap 的位置
- 这种设计避免了重新计算完整 hash，仅靠一次位运算就能决定迁移方向，大幅提升 resize 效率
负载因子的作用：控制“何时扩”和“扩多频繁”
loadFactor 决定了 HashMap 的“拥挤容忍度”，直接影响两个方面：
- 太小（如 0.5）：提前扩容，链表更短、查询更快，但空间浪费严重，可能频繁新建数组
- 太大（如 1.0）：节省内存，但哈希冲突剧增，链表变长，查询退化为 O(n)，甚至触发树化（链表长度 ≥8 且 capacity ≥64 时转红黑树）
- 0.75 是统计最优解：基于哈希均匀分布假设和泊松分布推导得出——此时链表长度达到 8 的概率极低（约 10⁻⁸），既极少触发树化，又不过度浪费空间
实际开发中怎么用更合理
避免默认构造带来的多次 resize 开销：
- 如果预估要存 N 个键值对，建议初始化时指定容量：
int capacity = (int) Math.ceil(N / 0.75);
Mapmap = new HashMap(capacity); - 例如要放 1000 个元素，直接 new HashMap(1000) 不够——应设为 1334（向上取整），这样可跳过前几次扩容
- 不推荐盲目调大 loadFactor（如设成 0.9），除非你明确接受更高冲突代价
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
