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 实现。