HashMap性能由loadFactor与capacity共同决定，二者通过threshold=capacity×loadFactor联动控制扩容时机；capacity须为2的幂以支持位运算索引定位，默认16；loadFactor默认0.75，平衡空间与查询效率；实际capacity会向上对齐至2的幂，threshold据此动态计算。
Java中Map接口的典型实现HashMap，其性能直接受loadFactor（负载因子）和capacity（容量）两个初始化参数影响。这两个参数共同决定哈希表何时扩容、内存占用多少、以及get/put操作的平均时间复杂度。它们不是孤立存在的，而是通过阈值threshold = capacity × loadFactor联动起作用。
capacity 决定底层数组长度与空间开销
capacity 指的是哈希表中“桶”（bucket）的数量，也就是底层Node数组的长度。它必须是2的幂次方（如16、32、64），这样能用位运算(hash & (capacity - 1))快速定位索引，替代取模运算，提升效率。
- 默认初始容量为16；若明确知道要存约100个键值对，直接设为128比用默认值再经历多次扩容更高效
- 容量过大会浪费内存（空桶多），尤其在迭代keySet或entrySet时，遍历时间与
capacity成正比，而非只与实际元素数相关 - 容量过小会频繁触发扩容——每次扩容都要重新计算所有元素的哈希、重分配到新数组，是O(n)操作，显著拖慢put性能
loadFactor 控制扩容时机与冲突概率的平衡
loadFactor 是一个浮点数，默认0.75，表示“桶被填满”的容忍度。当实际元素个数size ≥ capacity × loadFactor时，就触发扩容。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 设为0.5：提前扩容，桶更稀疏，哈希冲突少，查询快，但内存占用高、扩容更频繁
- 设为0.9：延迟扩容，内存更省，但桶更拥挤，链表变长（甚至触发树化），get/put平均耗时上升
- 0.75是JDK权衡后的经验值：在空间利用率和查找效率之间取得较好折中
二者协同决定 threshold 和实际行为
threshold（阈值）不是构造时直接传入的参数，而是由capacity × loadFactor推导出的整数。它才是真正控制扩容开关的临界值。
立即学习“Java免费学习笔记（深入）”；
- 例如：
new HashMap(20, 0.75f)→ 实际capacity会被向上对齐为32（因必须是2的幂），threshold = 32 × 0.75 = 24 - 插入第24个元素后，下一次put（第25个）就会触发扩容，容量变为64，threshold更新为48
- 所以“指定20”不会让容量真变成20，但会影响最终对齐结果和阈值起点
实际使用建议
避免依赖默认配置，尤其在性能敏感或数据量可预估的场景：
- 已知要存N个键值对 → 初始capacity建议设为大于等于
N / 0.75的最小2的幂（如N=100 → 100/0.75≈133.3 → 取256） - 读多写少、对查询延迟极度敏感 → 可适当降低loadFactor（如0.6），减少冲突
- 内存受限、写入集中且后续几乎只读 → 可略提高loadFactor（如0.85），但需注意链表/红黑树退化风险
- 永远不要传入非2的幂的capacity——HashMap会自动调整，但可能偏离你的预期
