concurrenthashmap 默认 loadfactor 为 0.75 是工程权衡最优解，兼顾哈希冲突概率、内存占用与扩容开销；过高（如0.9）加剧碰撞、锁争用与树化开销，过低（如0.5）则浪费内存、增加扩容频次且损害缓存局部性。
ConcurrentHashMap 的 loadFactor 为什么默认是 0.75？
因为 0.75 是在并发场景下，对哈希冲突概率、内存占用、扩容开销三者反复权衡后的工程最优解——不是数学推导出的唯一答案，而是实测+统计模型（泊松分布）验证过的稳定拐点。
负载因子设高了（比如 0.9）会怎样？
看似省内存、少扩容，但在并发写入时问题立刻暴露：
-
put操作更容易撞到同一个桶（bin），导致链表变长，get和put都要遍历更久； - Segment 或 Node 数组局部过载，锁竞争加剧（尤其在旧版 JDK 7 的 Segment 分段锁中）；
- 树化阈值（8）更容易被触发，但红黑树在高并发写入下建树/拆树开销大，反而拖慢整体吞吐；
- JDK 8+ 的
TreeBin虽优化了并发树操作，但负载过高仍会显著抬高transfer扩容期间的读写阻塞时间。
能不能手动调低（比如设成 0.5）来换性能？
能，但不推荐盲目下调——它带来的收益有限，副作用却很实在：
- 初始容量翻倍（如从 16 → 32），空数组更多，GC 压力略增；
- 扩容更频繁，每次
transfer都要重新计算 hash、迁移节点，在高并发写入时反而放大 CPU 和内存带宽争用； - ConcurrentHashMap 的核心优势本就是「分段无锁化」，过度稀疏并不能线性提升并发度，反而让 CPU cache 局部性变差；
- 只有在极少数场景（如 key 分布极度不均 + 读远多于写 + 内存完全不是瓶颈）才值得试，且必须配合压测验证
get平均延迟和put吞吐变化。
源码里哪几处真正依赖这个 0.75？
它不是魔法数字，而是直接参与两个关键计算：
- 构造时算初始
size：传入initialCapacity=100，实际数组容量向上取 2 的幂（128），但threshold = 128 * 0.75 = 96，第 97 个元素才会触发扩容； -
transfer过程中判断是否需要树化：每个 bin 的节点数超过 8 且 table.length ≥ 64 才转红黑树，而 0.75 保证了在常规使用下，bin 长度 > 8 的概率极低（泊松分布 λ=0.5 时，P(k≥8) ≈ 6×10⁻⁸）； - 注意：
concurrencyLevel（JDK 7）或parallelismLevel（JDK 8+）控制的是并发段数，和loadFactor无关，别混淆。
真正容易被忽略的是：这个 0.75 是针对「平均分布」假设的，如果你的 key 哈希值本身有强偏斜（比如大量 key.hashCode() 返回相同值），再调低 loadFactor 也救不了——得先修 hashCode 实现。
