ConcurrentHashMap 1.7 通过 Segment 数组实现分段锁，每个 Segment 是独立的 ReentrantLock + 小型哈希表，put 仅锁定对应 Segment，get 完全无锁；但存在哈希倾斜退化、size() 阻塞等问题，故 1.8 改用 CAS + synchronized 锁单个 Node 并引入树化优化。
分段锁在ConcurrentHashMap 1.7里怎么实现的
ConcurrentHashMap 1.7 的分段锁本质是把整个哈希表切成了 Segment 数组，每个 Segment 是一个独立的 ReentrantLock + 小型哈希表。写操作（如 put）只锁住对应 key 落入的那个 Segment，其他段还能并发读写。
常见错误现象：以为“分段”能彻底避免锁竞争——其实如果大量 key 哈希后落在同一个 Segment（比如自定义 hashCode 返回固定值），那它就退化成单点瓶颈，吞吐不升反降。
实操建议：
-
concurrencyLevel参数只是初始化Segment数组长度的提示值，不是硬上限；实际段数会取大于等于该值的最小 2 的幂（如传 10 → 实际用 16 段） - 每个
Segment内部仍是数组 + 链表，扩容时只扩本段，但size()需要尝试加锁所有段来累加，可能阻塞较久 - JDK 1.7 的
get()完全无锁，靠volatile变量和不可变节点保证可见性——这点常被误认为“读也加锁”，其实不是
为什么 1.8 彻底干掉了 Segment
因为 Segment 带来额外内存开销（每个段都有一套 table、count、modCount 等字段），且无法解决单个桶（bin）的并发冲突——只要两个线程往同一个链表头插入，还是得串行。
立即学习“Java免费学习笔记（深入）”；
1.8 改用“CAS + synchronized 锁单个 Node”：数组元素（Node）本身作为锁粒度，配合 TreeBin 在链表过长时转红黑树，进一步降低哈希碰撞下的查找/插入成本。
实操建议：
- 1.8 的
put()先无锁 CAS 插入头节点，失败才用synchronized (f)锁住该桶的首节点（f），不是锁整个 table - 扩容（
transfer）变成协作式迁移：多个线程可同时参与搬数据，每个线程负责一段table区间，通过stride控制粒度 - 注意
computeIfAbsent这类方法在 1.8 中可能触发树化或扩容，若 lambda 里有阻塞操作，会卡住整个桶，影响其他线程对该桶的操作
从 1.7 升级到 1.8 后哪些行为变了
最易踩坑的是迭代器语义和 size() 行为差异：1.7 的 keySet().iterator() 是弱一致性（weakly consistent），允许遍历时修改；1.8 的迭代器仍弱一致，但内部结构变化更频繁（树/链表切换、扩容中迁移），导致某些遍历结果更“跳跃”。
性能上，1.8 在高并发写+低哈希碰撞场景下优势明显；但若写操作极少、读极多，1.7 的无锁 get() 和更简单的结构反而更轻量。
实操建议：
-
size()在 1.7 中需加锁统计所有Segment，可能慢；1.8 改用baseCount + CounterCell[]的 CAS 累加，但仍是近似值——严格计数请改用mappingCount() - 1.8 不再支持
rehash相关监控（如segments字段已不存在），依赖反射或 JMX 查看内部状态的代码会直接失败 - 自定义
Comparator用于树化时，必须满足与equals()一致的逻辑，否则containsKey可能返回 false（即使 key 存在）
现在还该手动分段锁吗
几乎不该。除非你在 JDK 1.7 环境下维护老系统，或者面对的是极特殊场景：比如某个业务 key 天然聚合成几十个大组，每组内操作高度隔离，且你愿意承担自己实现锁分片、负载均衡、扩容协调的复杂度。
现实中，JDK 1.8 的 ConcurrentHashMap 已经把锁粒度压到单个桶，配合 CAS 和树化，对绝大多数场景足够。手动分段反而容易引入死锁（比如跨段操作没按固定顺序加锁）、状态不一致（段间计数不同步）等问题。
真正要注意的其实是：别把 ConcurrentHashMap 当作通用线程安全容器去塞各种复杂对象——它的线程安全只保障自身结构变更，value 对象内部状态是否线程安全，它不管。
