合理设置初始容量需按预估数据量÷负载因子后向上取整再取不小于该值的最小2的幂，如100个元素应设256；加载因子默认0.75为时空平衡点，非必要不修改；推荐显式构造如new hashmap(256, 0.75f)，避免默认构造引发多次扩容。
关键在预估数据量并匹配底层机制，避免频繁扩容和哈希冲突。
初始容量怎么设才合理
不要用默认的 16。如果知道大概要存多少个键值对，就按公式算：
- 先除以负载因子（默认 0.75），再向上取整：比如预估存 100 个，100 ÷ 0.75 ≈ 133.3 → 取 134
- HashMap 会自动把容量调整为不小于该值的最小 2 的幂，134 对应的是 128？不对，128 小于 134，所以下一个是 256
- 所以直接传入 256 更稳妥；也可调用 tableSizeFor(134) 得到 256
- 如果容量设太小，比如只设 64 却塞了 100 个元素，很快触发扩容（64×0.75=48），接着 128、256……每次都要 rehash，性能明显下降
加载因子不是越小越好
默认 0.75 是空间与时间的平衡点，改它要有明确理由：
- 想减少哈希冲突、提升查询速度？可降到 0.6 或 0.5，但内存占用会上升约 20%～40%
- 内存极其紧张且读操作少？可提高到 0.8 或 0.85，但链表更容易变长，get 操作平均耗时上升
- 除非有压测数据支撑，否则不建议动加载因子；优先调容量更安全有效
构造时一步到位，别依赖默认行为
写法上直接指定参数，别让 HashMap 自己猜：
- ✅ 推荐：new HashMap(256, 0.75f) —— 容量明确，加载因子保留默认
- ✅ 若需微调：new HashMap(512, 0.6f) —— 适合高频读、低内存压力场景
- ❌ 避免：new HashMap() 后反复 put 上百个元素 —— 至少触发 3 次扩容
- ❌ 避免传奇数或非 2 的幂（如 100、200）—— HashMap 仍会转成 128、256，多一次计算无实质收益
配合其他细节一起看效果
光调容量和加载因子还不够，注意这些配套点：
- key 的 hashCode() 要尽量均匀，避免大量哈希值集中在低位
- 别用可变对象作 key（比如 ArrayList），否则可能找不到原值
- 如果单个桶里老是堆积超过 8 个元素，且数组长度 ≥ 64，说明容量还是偏小或 hash 分布差
- 用 size() 和 capacity()（需反射或 JOL 工具）观察实际占用，验证优化是否生效
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
