1. 项目概述为什么我们需要ConcurrentHashMap如果你写过Java并发程序并且用过HashMap那你大概率踩过这个坑在多个线程同时读写一个HashMap时程序莫名其妙地抛出了ConcurrentModificationException或者更糟直接死锁、数据错乱甚至程序崩溃。这背后的原因很简单标准的HashMap在设计之初就没考虑多线程并发访问的场景它的内部结构比如数组链表/红黑树在扩容rehash或者修改结构时如果多个线程同时操作很容易导致链表成环、数据丢失等不可预知的问题。这时候ConcurrentHashMap简称CHM就登场了。它不是简单地给整个HashMap加一把大锁像Hashtable或者Collections.synchronizedMap那样那种做法虽然线程安全但性能在高并发场景下会急剧下降因为所有操作哪怕是读操作都要排队。CHM的设计哲学是“锁细化”和“无锁化”它通过一种更精巧的方式在保证线程安全的前提下极大地提升了并发性能。可以说从Java 5引入java.util.concurrent包开始CHM就是处理高并发键值对映射的事实标准也是面试中绕不开的经典八股文。理解它不仅是应付面试更是写出高性能、高可靠Java并发程序的必备技能。2. 核心设计思想与演进历程要理解CHM不能只停留在API调用层面必须深入其设计思想的演变。它的进化史就是一部Java应对高并发挑战的微型编年史。2.1 从粗粒度锁到分段锁JDK 7在JDK 7及之前CHM的核心思想是分段锁Segment Locking。你可以把它想象成一个大型停车场。如果整个停车场只有一把钥匙全局锁那么同一时间只能有一辆车进出效率极低。分段锁的做法是把停车场划分成多个独立的区域Segment每个区域有自己的锁。车辆A进入1区车辆B可以同时进入2区互不干扰只有当他们要进入同一个区时才需要排队。在代码层面CHM内部维护了一个Segment数组。每个Segment本质上是一个小的HashMap继承自ReentrantLock。当进行put、remove等写操作时CHM会根据键Key的哈希值先定位到具体的Segment然后只对这个Segment加锁。这样不同Segment上的写操作就可以真正并行。读操作通常不需要加锁通过volatile变量保证可见性因此读写、写写在不同段上都可以并发进行。为什么这么设计在当时的硬件和多核编程认知下这是一种非常务实的折中。它假设写冲突不会特别频繁通过将数据分片将全局竞争分散到多个局部锁上显著降低了锁的粒度提升了并发度。但它的缺点也明显首先Segment的数量在构造时就固定了后期不能扩容这可能成为性能瓶颈其次当需要跨段操作比如size()时实现复杂且可能不精确最后数据结构本身相对复杂。2.2 迈向无锁化CAS与synchronizedJDK 8JDK 8对CHM进行了一次近乎重写式的革新放弃了分段锁采用了更细粒度的锁策略结合大量的无锁Lock-Free算法其核心变化包括数据结构变更摒弃了Segment直接采用Node数组链表红黑树的结构和HashMap类似。当链表长度超过阈值默认为8且数组容量达到一定值默认为64时链表会转换为红黑树以优化极端哈希冲突下的查询性能O(n) - O(log n)。锁粒度细化锁的粒度从Segment级别细化到了链表头节点或树根节点级别。也就是说锁只锁住哈希桶数组的一个位置的第一个节点。广泛使用CAS对于数组元素的初始化、节点的新增等操作大量使用sun.misc.Unsafe类提供的compareAndSwapCAS操作。CAS是一种乐观锁它假设冲突很少发生先进行计算在最后更新时判断值是否被其他线程改过没改过就更新改过了就重试。这避免了互斥锁的开销。使用synchronized替代ReentrantLockJDK 8的CHM在需要锁定桶时直接使用了synchronized关键字来锁住链表或树的头节点。这是因为经过JVM团队的深度优化在竞争不激烈的情况下synchronized的性能已经非常接近甚至优于ReentrantLock且能节省内存ReentrantLock是Java对象而synchronized是JVM内置的锁机制。为什么这么改硬件在进步多核CPU已成常态对并发的需求更高。分段锁的固定分区可能成为瓶颈而无锁算法和更细粒度的锁能更好地适应动态变化的工作负载。使用synchronized则是基于JVM性能优化的现实选择使得实现更简洁、内存占用更小。这个设计使得CHM在低并发和高并发场景下都有更好的表现并且API与HashMap更加一致。注意网上很多老旧资料和面试题还停留在JDK 7的分段锁时代。现在面试和实际开发中除非特别说明讨论的默认都是JDK 8及以后的实现。了解演进历史很重要但重点必须放在当前版本的设计上。3. 关键源码与工作机制深度解析光讲思想不够我们得看看代码是怎么实现的。这里我们聚焦JDK 8的实现拆解几个最核心的操作。3.1 内部存储结构Node, TreeNode, ForwardingNodeCHM的内部数组table存储的是Node节点。Node是一个简单的链表节点有hash,key,value,next属性。值得注意的是它的value和next字段都用volatile修饰这保证了线程间的可见性一个线程修改了某个节点的值或链表结构其他线程能立刻看到。static class NodeK,V implements Map.EntryK,V { final int hash; final K key; volatile V val; // volatile 保证可见性 volatile NodeK,V next; // volatile 保证可见性 // ... 省略构造方法和其它方法 }当链表转成红黑树时节点会替换为TreeNode它是Node的子类包含了红黑树所需的左右孩子、父节点等引用。还有一个非常关键的特殊节点ForwardingNode。它在扩容transfer时出现。当数组需要扩容时旧数组的某个桶位置会被放置一个ForwardingNode节点它的hash值为MOVED一个常量-1。这个节点不存储实际数据它像一个“路标”告诉其他线程“这个桶的数据已经迁移到新数组了请去新数组操作”。这是CHM实现并发扩容的关键。3.2 put操作如何保证线程安全地插入put(K key, V value)方法是CHM并发控制的精髓体现。它的流程可以高度概括为以下几步我们结合代码逻辑来看计算哈希对key的哈希值进行二次扰动让高位也参与运算减少哈希冲突。(h ^ (h 16)) HASH_BITS。初始化或定位表如果内部数组table还未初始化则通过CAS操作casTabAt进行初始化。这是一个典型的无锁化操作。定位桶位置根据哈希值计算数组下标i (n - 1) hash。处理空桶无锁CAS如果table[i]为null说明这个桶是空的。此时CHM会尝试用CAS操作将一个新节点直接放到这个位置。如果CAS成功插入结束这是最高效的情况完全无锁。处理哈希冲突加锁synchronized如果table[i]不为空说明发生了哈希冲突。首先检查头节点的hash值。如果hash MOVED说明数组正在扩容当前线程会加入帮助扩容的队伍helpTransfer。否则使用synchronized关键字锁住这个桶的头节点table[i]。在锁的保护下遍历链表或红黑树链表如果找到相同key的节点则更新value如果没找到则将新节点插入链表尾部。红黑树通过TreeNode的方法进行树的查找和插入。插入后判断是否需要将链表转换为红黑树。计数与扩容检查插入成功后会调用addCount方法增加元素总数。在这个方法里会检查当前元素数量是否超过容量阈值sizeCtl如果超过则触发扩容transfer。这里的精妙之处在于只有在发生哈希冲突需要操作同一个桶时才使用synchronized进行互斥。对于大量的空桶插入通过CAS实现无锁化并发性能极高。同时扩容操作也被设计成可以多线程协同完成进一步减少了停顿时间。3.3 get操作为什么可以完全不加锁get(Object key)操作是CHM高性能读的关键它完全不需要加锁。这主要得益于以下几个设计volatile变量保证可见性Node的val和next字段都是volatile的。根据Java内存模型JMM对一个volatile变量的写操作会对后续所有线程的读操作立即可见。这意味着一个线程put进去的值另一个线程get时一定能看到最新值。数组引用table本身是volatile的transient volatile NodeK,V[] table;。这保证了扩容后新数组能立即对所有线程可见。扩容时的安全读取即使在get过程中发生了扩容也能正确找到数据。因为扩容是逐个桶进行的。当线程读取到一个ForwardingNode时它会调用ForwardingNode的find方法转向新数组进行查找。而新旧数组在扩容完成前是共存的数据不会丢失。因此get操作就是一次普通的哈希查找遍历volatile的链表或树没有任何锁开销。这也是CHM在读多写少场景下性能卓越的原因。3.4 扩容机制如何实现高并发下的动态扩容扩容是CHM最复杂的部分之一目标是让扩容操作也能并发进行避免成为全局瓶颈。JDK 8的扩容流程大致如下触发时机在addCount方法中如果发现元素总数超过阈值sizeCtl某个线程会发起扩容。它首先将sizeCtl设置为一个负数标识扩容开始并计算出新数组的容量通常是旧数组的2倍。分配任务扩容不是由一个线程完成的。发起扩容的线程或后续协助的线程会根据CPU核心数和数组长度将旧数组划分成多个“步长”stride区间。每个线程负责迁移其中一个或多个区间内的桶。迁移桶数据线程迁移自己负责的桶。对于每个桶从后向前下标从大到小进行处理。迁移一个桶时会锁住该桶的头节点synchronized然后将链表或树中的节点根据哈希值重新散列到新数组的两个位置因为容量翻倍一个旧桶的数据会分散到新数组的两个桶中。迁移完成后在原桶位置放置一个ForwardingNode。协助迁移其他线程在执行put或remove操作时如果发现当前桶是ForwardingNode就不会阻塞等待而是会先帮助进行数据迁移helpTransfer迁移完自己需要操作的桶后再继续自己的插入或删除操作。这是一种“工作窃取”思想的变体充分利用了多线程的计算能力。完成与切换当所有桶都迁移完毕最后一个完成迁移的线程会将table引用指向新数组并更新sizeCtrl为新的扩容阈值。这个过程保证了扩容期间CHM仍然可以提供读写服务虽然性能会有所下降并且通过多线程协同大大缩短了扩容所需的总时间。4. 核心API使用、实战场景与性能调优理解了原理我们来看看怎么用好它以及在什么场景下该用它。4.1 关键API与使用示例CHM实现了ConcurrentMap接口常用方法和HashMap类似但有一些并发安全特有的方法。ConcurrentHashMapString, Integer map new ConcurrentHashMap(); // 1. 基础put/get map.put(apple, 1); Integer count map.get(apple); // 2. 原子性复合操作 - 这是CHM的精华 // computeIfAbsent: 如果key不存在则使用函数计算value并放入整个操作是原子的。 // 常用于“懒加载”或构建本地缓存。 map.computeIfAbsent(user:1001, key - fetchUserFromDB(key)); // computeIfPresent: 如果key存在则根据旧值和函数计算新值。 map.computeIfPresent(counter, (key, oldVal) - oldVal 1); // merge: 合并值如果key不存在直接放入给定值如果存在用函数合并旧值和新值。 map.merge(total, 1, Integer::sum); // 3. 遍历 // 使用forEach支持并行遍历但这里不是并行流 map.forEach((k, v) - System.out.println(k : v)); // 使用keySet、entrySet等视图这些视图的迭代器是“弱一致性”的 for (String key : map.keySet()) { // ... 迭代过程中其他线程的修改可能反映出来也可能不反映但不会抛ConcurrentModificationException } // 4. 并行流操作JDK 8 // 利用ForkJoinPool进行并行处理非常适合大数据量的CHM long sum map.values().parallelStream().mapToLong(Integer::longValue).sum();4.2 典型应用场景全局缓存这是CHM最经典的应用。例如在Web应用中缓存用户会话、配置信息、热点数据等。computeIfAbsent方法能完美解决“缓存穿透”问题多个线程同时查询一个不存在的key导致都去查数据库保证一个key只被计算一次。计数器实现一个高并发的计数器例如统计网站PV/UV、接口调用次数等。使用merge或compute方法可以轻松实现原子递增。替代Collections.synchronizedMap在任何需要线程安全Map且对性能有要求的地方都应优先考虑CHM。Hashtable和同步包装器已经过时。构建更复杂的数据结构作为基础组件用于实现线程安全的SetConcurrentHashMap.KeySetView、Cache如Guava Cache的底层实现之一等。4.3 大小size的统计与局限性CHM的size()方法返回的是一个估计值而不是精确值。因为在并发环境下要获取一个时刻的精确全局计数成本极高需要全局加锁。CHM采用了一种分计数的方法LongAdder思想的变体每个线程修改时先尝试更新一个基础计数baseCount如果竞争激烈则把计数累加到线程本地的计数器CounterCell中。size()方法会汇总baseCount和所有CounterCell的值。这个值在并发极高时可能略有误差但通常可以接受。如果需要精确计数可能需要额外的同步手段但这往往违背了使用CHM的初衷。4.4 性能调优与注意事项虽然CHM开箱即用性能就不错但在极端场景下了解一些调优点有助于榨干性能。初始容量与负载因子和HashMap一样可以在构造函数中指定初始容量initialCapacity和负载因子loadFactor。如果你能预估最终的元素数量设置一个合适的初始容量可以避免或减少扩容次数这对性能有积极影响。负载因子默认0.75通常不需要修改。并发级别JDK 7遗留下来的参数在JDK 8中构造函数里的concurrencyLevel参数仅仅是为了兼容旧版本它并不影响实际的并发度。JDK 8的并发度取决于桶的数量和竞争情况。这个参数在初始化时会影响内部大小但无需过分关注。键Key的设计确保键对象的hashCode()方法分布均匀。糟糕的哈希函数会导致大量数据堆积在少数几个桶里即使CHM的锁粒度很细也会退化成对这些热点桶的串行访问严重影响性能。String、Integer这类包装类作为Key通常是不错的选择。避免长时间持有锁的复合逻辑虽然computeIfAbsent等方法本身是原子的但你传入的函数Function执行时间不能太长。因为函数执行期间当前桶的锁是被持有的。如果这个函数执行了一个耗时的IO操作比如网络请求会阻塞其他所有需要访问这个桶的线程。正确的做法是让函数快速返回如果需要耗时操作考虑异步加载或使用专门的缓存库。迭代器的弱一致性CHM的迭代器keySet().iterator(),entrySet().iterator()是“弱一致性”的。它们反映的是迭代器创建时或之后某个时刻的映射状态但不会抛出ConcurrentModificationException。这意味着在迭代过程中你可能看到一些修改也可能看不到。如果你的逻辑依赖于迭代过程中集合不被修改那么需要在应用层进行同步。5. 常见面试题深度剖析与避坑指南作为Java并发面试的“钉子户”下面这些问题是高频考点理解背后的原理才能对答如流。5.1 JDK 7和JDK 8中ConcurrentHashMap的实现有什么区别这是必问题。回答要点数据结构JDK 7Segment数组 HashEntry链表。JDK 8Node数组 链表/红黑树。锁机制JDK 7分段锁ReentrantLock锁住整个Segment。JDK 8synchronized锁住单个桶的头节点结合大量CAS无锁操作。并发度JDK 7并发度由Segment数量决定构造时固定。JDK 8并发度理论上等于桶的数量更灵活。哈希冲突JDK 7只有链表。JDK 8链表长度超过阈值且数组容量足够时转换为红黑树。复杂度JDK 8的实现更简洁API与HashMap更统一。5.2 ConcurrentHashMap的get操作为什么不需要加锁核心三点Node节点的val和next属性用volatile修饰保证了线程间的可见性。数组引用table本身也是volatile的保证了扩容后新数组立即可见。扩容时通过ForwardingNode机制保证读操作在扩容期间也能正确找到数据要么在旧数组要么通过ForwardingNode导向新数组。5.3 ConcurrentHashMap是如何保证线程安全的这是一个综合问题要分点阐述写操作put/remove通过CAS无锁和synchronized有锁结合。空桶插入用CAS哈希冲突时锁住桶的头节点进行操作。读操作get完全无锁依赖volatile的内存语义保证可见性。扩容多线程协同扩容。通过ForwardingNode和sizeCtl等控制变量协调其他写操作线程会帮助迁移数据。计数采用分而治之的计数方式类似LongAdder避免对单一计数变量的激烈竞争。5.4 ConcurrentHashMap的size方法是线程安全的吗它返回的是精确值吗是线程安全的但返回的是近似值。它通过汇总一个基础计数baseCount和一组分散的计数单元CounterCell来得到结果。在高并发更新下这个汇总过程可能无法捕捉到所有刚刚完成的更新因此可能存在微小误差。这种设计是用精度换取性能的典型权衡。5.5 实际开发中的坑computeIfAbsent的递归调用这是一个非常隐蔽的坑。在JDK 8中computeIfAbsent的映射函数Function中如果尝试对当前正在计算的同一个ConcurrentHashMap再次调用computeIfAbsent并且key相同或存在哈希冲突导致锁竞争可能会造成死锁。ConcurrentHashMapString, String map new ConcurrentHashMap(); map.computeIfAbsent(keyA, k - { // 在计算keyA的值时又尝试计算keyA或另一个映射到同一个桶的keyB return map.computeIfAbsent(keyA, k2 - value); // 可能导致死锁 });在JDK 9中这个问题被修复了会直接抛出IllegalStateException。但在JDK 8中它可能导致线程永久阻塞。避坑指南永远不要在computeIfAbsent、computeIfPresent、compute、merge的函数体内对同一个CHM实例进行可能涉及相同桶的修改操作。5.6 如何选择ConcurrentHashMap的初始容量这是一个实践性问题。如果你能大致预估Map最终会存放多少元素那么设置初始容量可以避免扩容。公式可以参考初始容量 预估元素数量 / 负载因子 容错值。例如预估存放1000个元素负载因子0.75可以设置初始容量为1000 / 0.75 ≈ 1333取一个2的幂次方比如2048。这比使用默认容量16然后经历多次扩容要高效得多。当然如果无法预估使用默认值也是完全合理的。理解ConcurrentHashMap不仅仅是背会它的原理更是在高并发编程中建立一种“锁细化”和“无锁化”的思维模式。从Hashtable的全局锁到ConcurrentHashMap的分段锁再到桶节点锁与CAS的结合每一次演进都是为了在安全与性能之间找到更优的平衡点。在实际项目中当你需要一个线程安全的Map时ConcurrentHashMap几乎总是首选。但也要清醒认识到它的局限性比如size()的近似性、迭代器的弱一致性以及在特定场景下如compute函数耗时过长可能引发的性能问题。把这些原理、用法和坑都捋清楚了无论是应对面试还是解决实际的高并发难题你手里才算有了一张可靠的底牌。
Java高并发编程：ConcurrentHashMap核心原理与实战应用
发布时间：2026/7/29 16:01:55
1. 项目概述为什么我们需要ConcurrentHashMap如果你写过Java并发程序并且用过HashMap那你大概率踩过这个坑在多个线程同时读写一个HashMap时程序莫名其妙地抛出了ConcurrentModificationException或者更糟直接死锁、数据错乱甚至程序崩溃。这背后的原因很简单标准的HashMap在设计之初就没考虑多线程并发访问的场景它的内部结构比如数组链表/红黑树在扩容rehash或者修改结构时如果多个线程同时操作很容易导致链表成环、数据丢失等不可预知的问题。这时候ConcurrentHashMap简称CHM就登场了。它不是简单地给整个HashMap加一把大锁像Hashtable或者Collections.synchronizedMap那样那种做法虽然线程安全但性能在高并发场景下会急剧下降因为所有操作哪怕是读操作都要排队。CHM的设计哲学是“锁细化”和“无锁化”它通过一种更精巧的方式在保证线程安全的前提下极大地提升了并发性能。可以说从Java 5引入java.util.concurrent包开始CHM就是处理高并发键值对映射的事实标准也是面试中绕不开的经典八股文。理解它不仅是应付面试更是写出高性能、高可靠Java并发程序的必备技能。2. 核心设计思想与演进历程要理解CHM不能只停留在API调用层面必须深入其设计思想的演变。它的进化史就是一部Java应对高并发挑战的微型编年史。2.1 从粗粒度锁到分段锁JDK 7在JDK 7及之前CHM的核心思想是分段锁Segment Locking。你可以把它想象成一个大型停车场。如果整个停车场只有一把钥匙全局锁那么同一时间只能有一辆车进出效率极低。分段锁的做法是把停车场划分成多个独立的区域Segment每个区域有自己的锁。车辆A进入1区车辆B可以同时进入2区互不干扰只有当他们要进入同一个区时才需要排队。在代码层面CHM内部维护了一个Segment数组。每个Segment本质上是一个小的HashMap继承自ReentrantLock。当进行put、remove等写操作时CHM会根据键Key的哈希值先定位到具体的Segment然后只对这个Segment加锁。这样不同Segment上的写操作就可以真正并行。读操作通常不需要加锁通过volatile变量保证可见性因此读写、写写在不同段上都可以并发进行。为什么这么设计在当时的硬件和多核编程认知下这是一种非常务实的折中。它假设写冲突不会特别频繁通过将数据分片将全局竞争分散到多个局部锁上显著降低了锁的粒度提升了并发度。但它的缺点也明显首先Segment的数量在构造时就固定了后期不能扩容这可能成为性能瓶颈其次当需要跨段操作比如size()时实现复杂且可能不精确最后数据结构本身相对复杂。2.2 迈向无锁化CAS与synchronizedJDK 8JDK 8对CHM进行了一次近乎重写式的革新放弃了分段锁采用了更细粒度的锁策略结合大量的无锁Lock-Free算法其核心变化包括数据结构变更摒弃了Segment直接采用Node数组链表红黑树的结构和HashMap类似。当链表长度超过阈值默认为8且数组容量达到一定值默认为64时链表会转换为红黑树以优化极端哈希冲突下的查询性能O(n) - O(log n)。锁粒度细化锁的粒度从Segment级别细化到了链表头节点或树根节点级别。也就是说锁只锁住哈希桶数组的一个位置的第一个节点。广泛使用CAS对于数组元素的初始化、节点的新增等操作大量使用sun.misc.Unsafe类提供的compareAndSwapCAS操作。CAS是一种乐观锁它假设冲突很少发生先进行计算在最后更新时判断值是否被其他线程改过没改过就更新改过了就重试。这避免了互斥锁的开销。使用synchronized替代ReentrantLockJDK 8的CHM在需要锁定桶时直接使用了synchronized关键字来锁住链表或树的头节点。这是因为经过JVM团队的深度优化在竞争不激烈的情况下synchronized的性能已经非常接近甚至优于ReentrantLock且能节省内存ReentrantLock是Java对象而synchronized是JVM内置的锁机制。为什么这么改硬件在进步多核CPU已成常态对并发的需求更高。分段锁的固定分区可能成为瓶颈而无锁算法和更细粒度的锁能更好地适应动态变化的工作负载。使用synchronized则是基于JVM性能优化的现实选择使得实现更简洁、内存占用更小。这个设计使得CHM在低并发和高并发场景下都有更好的表现并且API与HashMap更加一致。注意网上很多老旧资料和面试题还停留在JDK 7的分段锁时代。现在面试和实际开发中除非特别说明讨论的默认都是JDK 8及以后的实现。了解演进历史很重要但重点必须放在当前版本的设计上。3. 关键源码与工作机制深度解析光讲思想不够我们得看看代码是怎么实现的。这里我们聚焦JDK 8的实现拆解几个最核心的操作。3.1 内部存储结构Node, TreeNode, ForwardingNodeCHM的内部数组table存储的是Node节点。Node是一个简单的链表节点有hash,key,value,next属性。值得注意的是它的value和next字段都用volatile修饰这保证了线程间的可见性一个线程修改了某个节点的值或链表结构其他线程能立刻看到。static class NodeK,V implements Map.EntryK,V { final int hash; final K key; volatile V val; // volatile 保证可见性 volatile NodeK,V next; // volatile 保证可见性 // ... 省略构造方法和其它方法 }当链表转成红黑树时节点会替换为TreeNode它是Node的子类包含了红黑树所需的左右孩子、父节点等引用。还有一个非常关键的特殊节点ForwardingNode。它在扩容transfer时出现。当数组需要扩容时旧数组的某个桶位置会被放置一个ForwardingNode节点它的hash值为MOVED一个常量-1。这个节点不存储实际数据它像一个“路标”告诉其他线程“这个桶的数据已经迁移到新数组了请去新数组操作”。这是CHM实现并发扩容的关键。3.2 put操作如何保证线程安全地插入put(K key, V value)方法是CHM并发控制的精髓体现。它的流程可以高度概括为以下几步我们结合代码逻辑来看计算哈希对key的哈希值进行二次扰动让高位也参与运算减少哈希冲突。(h ^ (h 16)) HASH_BITS。初始化或定位表如果内部数组table还未初始化则通过CAS操作casTabAt进行初始化。这是一个典型的无锁化操作。定位桶位置根据哈希值计算数组下标i (n - 1) hash。处理空桶无锁CAS如果table[i]为null说明这个桶是空的。此时CHM会尝试用CAS操作将一个新节点直接放到这个位置。如果CAS成功插入结束这是最高效的情况完全无锁。处理哈希冲突加锁synchronized如果table[i]不为空说明发生了哈希冲突。首先检查头节点的hash值。如果hash MOVED说明数组正在扩容当前线程会加入帮助扩容的队伍helpTransfer。否则使用synchronized关键字锁住这个桶的头节点table[i]。在锁的保护下遍历链表或红黑树链表如果找到相同key的节点则更新value如果没找到则将新节点插入链表尾部。红黑树通过TreeNode的方法进行树的查找和插入。插入后判断是否需要将链表转换为红黑树。计数与扩容检查插入成功后会调用addCount方法增加元素总数。在这个方法里会检查当前元素数量是否超过容量阈值sizeCtl如果超过则触发扩容transfer。这里的精妙之处在于只有在发生哈希冲突需要操作同一个桶时才使用synchronized进行互斥。对于大量的空桶插入通过CAS实现无锁化并发性能极高。同时扩容操作也被设计成可以多线程协同完成进一步减少了停顿时间。3.3 get操作为什么可以完全不加锁get(Object key)操作是CHM高性能读的关键它完全不需要加锁。这主要得益于以下几个设计volatile变量保证可见性Node的val和next字段都是volatile的。根据Java内存模型JMM对一个volatile变量的写操作会对后续所有线程的读操作立即可见。这意味着一个线程put进去的值另一个线程get时一定能看到最新值。数组引用table本身是volatile的transient volatile NodeK,V[] table;。这保证了扩容后新数组能立即对所有线程可见。扩容时的安全读取即使在get过程中发生了扩容也能正确找到数据。因为扩容是逐个桶进行的。当线程读取到一个ForwardingNode时它会调用ForwardingNode的find方法转向新数组进行查找。而新旧数组在扩容完成前是共存的数据不会丢失。因此get操作就是一次普通的哈希查找遍历volatile的链表或树没有任何锁开销。这也是CHM在读多写少场景下性能卓越的原因。3.4 扩容机制如何实现高并发下的动态扩容扩容是CHM最复杂的部分之一目标是让扩容操作也能并发进行避免成为全局瓶颈。JDK 8的扩容流程大致如下触发时机在addCount方法中如果发现元素总数超过阈值sizeCtl某个线程会发起扩容。它首先将sizeCtl设置为一个负数标识扩容开始并计算出新数组的容量通常是旧数组的2倍。分配任务扩容不是由一个线程完成的。发起扩容的线程或后续协助的线程会根据CPU核心数和数组长度将旧数组划分成多个“步长”stride区间。每个线程负责迁移其中一个或多个区间内的桶。迁移桶数据线程迁移自己负责的桶。对于每个桶从后向前下标从大到小进行处理。迁移一个桶时会锁住该桶的头节点synchronized然后将链表或树中的节点根据哈希值重新散列到新数组的两个位置因为容量翻倍一个旧桶的数据会分散到新数组的两个桶中。迁移完成后在原桶位置放置一个ForwardingNode。协助迁移其他线程在执行put或remove操作时如果发现当前桶是ForwardingNode就不会阻塞等待而是会先帮助进行数据迁移helpTransfer迁移完自己需要操作的桶后再继续自己的插入或删除操作。这是一种“工作窃取”思想的变体充分利用了多线程的计算能力。完成与切换当所有桶都迁移完毕最后一个完成迁移的线程会将table引用指向新数组并更新sizeCtrl为新的扩容阈值。这个过程保证了扩容期间CHM仍然可以提供读写服务虽然性能会有所下降并且通过多线程协同大大缩短了扩容所需的总时间。4. 核心API使用、实战场景与性能调优理解了原理我们来看看怎么用好它以及在什么场景下该用它。4.1 关键API与使用示例CHM实现了ConcurrentMap接口常用方法和HashMap类似但有一些并发安全特有的方法。ConcurrentHashMapString, Integer map new ConcurrentHashMap(); // 1. 基础put/get map.put(apple, 1); Integer count map.get(apple); // 2. 原子性复合操作 - 这是CHM的精华 // computeIfAbsent: 如果key不存在则使用函数计算value并放入整个操作是原子的。 // 常用于“懒加载”或构建本地缓存。 map.computeIfAbsent(user:1001, key - fetchUserFromDB(key)); // computeIfPresent: 如果key存在则根据旧值和函数计算新值。 map.computeIfPresent(counter, (key, oldVal) - oldVal 1); // merge: 合并值如果key不存在直接放入给定值如果存在用函数合并旧值和新值。 map.merge(total, 1, Integer::sum); // 3. 遍历 // 使用forEach支持并行遍历但这里不是并行流 map.forEach((k, v) - System.out.println(k : v)); // 使用keySet、entrySet等视图这些视图的迭代器是“弱一致性”的 for (String key : map.keySet()) { // ... 迭代过程中其他线程的修改可能反映出来也可能不反映但不会抛ConcurrentModificationException } // 4. 并行流操作JDK 8 // 利用ForkJoinPool进行并行处理非常适合大数据量的CHM long sum map.values().parallelStream().mapToLong(Integer::longValue).sum();4.2 典型应用场景全局缓存这是CHM最经典的应用。例如在Web应用中缓存用户会话、配置信息、热点数据等。computeIfAbsent方法能完美解决“缓存穿透”问题多个线程同时查询一个不存在的key导致都去查数据库保证一个key只被计算一次。计数器实现一个高并发的计数器例如统计网站PV/UV、接口调用次数等。使用merge或compute方法可以轻松实现原子递增。替代Collections.synchronizedMap在任何需要线程安全Map且对性能有要求的地方都应优先考虑CHM。Hashtable和同步包装器已经过时。构建更复杂的数据结构作为基础组件用于实现线程安全的SetConcurrentHashMap.KeySetView、Cache如Guava Cache的底层实现之一等。4.3 大小size的统计与局限性CHM的size()方法返回的是一个估计值而不是精确值。因为在并发环境下要获取一个时刻的精确全局计数成本极高需要全局加锁。CHM采用了一种分计数的方法LongAdder思想的变体每个线程修改时先尝试更新一个基础计数baseCount如果竞争激烈则把计数累加到线程本地的计数器CounterCell中。size()方法会汇总baseCount和所有CounterCell的值。这个值在并发极高时可能略有误差但通常可以接受。如果需要精确计数可能需要额外的同步手段但这往往违背了使用CHM的初衷。4.4 性能调优与注意事项虽然CHM开箱即用性能就不错但在极端场景下了解一些调优点有助于榨干性能。初始容量与负载因子和HashMap一样可以在构造函数中指定初始容量initialCapacity和负载因子loadFactor。如果你能预估最终的元素数量设置一个合适的初始容量可以避免或减少扩容次数这对性能有积极影响。负载因子默认0.75通常不需要修改。并发级别JDK 7遗留下来的参数在JDK 8中构造函数里的concurrencyLevel参数仅仅是为了兼容旧版本它并不影响实际的并发度。JDK 8的并发度取决于桶的数量和竞争情况。这个参数在初始化时会影响内部大小但无需过分关注。键Key的设计确保键对象的hashCode()方法分布均匀。糟糕的哈希函数会导致大量数据堆积在少数几个桶里即使CHM的锁粒度很细也会退化成对这些热点桶的串行访问严重影响性能。String、Integer这类包装类作为Key通常是不错的选择。避免长时间持有锁的复合逻辑虽然computeIfAbsent等方法本身是原子的但你传入的函数Function执行时间不能太长。因为函数执行期间当前桶的锁是被持有的。如果这个函数执行了一个耗时的IO操作比如网络请求会阻塞其他所有需要访问这个桶的线程。正确的做法是让函数快速返回如果需要耗时操作考虑异步加载或使用专门的缓存库。迭代器的弱一致性CHM的迭代器keySet().iterator(),entrySet().iterator()是“弱一致性”的。它们反映的是迭代器创建时或之后某个时刻的映射状态但不会抛出ConcurrentModificationException。这意味着在迭代过程中你可能看到一些修改也可能看不到。如果你的逻辑依赖于迭代过程中集合不被修改那么需要在应用层进行同步。5. 常见面试题深度剖析与避坑指南作为Java并发面试的“钉子户”下面这些问题是高频考点理解背后的原理才能对答如流。5.1 JDK 7和JDK 8中ConcurrentHashMap的实现有什么区别这是必问题。回答要点数据结构JDK 7Segment数组 HashEntry链表。JDK 8Node数组 链表/红黑树。锁机制JDK 7分段锁ReentrantLock锁住整个Segment。JDK 8synchronized锁住单个桶的头节点结合大量CAS无锁操作。并发度JDK 7并发度由Segment数量决定构造时固定。JDK 8并发度理论上等于桶的数量更灵活。哈希冲突JDK 7只有链表。JDK 8链表长度超过阈值且数组容量足够时转换为红黑树。复杂度JDK 8的实现更简洁API与HashMap更统一。5.2 ConcurrentHashMap的get操作为什么不需要加锁核心三点Node节点的val和next属性用volatile修饰保证了线程间的可见性。数组引用table本身也是volatile的保证了扩容后新数组立即可见。扩容时通过ForwardingNode机制保证读操作在扩容期间也能正确找到数据要么在旧数组要么通过ForwardingNode导向新数组。5.3 ConcurrentHashMap是如何保证线程安全的这是一个综合问题要分点阐述写操作put/remove通过CAS无锁和synchronized有锁结合。空桶插入用CAS哈希冲突时锁住桶的头节点进行操作。读操作get完全无锁依赖volatile的内存语义保证可见性。扩容多线程协同扩容。通过ForwardingNode和sizeCtl等控制变量协调其他写操作线程会帮助迁移数据。计数采用分而治之的计数方式类似LongAdder避免对单一计数变量的激烈竞争。5.4 ConcurrentHashMap的size方法是线程安全的吗它返回的是精确值吗是线程安全的但返回的是近似值。它通过汇总一个基础计数baseCount和一组分散的计数单元CounterCell来得到结果。在高并发更新下这个汇总过程可能无法捕捉到所有刚刚完成的更新因此可能存在微小误差。这种设计是用精度换取性能的典型权衡。5.5 实际开发中的坑computeIfAbsent的递归调用这是一个非常隐蔽的坑。在JDK 8中computeIfAbsent的映射函数Function中如果尝试对当前正在计算的同一个ConcurrentHashMap再次调用computeIfAbsent并且key相同或存在哈希冲突导致锁竞争可能会造成死锁。ConcurrentHashMapString, String map new ConcurrentHashMap(); map.computeIfAbsent(keyA, k - { // 在计算keyA的值时又尝试计算keyA或另一个映射到同一个桶的keyB return map.computeIfAbsent(keyA, k2 - value); // 可能导致死锁 });在JDK 9中这个问题被修复了会直接抛出IllegalStateException。但在JDK 8中它可能导致线程永久阻塞。避坑指南永远不要在computeIfAbsent、computeIfPresent、compute、merge的函数体内对同一个CHM实例进行可能涉及相同桶的修改操作。5.6 如何选择ConcurrentHashMap的初始容量这是一个实践性问题。如果你能大致预估Map最终会存放多少元素那么设置初始容量可以避免扩容。公式可以参考初始容量 预估元素数量 / 负载因子 容错值。例如预估存放1000个元素负载因子0.75可以设置初始容量为1000 / 0.75 ≈ 1333取一个2的幂次方比如2048。这比使用默认容量16然后经历多次扩容要高效得多。当然如果无法预估使用默认值也是完全合理的。理解ConcurrentHashMap不仅仅是背会它的原理更是在高并发编程中建立一种“锁细化”和“无锁化”的思维模式。从Hashtable的全局锁到ConcurrentHashMap的分段锁再到桶节点锁与CAS的结合每一次演进都是为了在安全与性能之间找到更优的平衡点。在实际项目中当你需要一个线程安全的Map时ConcurrentHashMap几乎总是首选。但也要清醒认识到它的局限性比如size()的近似性、迭代器的弱一致性以及在特定场景下如compute函数耗时过长可能引发的性能问题。把这些原理、用法和坑都捋清楚了无论是应对面试还是解决实际的高并发难题你手里才算有了一张可靠的底牌。
（支持资料、图片参考_相关定制）_)
