concurrenthashmap 1.7与1.8的rehash机制虽不同，但核心目标一致：并发扩容时复用节点、避免链表反转与环形结构，并保持单个bin内节点原有相对次序以保障线程安全和遍历正确性；1.7通过segment分段独立扩容并利用lastrun复用尾部链表，1.8则基于cas+synchronized按高位拆分链表为高低两组并尾插重建。
ConcurrentHashMap 在 JDK 1.7 和 JDK 1.8 中的 rehash 机制不同，但核心目标一致：**在并发扩容时尽量复用已有节点、避免链表反转、防止环形结构，同时不破坏读操作的可见性**。它并不严格保持“插入顺序”，而是保证**单个 bin 内链表节点在迁移后仍维持原有相对次序（即从头到尾的遍历顺序不变）**，这是线程安全和避免死循环的关键。
JDK 1.7：分段锁 + 链表尾部重用
ConcurrentHashMap 1.7 使用 Segment 分段锁，每个 Segment 独立扩容。rehash 时对每个 bin 的链表做如下处理：
- 遍历原链表，逐个计算新数组中的下标（index = hash & (newCapacity - 1)）
- 不是简单头插或尾插，而是先扫描整个链表，找到“最后一个连续落在同一新 bin 下标”的节点（称为 lastRun）
- 把 lastRun 及其后续节点整体迁移到新表对应位置，这部分节点完全复用，next 引用未改动
- 前面的节点则逐个新建或克隆，插入到新 bin 的头部（但仅影响局部，不影响 lastRun 段的顺序）
这样做的效果是：即使多个线程并发读取该 bin，只要它们还没读完原链表，就能安全看到完整、有序的旧结构；而新结构中，lastRun 段天然保持原顺序，前面部分虽重建，但因只影响头部且无环，不会导致遍历异常。
JDK 1.8：无锁化 + 拆分链表为高低位两组
1.8 彻底移除 Segment，采用 CAS + synchronized 控制单个桶（Node），rehash 更精细：
- 扩容时，新数组长度翻倍（如 16→32），意味着 hash 计算的掩码多一位，决定是否“高位迁移”
- 对每个非空 bin，遍历原链表/红黑树，按 (e.hash & oldCap) == 0 判断：结果为 0 → 留在原下标；结果非 0 → 迁移到 原下标 + oldCap
- 迁移过程使用尾插法构建新链表：每组节点都按原链表顺序依次追加到新位置的末尾
- 红黑树节点也按同样逻辑拆分为高低两组，再分别重构为树或链表
这确保了：同一组内的节点在新表中仍按原链表顺序排列，不会反转；且因为是尾插，绝不会形成环——哪怕并发写入，每个桶的迁移由单线程负责，顺序自然保留。
为什么顺序不乱，但不等于“插入顺序”？
这里的“相对顺序”指原链表中 A→B→C 的引用关系，在新结构中仍表现为 A→B→C（或拆分为 A→C 和 B 两组，各自内部顺序不变），而非 LinkedHashMap 那种全局插入时间序：
- Hash 表本身不维护全局顺序，bin 之间无先后关系
- 单个 bin 内顺序只服务于遍历正确性和线程安全，不是语义保证
- ConcurrentHashMap 不提供迭代顺序保证，官方文档明确说明其遍历结果不保证一致性
所以它保持的是数据结构层面的安全顺序，不是用户可见的业务顺序。
和 HashMap 尾插法的区别在哪？
HashMap 1.8 改用尾插也是为防环，但它没有并发控制，单线程扩容即可；ConcurrentHashMap 的难点在于：多线程可能同时读旧表、写新表、甚至部分线程还在用旧结构遍历。它的 rehash 设计本质是让旧结构可安全读、新结构可正确建、中间状态不产生环或断裂——顺序稳定只是这一目标的自然结果，不是首要目的。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
