- 正确答案： ConcurrentHashMap 在 JDK 1.7 和 JDK 1.8 中的实现机制存在根本性差异：JDK 1.7 采用分段锁（Segment + HashEntry 数组 + 链表）的粗粒度并发控制；JDK 1.8 则彻底摒弃 Segment，改用 CAS + synchronized（锁单个链表头节点或红黑树根节点）+ Node 数组 + 链表/红黑树的细粒度锁优化方案，更接近 HashMap 的并发增强版。 - 解答思路：要对比两个版本的实现，需从数据结构、并发控制机制、扩容策略、线程安全保证方式、性能瓶颈等维度逐层拆解。核心在于理解“如何在不牺牲并发度的前提下保障线程安全”，因此需聚焦锁粒度变化带来的影响——从“锁一段”（Segment 级别）到“锁一个桶”（Node 链表头），再到“锁树根”，本质是将锁范围最小化，并大量依赖无锁原子操作（CAS）完成非冲突路径。 - 深度知识讲解：【JDK 1.7 实现细节】 - 底层结构：由若干个 Segment 组成的数组（默认 16 个），每个 Segment 是 ReentrantLock 的子类，内部维护一个 HashEntry 数组（即“段内哈希表”），HashEntry 是 final 的 volatile 节点，其 next 字段为 volatile，保证链表可见性。 - 并发模型：Segment 继承自 ReentrantLock，put 操作需先定位 segment（hash >>> 16 & (segments.length - 1)），再对该 segment 加锁（可重入），锁住整个段后执行插入/更新。不同 segment 可并行操作，最大并发度 ≈ segments.length（默认 16）。 - 扩容：每个 Segment 独立扩容（rehash），无需全局同步，但扩容时仍需独占该 segment 锁，且扩容后新 table 对其他线程立即可见（因 HashEntry.next 是 volatile）。 - 缺陷： • Segment 是重型锁，即使只修改一个桶，整段被锁； • 多级哈希（先算 segment 索引，再算 entry 索引），计算开销略大； • 无法利用 CPU 缓存行对齐优化； • 删除时需加锁，读操作虽不用锁但依赖 volatile 保证可见性（get 不加锁，但依赖 HashEntry.value 的 volatile 语义和 next 的 volatile 传递性）。【JDK 1.8 实现细节】 - 底层结构：与 HashMap 完全一致的基础结构 —— Node[] table（volatile 修饰），每个桶是 Node 单向链表或 TreeNode（红黑树）；Node 类中 key、hash、next 均为 final，val 为 volatile（保证写入可见性）；TreeNode 继承自 Node，额外包含 parent、left、right、red 等字段。 - 并发模型： • 初始化：通过 Unsafe.compareAndSwapObject 控制 table 初始化，仅首个线程成功初始化，其余忙等； • put 操作： - 若 table 未初始化，先尝试初始化（CAS 设置 sizeCtl）； - 计算 tab[i] = (n - 1) & hash，若该桶为空，直接 CAS 插入新 Node； - 若桶为 ForwardingNode（正在扩容），则协助扩容（helpTransfer）； - 若桶有值，则对该桶首节点加 synchronized 锁（synchronized(f = tabAt(tab, i))），再遍历链表或树进行插入； - 插入后若链表长度 ≥ TREEIFY_THRESHOLD（8）且 table.length ≥ MIN_TREEIFY_CAPACITY（64），则触发 treeifyBin（可能转红黑树）； • 扩容：多线程协作扩容（transfer 方法），使用 sizeCtl 控制扩容状态（负数表示正在扩容，-1 表示初始化中，-(1 + 扩容线程数) 表示参与扩容的线程数）；每个线程负责迁移若干个桶（stride = MAX(16, n/NCPU)），迁移时将原桶设为 ForwardingNode，其他线程遇到该节点即去协助迁移； • get 操作：完全无锁，仅通过 volatile 读（U.getObjectVolatile(table, ((long)i << ASHIFT) + ABASE)）获取 Node，再遍历链表/树，依赖 volatile 变量的 happens-before 语义保证可见性； • size()：不再维护精确计数（避免高并发下计数器竞争），改用 baseCount + CounterCell[] 的分段计数（类似 LongAdder），最终调用 sumCount() 汇总，结果可能滞后于实时值。【关键底层原理与对比】 1. 锁粒度：JDK 1.7 是 Segment 级（≈16把锁），JDK 1.8 是桶级（理论上最多 n 把锁，实际远少于 n，因多数桶为空或只读）； 2. 内存模型依赖：1.7 重度依赖 volatile HashEntry.next 与 final 字段的语义；1.8 更依赖 Unsafe 的 volatile 读写 + synchronized 的 monitor 语义 + final 字段的初始化安全发布； 3. 扩容机制：1.7 是各 Segment 独立 rehash；1.8 是全局协作式迁移，支持动态扩容中继续读写（ForwardingNode 作为中间态），真正实现“扩容不影响服务”； 4. 树化条件：1.8 引入红黑树解决链表过长导致的 O(n) 查找问题，但树化前提是 table.length ≥ 64，避免小表频繁树化开销； 5. CAS 使用密度：1.8 几乎所有非冲突路径（初始化、空桶插入、头结点判断、sizeCtl 修改）均用 CAS，而 1.7 仅用于初始化和部分计数； 6. 内存布局：1.8 消除 Segment 对象，减少对象头和引用开销，更紧凑；同时利用 @Contended 注解（需 JVM 启动参数 -XX:-RestrictContended）缓解伪共享（如 CounterCell），但默认未启用。 - 代码示例（JDK 1.8 put 核心逻辑伪代码）： ``` final V putVal(K key, V value, boolean onlyIfAbsent) { if (key == null || value == null) throw new NullPointerException(); int hash = spread(key.hashCode()); // 高位参与运算：(h ^ (h >>> 16)) & HASH_BITS int binCount = 0; for (Node[] tab = table;;) { Node f; int n, i, fh; if (tab == null || (n = tab.length) == 0) tab = initTable(); // CAS 初始化 else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) { if (casTabAt(tab, i, null, new Node(hash, key, value, null))) break; // 插入成功 } else if ((fh = f.hash) == MOVED) tab = helpTransfer(tab, f); // 协助扩容 else { V oldVal = null; synchronized (f) { // 锁住链表头节点 if (tabAt(tab, i) == f) { if (fh >= 0) { // 链表 binCount = 1; for (Node e = f;; ++binCount) { if (e.hash == hash && ((e.key == key) || (key != null && key.equals(e.key)))) { oldVal = e.val; if (!onlyIfAbsent) e.val = value; break; } Node pred = e; if ((e = e.next) == null) { pred.next = new Node(hash, key, value, null); break; } } } else if (f instanceof TreeBin) { // 红黑树 Node p; binCount = 2; if ((p = ((TreeBin)f).putTreeVal(hash, key, value)) != null) { oldVal = p.val; if (!onlyIfAbsent) p.val = value; } } } } if (binCount != 0) { if (binCount >= TREEIFY_THRESHOLD) treeifyBin(tab, i); // 尝试树化 if (oldVal != null) return oldVal; break; } } } addCount(1L, binCount); // 更新计数器 return null; } ``` - 扩展知识： • ConcurrentHashMap 不支持 key 或 value 为 null（否则无法区分缺失与 null 值，且 null 会破坏 CAS 判断逻辑）； • computeIfAbsent / compute 等方法在 JDK 1.8 中基于 synchronized + 重试机制实现，确保函数式操作的原子性； • 与 Collections.synchronizedMap 相比，ConcurrentHashMap 并发度更高、扩展性更好，但迭代器仍是弱一致性（weakly consistent）：不抛 ConcurrentModificationException，可反映部分更新，但不保证反映所有更新； • JDK 9+ 引入 VarHandle 替代 Unsafe，但 ConcurrentHashMap 内部仍兼容 Unsafe（未来可能迁移）； • 生产建议：若读多写少，可考虑使用 ConcurrentHashMap；若写压力极大且需强一致性计数，应评估 LongAdder + 外部锁组合方案；避免在 lambda 中对 map 做结构性修改（如 compute 中再 put），易引发死锁或无限重试。

同程一面

全站热榜

创作者周榜