hashmap动态扩容在size > capacity × loadfactor时触发，新容量翻倍且为2的幂，通过高位/低位拆分优化迁移；负载因子0.75是基于泊松分布推导的空间与时间最优平衡点。
Java 中 HashMap 的动态扩容和负载因子设置，核心是控制空间与时间的平衡：扩容解决哈希冲突加剧导致的查找退化，负载因子决定何时触发扩容。
扩容触发条件与过程
扩容不是按需增加几个桶，而是整体重建——当元素个数 size > capacity × loadFactor 时立即触发。例如默认容量 16、负载因子 0.75，第 13 个元素插入后就会扩容。
- 新容量 = 原容量 × 2（如 16 → 32 → 64），始终为 2 的幂，保证
(n - 1) & hash能等效替代取模运算 - 所有已有键值对必须 rehash：重新计算每个 key 在新数组中的下标。JDK8 利用
hash & oldCap == 0快速区分高低位，将链表拆成两个子链，避免二次遍历 - 红黑树节点在迁移中复用结构，仅调整父子引用；若树节点 ≤ 6，后续可能退化回链表
负载因子为什么设为 0.75
这不是经验值，而是基于泊松分布的概率推导结果：当负载因子为 0.75 时，桶中链表长度达到 8 的概率极低（约 6×10⁻⁸），恰好匹配树化阈值的设计逻辑。
- 设为 1.0：空间利用率高，但冲突激增，大量链表变长，查询接近 O(n)
- 设为 0.5：冲突极少，但内存占用翻倍，且频繁扩容带来额外开销
- 0.75 是理论最优折中点，在哈希均匀前提下，兼顾查找效率与内存成本
如何合理设置初始容量与负载因子
避免运行期多次扩容的关键，在于初始化时预估到位。构造时传入容量参数，HashMap 会自动向上取最近的 2 的幂。
- 若明确要存 N 个元素，按公式计算：初始容量 ≥ N / loadFactor，再取 2 的幂。例如存 800 个元素，800 ÷ 0.75 ≈ 1067 → 取 2048
- 负载因子不建议随意修改：业务写多读少且内存充裕，可略调高（如 0.8）；对延迟敏感场景，可略调低（如 0.6），但需实测验证收益
- key 的
hashCode()必须稳定且分布均匀，否则再好的容量设置也无效——这是很多性能问题的根源
实际开发中的避坑提醒
扩容本身是单线程阻塞操作，未加同步的并发 put 可能导致数据丢失（JDK8）或死循环（JDK7）。高并发场景应直接选用 ConcurrentHashMap，而非手动同步 HashMap。
- 不要依赖默认容量处理大批量数据：插入 1024 个元素，默认起始容量 16 会触发约 7 次扩容，每次都要 rehash 全量数据
- 慎用自定义负载因子：除非有压测数据支撑，否则偏离 0.75 往往得不偿失
- 注意 null 键：其 hash 固定为 0，总落在索引 0 的桶里，若大量使用 null 键，极易造成局部冲突
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
