ConcurrentHashMap链表转红黑树需同时满足：桶中节点数≥8且数组长度≥64；阈值8源于泊松分布（λ=0.5时P(≥8)≈6e-8），64为工程权衡下限，退化阈值设为6以防震荡。
ConcurrentHashMap 通过链表转红黑树，把最差情况下的查询时间复杂度从 O(n) 优化到 O(log n)，显著缓解哈希冲突严重时的性能退化问题。
链表转红黑树的触发条件
不是链表一长就立刻树化，必须同时满足两个硬性条件：
- 当前桶（bin）中的链表节点数 ≥ 8（即
TREEIFY_THRESHOLD = 8） - 整个哈希表的数组长度（
table.length）≥ 64（即MIN_TREEIFY_CAPACITY = 64）
若链表已达 8 个节点但数组还不到 64，ConcurrentHashMap 会优先选择扩容（rehash），把元素分散到更多桶中，而不是直接树化——这是用空间换时间的务实策略。
为什么阈值设为 8 和 64？
这背后有统计学依据和工程权衡：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 根据泊松分布，在负载因子 0.75 下，哈希均匀时，链表长度超过 8 的概率低于千万分之一，说明 8 是一个极低频事件的临界点
- 64 是经验下限：数组太小（如初始容量 16）时强行树化，会导致大量小红黑树，反而增加内存开销与维护成本
- 红黑树节点比链表节点多存 parent/left/right/red 等字段，空间占用更大，只在真正必要时启用
树化如何提升查询性能
在高并发且 key 分布不均（例如大量 key 哈希值相同）的场景下：
- 纯链表查找需逐个遍历，平均比较次数 ≈ n/2，最坏达 n 次
- 红黑树是自平衡二叉搜索树，任意路径长度不超过 2log₂n，100 个节点最多查 14 次，而链表平均要 50 次
- ConcurrentHashMap 对红黑树的读操作（如
get()）基本无锁，仅靠 volatile 引用和节点结构保证可见性，查询高度并发友好
红黑树还会退化回链表
这不是单向升级，而是动态适应：
- 当红黑树节点数 ≤ 6（
UNTREEIFY_THRESHOLD = 6）时，会自动转回链表 - 退化通常发生在删除操作后，或扩容导致该桶内元素大幅减少时
- 这样避免了“轻量级操作”（如少量元素）还要承担红黑树的结构维护开销
