负载因子是触发hashmap扩容的阈值系数，计算为threshold = capacity × loadfactor；默认0.75f是时间与空间的折中，过小导致频繁扩容，过大加剧哈希冲突；它不直接引发冲突，但通过控制扩容间接影响桶数量和平均链长。
负载因子决定HashMap何时扩容
负载因子（loadFactor）是触发 HashMap 扩容的阈值系数，计算公式为：threshold = capacity × loadFactor。当元素数量达到该阈值时，HashMap 会执行扩容（rehash），将桶数组长度翻倍并重新分配所有键值对。
默认值 0.75f 是时间与空间的折中：太小（如 0.5f）会导致频繁扩容、大量 rehash 开销；太大（如 0.9f）虽减少扩容次数，但哈希冲突概率陡增，链表/红黑树查找变慢。
- 扩容本身耗时：需遍历旧数组、重新计算每个
hash、再插入新数组 - 高负载因子下，单个桶中链表长度易超过
8，触发转红黑树，但树化开销也不小 - 若已知数据量稳定且可预估（如缓存固定 1000 个配置项），可设
initialCapacity避免扩容，此时loadFactor影响变小
哈希冲突不是“碰撞就卡”，而是查找路径变长
哈希冲突指不同 key 经 hashCode() 和扰动函数后映射到同一桶索引。Java 8+ 中，冲突元素以链表或红黑树形式存储在该桶中——这不是错误，而是设计行为。
真正影响性能的是「平均冲突链长度」。它直接受两个因素制约：hash 分布质量（key 的 hashCode() 是否均匀）和桶数量（即当前 capacity）。负载因子不直接制造冲突，但它通过控制扩容时机，间接决定了桶是否足够多来摊薄冲突。
立即学习“Java免费学习笔记（深入）”；
- 若 key 的
hashCode()全返回1（极差实现），哪怕负载因子是0.1，所有元素仍挤在一个桶里 - 若 key 哈希分布理想，负载因子
0.75下平均链长约为1.33；升到0.9后可能接近2.5+，get() 平均比较次数明显上升 - 注意：红黑树仅在链表长度 ≥
8且table.length ≥ 64时才触发，否则仍是链表遍历
什么时候该调低或调高负载因子？
调整 loadFactor 不是调优第一选择，优先确保 key 的 hashCode() 和 equals() 正确且高效。仅在明确瓶颈场景下微调：
- 写多读少、内存充足：可设
loadFactor = 0.5f，用空间换更低冲突率，减少 get() 延迟波动 - 读远多于写、内存敏感：设
loadFactor = 0.9f，但必须配合足够大的initialCapacity，否则首次扩容后立即再扩 - 实时性要求极高（如金融报价缓存）：避免扩容抖动，直接按最大预期 size 计算初始容量：
initialCapacity = (int) Math.ceil(expectedSize / 0.75)，保持默认负载因子即可
Map<String, Object> cache = new HashMap<>(1024, 0.75f); // 明确初始容量，比只调 loadFactor 更有效
别忽略 rehash 过程中的线程安全陷阱
即使你把 loadFactor 设得再合理，HashMap 在扩容时仍会短暂进入不一致状态：新旧 table 并存、部分节点未迁移。这是其非线程安全的根本原因之一。
如果多个线程同时触发扩容（比如并发 put 超过阈值），可能造成链表成环（Java 7）或数据丢失（Java 8+），而这种问题与负载因子大小无关，只与是否并发修改有关。
-
ConcurrentHashMap用分段锁 + CAS 避免全局 rehash 阻塞，但它的扩容是渐进式、多线程协作完成的 - 若必须用
HashMap且有并发写，至少用Collections.synchronizedMap()包一层，但同步粒度是整个 map，吞吐会下降 - 负载因子调得再低，也不能让
HashMap变成线程安全容器
