ConcurrentHashMap在JDK 8中树化需同时满足链表长度≥8、数组容量≥64且成功加锁，退化仅在扩容迁移后节点数≤6时批量触发，行为比HashMap更谨慎，以降低并发开销和内存抖动。
ConcurrentHashMap 在 JDK 8 中的红黑树树化与退化机制，**基本沿用 HashMap 的阈值设计，但行为更谨慎、触发条件更严格**。
树化阈值：链表长度 ≥ 8 且桶数组容量 ≥ 64
与 HashMap 一致，ConcurrentHashMap 的单个 bin（桶）中链表长度达到 TREEIFY_THRESHOLD = 8 时，并不会立即树化。必须同时满足：
- 当前 bin 的链表节点数 ≥ 8
- 整个 table 的 length ≥ MIN_TREEIFY_CAPACITY = 64
- 该 bin 处于“无锁”或已成功获取写锁状态（因并发安全要求，树化需加锁）
不满足容量条件时，优先触发扩容而非树化——这点和 HashMap 完全相同，本质是小表扩容比建树更轻量、更高效。
退化阈值：红黑树节点数 ≤ 6 时转回链表
ConcurrentHashMap 的退化阈值同样是 UNTREEIFY_THRESHOLD = 6，但退化时机有关键差异：
立即学习“Java免费学习笔记（深入）”；
- 退化只发生在 扩容（transfer）过程中，不是每次 remove() 或 resize() 都检查
- 仅当某棵树在迁移后剩余节点数 ≤ 6，才会调用
untreeify()拆成普通链表 - 不会因单次删除就立刻退化——避免高并发下频繁结构切换带来的锁竞争和内存抖动
为什么 ConcurrentHashMap 的树化更“克制”？
它不是简单复制 HashMap 的逻辑，而是叠加了并发控制约束：
- 树化操作需对 bin 加独占锁（
lock），而扩容时多个线程协作迁移，树化可能阻塞其他线程 - 红黑树节点（
TreeBin）本身包含读写锁字段，内存开销更大；在多线程场景下，空间成本被进一步放大 - 实际压测表明：在典型并发负载下，绝大多数 bin 仍维持链表形态；真正树化的 bin 往往集中在热点 key 或异常哈希分布区域
和 HashMap 的核心区别总结
两者共享同一套阈值常量（8/6/64），但 ConcurrentHashMap 的执行逻辑更保守：
- 触发门槛更高：除长度和容量外，还需获得锁、避开扩容竞争段等运行时条件
- 退化更延迟：不响应局部删除，只在全局扩容迁移时批量判断
-
结构封装不同：ConcurrentHashMap 的红黑树由
TreeBin包裹，内部维护读写锁，而非直接使用TreeNode
