合理设置hashmap初始容量可减少扩容、提升性能，应按⌈预期元素数÷0.75⌉向上取最近2的幂（如300→512），避免依赖自动转换，并可根据内存与性能权衡调整负载因子。
HashMap 初始化时合理设置初始容量，能显著减少扩容次数，提升性能。关键不是随便给个大数，而是根据预估元素数量和默认加载因子（0.75）反向推算。
按预期元素数量反推初始容量
HashMap 在元素数量超过 容量 × 加载因子 时触发扩容。默认加载因子是 0.75，所以若你确定要存 100 个键值对，最小安全容量应满足：
capacity × 0.75 ≥ 100 → capacity ≥ 134（向上取整）。但 HashMap 容量必须是 2 的幂次，因此实际应设为 256。
- 公式：初始容量 = ⌈预期元素数 ÷ 0.75⌉，再向上取最近的 2 的幂
- JDK 提供了工具方法
tableSizeFor(int cap)（内部使用），但对外推荐用HashMap(int initialCapacity)构造器 - 例如：预估存 300 个元素 → ⌈300 ÷ 0.75⌉ = 400 → 最近 2 的幂是 512
避免传入过小或未处理的原始值
直接传入 100、200 这类非 2 的幂数值，HashMap 会自动调用 tableSizeFor 转成下一个 2 的幂（如 100 → 128，200 → 256），看似省事，但容易误判——如果只传 1，它变成 1；传 12，它变成 16；但若你本意是存 12 个元素，16 容量刚好够（16×0.75=12），不会扩容；可若传 13，就变成 16，仍够用；但传 17 就升到 32，冗余变大。
- 不建议依赖自动转换，应自己算好再传，更可控
- 特别注意：传 0 会得到容量 1；传负数抛异常；传 1 得容量 1（很快扩容）
考虑负载因子是否需要调整
如果内存充裕、更看重读写速度，可适当提高初始容量并降低负载因子（如设为 0.5 或 0.6），进一步推迟扩容；反之，内存敏感场景可略提高负载因子（但不建议超过 0.75，易引发大量哈希冲突）。
- 构造时可用
new HashMap(initialCapacity, loadFactor) - 例如：预估 200 元素 + loadFactor=0.5 → 容量至少 400 → 取 512
- 注意：负载因子过低会导致空间浪费；过高会增加链表/红黑树查找开销
结合实际场景做保守估算
如果元素数量波动大，或存在批量插入（如从数据库查出一批记录一次性 putAll），建议按峰值数量计算，而非平均值。另外，Key 的哈希分布质量也影响实际扩容时机——即使容量够，严重哈希碰撞仍可能提前触发树化或影响性能，但这不属于容量设置范畴。
- 日志、缓存类场景常有明确上限，适合精确设容量
- 用户输入驱动的 Map（如表单解析）较难预估，可适度预留 20%~30% 余量
- 不确定时宁可稍大勿小：多占点内存，比频繁 resize（涉及 rehash、数组复制、链表重散列）代价小得多
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
