应预设HashMap初始容量为大于预估数量的最小2的幂（如800选1024），合理调整负载因子（默认0.75，读多可调高至0.9，内存敏感可略降），避免循环中未预分配容量导致频繁扩容，并确保key的hashCode分布均匀且稳定。
预设初始容量，避开默认扩容链
HashMap默认初始容量是16，负载因子0.75，即插入第13个元素时就可能触发第一次扩容（16×0.75=12）。扩容需重新哈希所有已有元素，时间复杂度O(n)，频繁发生会明显拖慢性能。如果业务中能预估键值对数量（比如大概存800条记录），直接指定初始容量更稳妥：
- 用new HashMap(initialCapacity)构造，initialCapacity建议设为大于预估值的最小2的幂次（如预估800，选1024）
- 不要写new HashMap(800)——HashMap内部会自动向上取整到最近的2的幂（即1024），但明确给1024更清晰，也避免误传非2幂值引发额外计算
合理设置负载因子，平衡空间与扩容频次
负载因子决定“多满才扩容”。默认0.75是时间与空间的折中。若读多写少、内存充裕，可适当调高（如0.85或0.9），减少扩容次数；若对内存敏感或写入极不均匀，可略调低（如0.6）。但注意：
- 负载因子 > 1.0 是允许的（例如new HashMap(16, 1.2f)），意味着能存19个元素再扩容，适合短生命周期、数量可控的Map
- 负载因子过小会导致大量空间浪费，且桶数组稀疏
，反而降低缓存局部性，影响查询效率
避免在循环中反复put导致隐式扩容
批量插入场景下，一边遍历一边put，容易在中途触发多次扩容。例如从List构建Map时：
- ❌ 错误写法：Map
map = new HashMap(); for (Item item : list) { map.put(item.key(), item.value()); } - ✅ 正确做法：先算好数量，预分配容量：Map
map = new HashMap(list.size() + 1); 再循环put - 更优：用Java 10+的Map.ofEntries()或Stream.collect(Collectors.toMap(...))，底层已做容量优化
注意key的hashCode稳定性与分布质量
扩容本身不可免，但糟糕的hashCode会加剧扩容影响。因为扩容后要rehash，若大量key的hashCode低位相同（如只依赖对象ID末位），在小容量时就易产生长链表，扩容后仍可能聚集，无法利用红黑树优化。
- 自定义key类务必重写hashCode()，尽量混合多个字段，用Objects.hash(...)安全又高效
- 避免用可变字段（如ArrayList引用）作hashCode依据，否则put后修改内容会导致get失败
- 用JDK 8+，当链表长度≥8且桶数组≥64时自动转红黑树，但前提是hashCode分布够散——这是扩容“减负”的前提，不是替代方案
