hashmap在元素数量达12（16×0.75）时即触发扩容，而非填满才扩；存千条数据若用默认构造器将多次扩容致性能雪崩；扩容是数组长度翻倍重建，阈值按capacity×loadfactor向下取整计算。
扩容触发条件：别等满才动，12个就该扩了
HashMap不是等数组填满才扩容的——默认容量16 × 负载因子0.75 = 12，插入第13个元素时立刻扩容。这是主动“防堵”，不是被动“救火”。如果业务明确要存上千条数据，却用默认构造器：new HashMap()，那会连续触发多次扩容（16→32→64→128…），每次都要遍历、重哈希、迁移节点，性能雪崩。
- 临界值计算公式始终是：
threshold = capacity * loadFactor，不是四舍五入，是向下取整后的整数比较 - 扩容不是“加几个格子”，而是整个数组重建为原长度的2倍（
oldCap ），比如16→32，32→64 - 最大容量卡在
1 （即1073741824），再大就不再扩容，<code>threshold设为Integer.MAX_VALUE
扩容时怎么搬数据：位运算判断去哪，不重算hash
JDK 8 的扩容不是暴力遍历每个元素再调一次 hashCode()，而是用一个极简位运算：e.hash & oldCap。因为旧容量 oldCap 是2的幂，它的二进制只有一位是1（如16=0b10000），这个运算本质上是在看 hash 值在这一位上是0还是1：
- 结果为
0→ 新位置 = 原索引（留在老地方） - 结果为非零（实际就是
oldCap）→ 新位置 = 原索引 +oldCap（挪到后半区） - 链表节点保持原有顺序（尾插法），红黑树也按此规则拆分两棵，不打乱结构
这比重新 hash % newCap 快得多，也避免了 JDK 7 头插法导致的多线程死循环问题。
负载因子为什么是0.75：不是玄学，是泊松分布算出来的
0.75 不是拍脑袋定的。它背后是哈希均匀分布假设下的概率权衡：当负载因子为0.75时，桶中链表长度为8的概率约为 0.00000006（泊松分布推导），足够小，所以把树化阈值设为8才合理。换言之，0.75让“链表转红黑树”这件事极少发生，但一旦发生，说明冲突已严重，值得升级结构。
立即学习“Java免费学习笔记（深入）”；
- 设成
1.0？内存省了，但冲突剧增，O(1)退化成 O(n)，尤其在哈希码分布差的场景（如大量 Integer key 用小范围值） - 设成
0.5？扩容太勤，空间浪费翻倍，GC压力上升，对缓存局部性也不友好 - 实际调优建议：若 key 哈希质量高（如 UUID、良好重写的
hashCode()），可尝试0.8；若 key 是简单整数或字符串前缀雷同，建议0.6～0.7
预分配容量的实操口诀：除以0.75，向上取整再找2次幂
想彻底避开扩容开销？初始化时就给足空间。比如预计存 1000 个键值对，不要写 new HashMap(1000)——它会自动找最近的2次幂，即 1024，但阈值是 1024 * 0.75 = 768，第769个就扩了。正确做法是反推最小容量：
- 计算理论最小容量：
(int) Math.ceil(1000 / 0.75)≈1334 - 找 ≥1334 的最小2次幂：
2048（因为1024 ） - 构造：
new HashMap(2048)→ 阈值 =2048 * 0.75 = 1536，1000个完全不扩容
注意：JDK 内部会把传入的初始容量向上规整为2次幂，但你仍得自己算清楚，否则可能白传——比如传 1000，它变成 1024，但阈值只有768，照样扩。
