前言在Java的大厂面试中集合框架是高并发基础中的重要考察点。而 ConcurrentHashMap 作为线程安全的HashMap是应对并发场景的利器。面试官通常会从版本区别、线程安全实现、扩容机制、并发度等角度层层递进地提问。本文将围绕最常见的15道 ConcurrentHashMap 面试题结合JDK 1.7和1.8的底层原理进行深度剖析帮你构建从应用到源码的完整知识体系。第一部分基础概念篇1. ConcurrentHashMap 和 HashMap 的区别是什么核心考点考察对线程安全基础的理解。答案详解线程安全性HashMap是线程不安全的。在并发环境下进行put操作可能会导致环形链表JDK 1.7头插法导致从而在get时发生死循环CPU飙升到100%。JDK 1.8虽然解决了死循环问题但仍会导致数据覆盖、数据不一致等问题。ConcurrentHashMap是线程安全的。它通过精细化的锁机制分段锁或CASsynchronized保证多线程下的原子性。Null值策略HashMap允许key和value为null。ConcurrentHashMap不允许key或value为null。这是因为在并发环境下无法通过get(key)返回null来准确判断是key不存在还是value为null这种二义性在多线程环境下难以通过加锁来解决为了避免歧义直接禁止。数据结构HashMapJDK 1.8后采用数组链表红黑树。ConcurrentHashMapJDK 1.7采用Segment数组HashEntry链表JDK 1.8采用Node数组链表红黑树结构与HashMap类似。2. ConcurrentHashMap 和 Hashtable 的区别是什么核心考点考察并发容器的发展历史为什么淘汰Hashtable。答案详解锁粒度核心性能差异Hashtable使用全局锁。每个方法如put、get都是用synchronized修饰相当于给整个哈希表加了一把大锁。同一时刻只有一个线程能读写并发效率极低竞争激烈时线程会进入阻塞或轮询状态。ConcurrentHashMap使用细粒度锁。JDK 1.7采用分段锁JDK 1.8采用桶锁锁链表或树的首节点多个线程操作不同数据段/桶时可以并发执行。数据结构与演进Hashtable数组链表没有红黑树优化查询效率随着链表变长而下降。ConcurrentHashMapJDK 1.8引入红黑树当链表长度超过阈值8且数组长度64时链表转为红黑树优化了高冲突场景下的查询性能。扩容机制Hashtable扩容时由单线程完成且扩容期间无法对外服务。ConcurrentHashMapJDK 1.8支持多线程并发扩容将旧数组的数据迁移任务分配给多个线程共同完成大大缩短了扩容的停顿时间STW。第二部分版本演进与实现原理篇3. 请分别介绍 JDK 1.7 和 JDK 1.8 中 ConcurrentHashMap 的底层数据结构。核心考点考察对源码结构的记忆。答案详解JDK 1.7 版本结构Segment数组 HashEntry数组 链表。Segment继承自ReentrantLock扮演了锁Lock的角色。每个Segment就是一个小的哈希表它里面包含一个HashEntry数组。ConcurrentHashMap 将数据分成多个 Segment 存储默认是16个。HashEntry用于存储键值对数据。当发生哈希冲突时以链表的形式存储。JDK 1.8 版本结构Node数组 链表 红黑树。Node与 HashMap 中的 Node 类似用于存储键值对。TreeNode当链表转为红黑树时Node 会被包装为 TreeNode。去除了 Segment 分段锁的概念锁的粒度由“分段”细化为“桶”。虽然代码里还有 Segment但仅用于序列化兼容不再用于锁控制。4. 为什么 JDK 1.8 要放弃分段锁改用 synchronized CAS核心考点考察对锁优化和性能的理解。答案详解锁粒度更细JDK 1.7 的分段锁虽然比 Hashtable 的全局锁细但如果多个线程同时操作同一个 Segment 内的不同桶依然会产生锁竞争。JDK 1.8 的锁粒度是每个桶的头节点只要线程操作的键不落在同一个桶里哈希冲突就不会产生锁竞争。内存占用更小JDK 1.7 的 Segment 结构本身是冗余的维护 Segment 数组需要额外内存。JDK 1.8 直接使用 Node 数组结构更简洁。JVM 锁优化JDK 1.6 以后对synchronized做了大量优化如锁升级偏向锁-轻量级锁-重量级锁。synchronized不再像以前那样“重”它能够根据竞争情况动态地选择锁机制。而ReentrantLock需要手动管理锁的释放相比之下synchronized在 JVM 层面的优化空间更大且使用更简单自动释放。结合 CAS 提高无竞争场景性能在桶为空时直接使用 CAS 插入节点无需加锁只有在发生哈希冲突时才加锁这种锁降级策略大大提高了并发性能。5. 描述 JDK 1.8 中 ConcurrentHashMap 的 put 方法执行流程。核心考点考察核心逻辑的清晰度。答案详解put方法的执行是一个自旋死循环加 CAS 的过程主要步骤如下参数校验如果 key 或 value 为 null直接抛出NullPointerException。计算hash调用spread()方法计算 key 的 hash 值确保散列均匀。初始化数组进入一个死循环 (for (NodeK,V[] tab table;;))。判断table是否为空或长度为0如果是则调用initTable()进行初始化initTable()通过 CAS 将sizeCtl设为 -1 来获得初始化权限防止并发初始化。定位空桶无锁插入根据 hash 值找到对应的桶位置i。如果该桶为空null则通过CAS 操作(casTabAt) 尝试将新节点放入该位置。如果 CAS 成功则跳出循环如果失败说明有其他线程抢先插入则进入下一轮循环重试。帮助扩容如果检测到该桶的 hash 值为MOVED即该节点是ForwardingNode说明当前 ConcurrentHashMap 正在进行扩容。此时当前线程不会等待而是调用helpTransfer()方法加入扩容的队伍协助迁移数据。哈希冲突加锁插入如果桶不为空且不是扩容状态则使用synchronized关键字锁住该桶的头节点f。确认锁住的头节点未被修改。遍历链表或红黑树如果找到 key 相同的节点则根据onlyIfAbsent参数决定是否覆盖旧值。如果没找到在链表尾部插入新节点尾插法。插入后检查链表长度是否超过TREEIFY_THRESHOLD(8)若超过且数组长度64则调用treeifyBin()将链表转为红黑树。计数与扩容插入完成后释放锁。调用addCount(1L, binCount)方法增加元素个数计数器。addCount内部会检查当前 size 是否超过阈值sizeCtl如果超过则触发transfer()方法进行扩容。6. ConcurrentHashMap 的 get 方法需要加锁吗它是如何保证可见性的核心考点考察对 volatile 和内存语义的理解。答案详解不需要加锁。get方法是无锁的通过volatile的语义来保证数据的可见性。保证可见性的三个关键点volatile修饰的数组引用table数组被volatile修饰。虽然volatile对数组的修饰只针对数组的引用地址本身不针对数组元素但这保证了当数组地址发生改变时如扩容后新数组的引用所有线程能立即看到最新的数组。volatile修饰的 Node 属性Node节点中的val和next属性都是volatile修饰的。这保证了当线程 A 修改了某个节点的 value或者修改了链表的next结构线程 B 在get时能立即看到这些修改即从主内存中读取。Unsafe类的getObjectVolatile在源码中获取数组元素桶的头节点时并没有直接使用tab[index]这种普通的数组访问方式而是通过U.getObjectVolatile(tab, ((long)i ASHIFT) ABASE)。这是因为普通的数组访问无法利用volatile的语义而Unsafe的getObjectVolatile方法能保证对该数组元素的读取具有volatile的可见性直接读取主内存中的最新值。get 流程简述计算 hash 值。根据 hash 值找到数组中的桶位置。如果桶首节点就是要找的 key直接返回其 value。如果首节点的 hash 0即红黑树或正在扩容则调用对应的find()方法查找。否则遍历链表查找。返回结果如果没找到返回null。第三部分核心机制与源码细节篇7. 解释一下 ConcurrentHashMap 的扩容机制transfer方法。它是如何实现多线程协同扩容的核心考点考察对并发协作深度的理解。答案详解当数组长度达到阈值sizeCtl时会触发扩容。扩容的核心是transfer()方法其设计目标是多线程并发迁移数据以减少扩容对业务线程的阻塞。关键设计点步长分配新数组创建后原数组会被分成多个任务区间步长 stride。默认每个线程负责迁移 16 个桶MIN_TRANSFER_STRIDE。有一个全局的transferIndex指针用于指向下一个需要迁移的桶区间。多线程通过CAS竞争修改transferIndex来领取各自的任务。例如初始transferIndex指向最后一个桶线程 A 通过 CAS 将其修改为最后一个桶 - 步长表示它领取了这一段区间。ForwardingNode当某个桶迁移完成后会在旧数组的该桶位置放置一个ForwardingNodehash值为MOVED。这是一个标记节点它的作用是表示该桶已完成迁移。持有新数组的引用。当其他线程即使是写线程或读线程访问到该桶时会通过ForwardingNode的find方法转而到新数组中去继续操作实现了读写操作的平滑过渡。数据迁移在迁移一个桶时线程会锁住该桶的头节点synchronized。对于链表它会将链表拆分成高位链和低位链然后直接放到新数组的对应位置这是借鉴了 HashMap 1.8 的扩容优化避免重新计算 hash。协助扩容前面提到的当put操作发现桶上存在ForwardingNode即hash MOVED时当前线程不会阻塞等待而是调用helpTransfer()方法加入扩容大军贡献自己的一份力。扩容结束的标志是最后一个线程完成迁移并且新数组替换旧数组。8. ConcurrentHashMap 的 size() 方法是怎样统计大小的它准确吗核心考点考察对高并发计数器的理解。答案详解size()方法返回的是一个近似值并不保证100%的实时精确性。这是因为在并发环境下为了得到一个精确值而锁住整个 Map 是不现实的。计数机制采用了baseCountCounterCell[]的机制。基本计数baseCount在没有竞争的情况下直接通过 CAS 更新baseCount。计数单元CounterCell当 CAS 更新baseCount失败时说明有竞争系统就会启用一个CounterCell数组。后续的计数操作会通过随机线程哈希的方式选取数组中的一个CounterCell进行 CAS 累加。这实际上是一种分段计数的思想将计数的热点分散到多个 Cell 中极大地减少了并发冲突。统计过程在 JDK 1.8 中size()方法的计算逻辑是先尝试对baseCount和所有CounterCell数组的值进行累加同时检查过程中是否有数据被修改通过modCount。如果累加过程中发现数据发生变化则会采用悲观策略通过加锁来重新统计。但在高并发下返回的数据依然是弱一致性的。*注意在 JDK 11 中size()已被mappingCount()替代因为size()的 int 返回值可能溢出。*9. ConcurrentHashMap 的迭代器是强一致性的还是弱一致性的为什么核心考点考察对并发迭代的理解。答案详解ConcurrentHashMap 的迭代器是弱一致性的。特征不抛异常在迭代器遍历的过程中如果其他线程修改了 Map增删改迭代器不会抛出ConcurrentModificationException异常。不保证实时更新迭代器遍历的是迭代器创建那一刻或遍历过程中某个时刻的数据快照。它可能会反映出修改也可能不会。例如当你遍历完一个桶后另一个线程在该桶尾部插入了一个新节点那么这个新节点可能不会被本次迭代器遍历到。反之如果在遍历某个桶之前其他线程删除了桶中的一个节点且该节点尚未被遍历到那么遍历时可能就找不到了。原因这种弱一致性是为了在高并发下获取更高的吞吐量和性能。为了实现强一致性就必须在迭代时锁住整个 Map 或者数据段这会导致性能大幅下降。ConcurrentHashMap 的设计哲学就是在保证线程安全的前提下尽可能提升并发性能因此选择了弱一致性。第四部分进阶与对比篇10. 为什么 ConcurrentHashMap 的链表转红黑树的阈值是 8而红黑树转链表的阈值是 6核心考点考察对时间和空间复杂度平衡的理解以及对统计学原理的了解。答案详解空间和时间权衡红黑树虽然查找效率高O(log n)但每个节点需要存储左子节点、右子节点、颜色等额外信息占用空间比链表节点只存 next 指针大得多。链表查找效率低O(n)但节点结构简单占用空间小。泊松分布Poisson Distribution源码注释中提到在理想随机哈希码的情况下桶中节点个数的概率服从泊松分布。当负载因子为0.75时桶中节点数出现8个的概率已经非常小了小于千万分之一。因此设置阈值为8意味着只有在极端哈希冲突的情况下通常是哈希算法被恶意构造或严重退化才会将链表转为红黑树。这既保证了正常情况下使用轻量级的链表以节省内存又能在极端情况下保证查询性能。缓冲机制为什么是6和8如果链表长度降到7就转回链表那么在 7、8 之间频繁插入和删除元素会导致树和链表之间不停地来回转换产生大量的开销。设置6作为转回链表的阈值是为了预留一个缓冲区间。即链表长度需要从 8 降到 6 才会转回这样可以避免在边界值附近频繁触发结构转换保持相对的稳定。11. 为什么 ConcurrentHashMap 在 1.8 中要使用内置锁 synchronized 而不是显式锁 ReentrantLock核心考点考察对 JVM 锁优化和新特性的理解。答案详解锁的粒度降低在 1.8 中锁只加在桶的头节点上锁的持有时间极短。在如此细粒度的场景下synchronized和ReentrantLock的性能已经相差无几。JVM 原生支持与优化synchronized是 JVM 内置的关键字它随着 JDK 版本的迭代不断得到优化如偏向锁、轻量级锁、锁粗化、锁消除。这些优化是在 JVM 层面实现的对开发者透明。ReentrantLock是 API 层面的锁需要开发者手动加锁和释放虽然灵活但缺少 JVM 内置的自动优化空间。代码简洁性使用synchronized可以使代码更简洁不需要像ReentrantLock那样在finally块中手动释放锁降低了代码编写出错的可能性。12. 在多线程环境下如何安全地使用 ConcurrentHashMap 的复合操作如“若不存在则添加”核心考点考察是否知道单个操作安全不等于组合操作安全。答案详解虽然 ConcurrentHashMap 的put、get、remove等单个操作都是原子的但多个操作的组合如先get判断再put添加并不保证原子性可能会被其他线程打断。错误示例javaif (!map.containsKey(key)) { // 线程A执行完这里被挂起 map.put(key, value); // 线程B此时可能已经put进去了导致线程A覆盖数据 }正确的解决方案使用原子复合方法ConcurrentHashMap 本身提供了丰富的原子性复合方法应优先使用。putIfAbsent(key, value)如果 key 不存在才插入。等价于上述操作的原子版本。computeIfAbsent(key, mappingFunction)如果 key 不存在则通过mappingFunction计算 value 并插入。该函数内部是原子性加锁的能保证计算过程只被执行一次常用于构建高效缓存。compute(key, remappingFunction)对指定 key 进行任意值的计算和更新。merge(key, value, remappingFunction)用于合并操作。手动加锁如果不使用上述方法或者复合操作涉及多个键也可以对某个固定的锁对象进行加锁但这样就失去了 ConcurrentHashMap 的并发意义不推荐。13. ConcurrentHashMap 中的UNSAFE类CAS主要应用在哪些地方核心考点考察对底层实现工具的认知。答案详解Unsafe类提供了硬件级别的原子操作CAS在 ConcurrentHashMap 中大量用于实现无锁并发主要应用场景包括初始化数组 (initTable)通过 CAS 修改sizeCtl变量确保只有一个线程能进行数组的初始化工作。java// 如果 sizeCtl 小于 0说明有线程在初始化当前线程让出CPU if (U.compareAndSwapInt(this, SIZECTL, sc, -1)) { // 获得初始化权限 }向空桶插入节点 (casTabAt)当定位到的桶为 null 时通过U.compareAndSwapObject将新节点设置到该桶位置这是最典型的无锁编程。统计数量 (addCount)通过 CAS 更新baseCount和CounterCell数组中的值避免加锁。获取数组元素 (tabAt)通过U.getObjectVolatile保证获取到的头节点是最新值volatile 语义。推进扩容索引多线程竞争领取迁移任务时通过 CAS 修改transferIndex。第五部分总结与深度追问篇14. 如果让你来设计一个高并发的 HashMap你会考虑哪些方面核心考点考察系统设计能力和知识迁移能力。答案详解锁策略首先必须采用细粒度锁绝不能使用全局锁。借鉴 1.8 的桶锁思想锁头节点。采用读写分离思想或乐观锁读多写少的场景读操作完全无锁通过 volatile 保证可见性写操作在无竞争时用 CAS有竞争时锁住桶。数据结构底层采用数组链表红黑树的变体以应对 Hash 攻击。链表节点要足够轻量。并发扩容必须支持多线程扩容不能让扩容成为单点瓶颈。扩容时不能阻塞读操作使用 ForwardingNode 转发。计数设计使用分段计数器类似LongAdder避免一个计数器被所有线程争抢。安全性禁止 null 键值消除二义性。提供原子性的复合操作方法如computeIfAbsent。15. 你遇到过 ConcurrentHashMap 相关的线上问题吗核心考点考察实际排查问题的能力。答案详解虽然 ConcurrentHashMap 是线程安全的但错误的使用依然会导致问题滥用computeIfAbsent导致死循环或 CPU 飙升现象在 JDK 1.8 的某些版本如 1.8.0_191 之前computeIfAbsent的mappingFunction中如果又调用了外层 Map 的其它方法可能会导致死循环因为该方法内部加锁且递归调用同一个锁。解决方案避免在mappingFunction中对当前 Map 做复杂的、可能触发递归的操作。对象引用变更导致的内存泄漏现象将 ConcurrentHashMap 作为缓存使用但 key 是一个自定义对象且该对象没有正确重写equals和hashCode或者 key 对象的外部属性被修改导致无法准确找到 value随着时间的推移Map 越来越大最终 OOM。解决方案使用不可变对象作为 key或者严格控制 key 的生命周期。误以为size()精确而导致的统计错误现象需要精确统计在线人数但使用map.size()在高并发下结果不准。解决方案如果追求极致精确需配合外部锁或改用数据库原子计数器。