- 正确答案：ConcurrentHashMap 在 JDK 1.7 和 JDK 1.8 中的实现机制存在根本性差异：JDK 1.7 采用分段锁（Segment + HashEntry 数组 + 链表）的粗粒度并发控制，而 JDK 1.8 改为基于 CAS + synchronized + Node 数组 + 链表/红黑树的细粒度锁机制，取消了 Segment，整体更接近 HashMap 的结构但强化了并发安全。 - 解答思路：首先明确问题核心是“并发实现机制演进”，需从数据结构、锁粒度、线程安全手段、扩容机制、哈希冲突处理等维度对比。JDK 1.7 的 Segment 是可重入锁（ReentrantLock）的封装，每个 Segment 独立加锁，锁粒度为段级（默认16段）；JDK 1.8 则完全摒弃 Segment，对单个数组桶（bin）头节点使用 synchronized 加锁（锁对象为该 Node），锁粒度细化到单个链表/红黑树的头结点，配合无锁的 CAS 操作（如 putIfAbsent、computeIfAbsent 等），显著提升高并发下的吞吐量。同时，1.8 引入红黑树优化长链表查找性能（链表长度 ≥ 8 且 table.length ≥ 64 时树化），而 1.7 始终仅用链表。 - 深度知识讲解：【底层数据结构】 • JDK 1.7：内部维护一个 Segment 数组（默认大小 16），每个 Segment 继承 ReentrantLock，包含一个 HashEntry 数组（volatile 修饰），HashEntry 是链表节点，使用 volatile 的 next 字段保证可见性，但不支持 CAS 更新（因 next 是 final 字段，实际通过创建新节点+头插法实现无锁读）。 • JDK 1.8：直接使用 Node 数组（transient volatile Node[] table），Node 是普通静态内部类，next 字段非 final，支持 CAS 修改；引入 TreeNode（红黑树节点）和 TreeBin（红黑树容器节点，含读写锁 state 字段用于控制并发树操作）；ForwardingNode 用于扩容期间标记迁移中的桶。【锁机制与线程安全】 • JDK 1.7：写操作需获取对应 Segment 的独占锁（如 put(key,val) 先 hash 定位 segmentIndex，再 lock()），读操作无需加锁（依赖 volatile 变量和 final 域的内存语义保证可见性），但存在“弱一致性”——可能读到过期值（如 size() 需尝试 2 次加锁统计，仍可能不准）。 • JDK 1.8：put 操作首先无锁 CAS 尝试插入到空桶；若桶非空，则对桶首节点（即链表头或 TreeBin）加 synchronized 锁（锁对象为该节点本身），在临界区内完成链表插入或树化逻辑；扩容时使用多线程协作迁移（transfer 方法），每个线程负责一段 stride 区间，并通过设置 tab[i] = ForwardingNode 协作标识；size() 使用 CounterCell 数组 + baseCount + 高并发累加器思想（类似 LongAdder），避免全局竞争。【扩容机制】 • JDK 1.7：扩容由单个线程完成，需 lock 所有 Segment（实际是依次 lock 每个 Segment），阻塞所有写操作，扩展性差。 • JDK 1.8：支持多线程协同扩容（helpTransfer），新表 nextTable 创建后，原表每个桶迁移由首个发现该桶为 ForwardingNode 的线程触发，其他线程可协助迁移；迁移过程将桶中节点按 hash & oldCap 分成低位链（留在原位置）和高位链（移到 i + oldCap），保证 rehash 后顺序性；迁移完成前，get 操作仍可正确读取（ForwardingNode 的 find 方法会递归查新表）。【哈希冲突与性能】 • JDK 1.7：链表头插法（并发下可能导致环形链表，但 JDK 1.7 实际未出现死循环，因 HashEntry.next 是 volatile 且写操作加锁，但存在 ABA 和可见性边界问题）；最坏 O(n) 查找。 • JDK 1.8：链表尾插法（避免环形链表风险）；当链表长度 ≥ 8 且 table.length ≥ 64 时，触发树化（treeifyBin），转为红黑树，查找降为 O(log n)；退化条件：红黑树节点数 ≤ 6 时转回链表。树化/反树化均在 synchronized 临界区内完成，TreeBin 内部用读写锁（state 字段：0=无锁，-1=写锁，正数=等待读线程数）协调并发读写。【关键字段与内存模型】 • JDK 1.7：Segment 中的 count（volatile int）、modCount（volatile int）、table（volatile HashEntry[]）共同保障可见性；但 size() 不保证强一致性。 • JDK 1.8：table、nextTable、baseCount、counterCells 均为 volatile；Node 的 val 和 next 字段为 volatile（通过 Unsafe.putObjectVolatile 等保证）；CAS 操作基于 Unsafe.compareAndSwapXXX 实现，如 tabAt、casTabAt、setTabAt 等工具方法封装了 volatile 读写与 CAS。 - 伪代码/关键逻辑片段（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()); // 高位参与扰动 int binCount = 0; for (Node[] tab = table;;) { Node f; int n, i, fh; if (tab == null || (n = tab.length) == 0) tab = initTable(); // 懒初始化，CAS 设置 table else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) { // 桶为空，CAS 插入新节点 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 && ((ek = e.key) == key || (ek != null && key.equals(ek)))) { 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); // 链表长度达标且 table 足够大则树化 break; } } } addCount(1L, binCount); // 更新计数器 return oldVal; } ``` - 扩展知识： • 为什么 JDK 1.8 不再需要 Segment？因为 synchronized 在 JDK 1.6+ 经过锁优化（偏向锁→轻量级锁→重量级锁），性能已接近 ReentrantLock，且更轻量；而 CAS 配合细粒度锁可极大减少线程阻塞，尤其在热点桶较少的场景下优势明显。 • ConcurrentHashMap 不支持 null 键/值，因 null 在 get 中无法区分“不存在”和“值为 null”，且会破坏 CAS 判断逻辑（如 tabAt 返回 null 可能是空桶或被删除节点）。 • 与 Collections.synchronizedMap 对比：后者是全表锁，吞吐量低；ConcurrentHashMap 是分段/分桶锁，适合读多写少场景；若需更强一致性（如遍历过程中不允许修改），应使用 CopyOnWriteArrayList 或客户端加锁。 • Spring 框架中 BeanFactory 的 singletonObjects 缓存即使用 ConcurrentHashMap，利用其高并发读性能支撑 IOC 容器高频 getBean 调用。

美团暑期一面

全站热榜

创作者周榜