- 正确答案：ConcurrentHashMap 是 Java 中用于高并发场景下的线程安全的哈希表实现，位于 java.util.concurrent 包中。它允许多个线程同时读取和写入而不需要对整个容器加锁，通过分段锁（JDK 1.7）或 CAS + synchronized（JDK 1.8 及以后）机制来保证线程安全。 - 解答思路：在面试中被问到 ConcurrentHashMap 时，应从以下几个方面回答： 1. 基本定义与用途：说明它是线程安全的 HashMap，适用于高并发环境。 2. 实现原理的演进：区分 JDK 1.7 和 JDK 1.8 的不同实现方式。 3. 核心机制：如分段锁、CAS、synchronized 锁升级等。 4. 性能优势：相比 Hashtable 或 synchronized Map，其并发性能更高。 5. 关键方法的行为：如 get、put、remove 的线程安全性。 6. 扩容机制与并发控制：特别是在 JDK 1.8 中的多线程协助扩容。 - 深度知识讲解：一、JDK 1.7 实现原理（分段锁 Segment）在 JDK 1.7 中，ConcurrentHashMap 使用了“分段锁”机制。整个哈希表被分成多个 Segment（段），每个 Segment 继承自 ReentrantLock，是一个独立的可重入锁。每个 Segment 管理一个 HashEntry 数组（类似于 HashMap 的 Entry 链表）。结构示意： ConcurrentHashMap → Segment[0] ~ Segment[N] ↓ HashEntry 链表 put 操作流程： 1. 计算 key 的 hash 值。 2. 根据 hash 值定位到某个 Segment。 3. 对该 Segment 加锁（ReentrantLock），然后执行插入操作。 4. 插入完成后释放锁。 get 操作：由于 HashEntry 的 value 和 next 指针声明为 volatile，因此读操作无需加锁，直接通过内存可见性保证一致性。并发度（concurrencyLevel）：初始化时指定，默认为 16，表示最多支持 16 个线程并发写入（每个 Segment 一把锁）。但实际并发度受限于 Segment 数量。缺点： - Segment 固定大小，无法动态扩展。 - 内存占用较高。 - 锁粒度仍不够细。二、JDK 1.8 实现原理（CAS + synchronized） JDK 1.8 彻底重构了 ConcurrentHashMap，放弃 Segment 设计，采用更现代的方式： - 底层数据结构：Node 数组 + 链表 + 红黑树（与 HashMap 一致） - 同步机制：使用 CAS（Compare and Swap）操作结合 synchronized 关键字对链表头节点或红黑树根节点加锁核心类结构： transient volatile Node[] table; // 主数组 private transient volatile Node nextTable; // 扩容时用的新数组 private transient volatile long baseCount; // 元素总数计数器 private transient volatile int sizeCtl; // 控制标识符： // -1: 正在初始化 // -N: 正在扩容（高位记录线程数） // >0: 初始容量或下次扩容阈值 Node 节点定义： static class Node implements Map.Entry { final int hash; final K key; volatile V val; // 值是 volatile，保证可见性 volatile Node next; // 下一个节点也是 volatile } put 方法（putVal）关键步骤： 1. 如果 table 为空，先进行懒加载初始化（通过 CAS 设置 sizeCtl 来竞争初始化权）。 2. 计算索引位置 i = (n - 1) & hash。 3. 若该槽位为空，尝试用 CAS 插入新节点。 4. 若该槽位已存在节点（f）： - 检查是否为 MOVED 节点（即 forwarding node，hash == -1），表示正在扩容，则当前线程协助扩容。 - 否则对该槽位头节点 f 加 synchronized 锁，然后遍历链表或红黑树插入。（注意：只锁住当前桶，不是整个 map）扩容机制（transfer）：当某个桶的链表长度超过 TREEIFY_THRESHOLD（默认 8）且数组长度达到 MIN_TREEIFY_CAPACITY（64）时会树化；否则先扩容。扩容由多个线程协作完成： - 使用 transferIndex 记录待处理的区间。 - 每个线程从右往左领取任务块（避免冲突）。 - 创建两倍大小的新数组 nextTable。 - 将旧数组中的每个桶迁移至新数组。 - 迁移过程中原数组对应位置设置为 ForwardingNode（特殊节点，hash=-1），表示该桶已迁移或正在迁移。 - get 操作遇到 ForwardingNode 会去新数组查找。 size() 方法实现变化： - JDK 1.7：直接统计各 Segment 的 count 总和。 - JDK 1.8：引入一个长数组 counterCells，当并发更新 baseCount 失败时（CAS 失败），会将增量记录在 counterCells 中的不同槽位（类似 LongAdder）。 - 最终 size = baseCount + sum(counterCells) - 这种设计减少了 CAS 冲突，提高了并发更新效率。 get 方法为何不需要加锁？ - 因为 Node 的 val 和 next 都是 volatile 的，保证了可见性。 - 查找过程只是读操作，不会修改结构。 - 即使在扩容期间，get 也能正确地从旧表或新表中找到数据（ForwardingNode 引导跳转）。为什么使用 synchronized 而不是 ReentrantLock？ - JDK 1.8 对 synchronized 做了大量优化（偏向锁、轻量级锁、锁膨胀等），在低竞争下性能接近甚至优于 ReentrantLock。 - 减少内存开销（无需额外维护 Lock 对象）。 - 锁住的是具体的节点，粒度非常细。三、重要特性总结： - 线程安全：所有操作都线程安全。 - 不允许 null 键和 null 值：防止歧义（如 get 返回 null 时无法判断是没找到还是值为 null）。 - 迭代器弱一致性：不抛出 ConcurrentModificationException，但可能反映部分中间状态（允许边遍历边修改）。 - 高并发性能：读完全无锁，写操作仅锁定单个桶。四、常见面试问题延伸： Q: ConcurrentHashMap 和 Hashtable 的区别？ A: - Hashtable 使用全局 synchronized 方法，锁粒度大，并发性能差。 - ConcurrentHashMap 使用分段锁（1.7）或 CAS+synchronized（1.8），并发性能好。 - Hashtable 允许 null 键/值？不允许（但早期版本允许，后来修正）；CHM 明确禁止。 - CHM 提供更好的扩展性和现代并发编程支持。 Q: 为什么 ConcurrentHashMap 不允许 null 键？ A: 防止歧义。比如 get(key) 返回 null，如果是 null 键导致的就无法判断到底是 key 不存在还是 value 为 null。这在并发环境下尤其危险。 Q: 如何实现线程安全的计数？ A: 使用 counterCells 数组 + CAS 更新策略，类似于 LongAdder 和 Striped64 的思想，减少争用。 - 代码示例（简化版 put 操作逻辑，基于 JDK 1.8）： ``` 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; Node[] tab = table; for (Node[] t;;) { 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) { // 槽位为空，尝试 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) { K ek; 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) { // 红黑树 // ... tree insert logic } } } if (binCount != 0) { if (binCount >= TREEIFY_THRESHOLD) treeifyBin(tab, i); // 尝试树化 if (oldVal != null) return oldVal; break; } } tab = table; } addCount(1L, binCount); // 更新元素总数，可能触发扩容 return null; } ``` 辅助方法说明： - tabAt(tab, i): 使用 Unsafe.getVolatileObject 获取 volatile 引用 - casTabAt(tab, i, c, v): 使用 Unsafe.compareAndSwapObject 执行 CAS - helpTransfer: 协助扩容 - addCount: 更新计数并检查是否需要扩容 - 扩展知识点： 1. LongAdder vs AtomicLong：同属 JUC 工具类，解决高并发计数问题，思想一致。 2. ForkJoinPool 与 Work-Stealing：ConcurrentHashMap 扩容任务划分借鉴了类似的并行任务调度思想。 3. Unsafe 类的作用：直接操作内存、实现 CAS、volatile 读写等底层功能。 4. volatile 的内存语义：保证变量的可见性和禁止指令重排序。 5. CAS 的 ABA 问题及解决方案（AtomicStampedReference）——但在 ConcurrentHashMap 中影响较小，因为关注的是引用地址而非内容。综上所述，ConcurrentHashMap 是一个高度优化的并发容器，体现了现代 Java 并发编程的核心思想：细粒度锁、无锁编程（CAS）、惰性初始化、多线程协作扩容等。掌握其原理不仅有助于应对面试，也对理解高并发系统设计有重要意义。

途虎养车后端一面

全站热榜

创作者周榜