ConcurrentHashMap是Java中线程安全且高性能的哈希表实现，适用于多线程环境下高效操作键值对。它通过CAS操作和synchronized锁节点实现高并发读写，避免了HashTable的全局锁性能瓶颈。与HashMap相比，它支持并发修改而不抛出异常；与HashTable相比，其分段锁或节点级锁机制显著提升并发性能。在Java 8中，底层采用Node数组+链表/红黑树结构，put操作先CAS插入再必要时加锁，get操作无锁但保证可见性。推荐在多线程共享数据场景使用，如缓存、计数器等。注意其不允许null键或值，迭代器为弱一致性，复合操作应使用compute、merge等原子方法以避免竞态条件。合理设置初始容量可减少扩容开销，同时需关注键的hashCode均匀性及内存占用问题。
ConcurrentHashMap是Java并发编程中不可或缺的利器，它提供了一种线程安全且高性能的哈希表实现。简单来说，当你需要在多线程环境下安全、高效地操作一个键值对集合时，ConcurrentHashMap往往是你的首选，因为它在保证数据一致性的同时，最大程度地提升了并发性能，避免了传统HashTable或Collections.synchronizedMap()带来的性能瓶颈。
解决方案
使用ConcurrentHashMap非常直接，它提供了与HashMap类似的API，但在内部处理了所有的并发细节。
首先，你需要创建一个ConcurrentHashMap实例。通常，我们不需要指定初始容量，但在处理大量数据时，预估一个合理的初始容量（或使用
new ConcurrentHashMap<>(initialCapacity)）可以减少扩容的开销。
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
public class ConcurrentHashMapDemo {
public static void main(String[] args) throws InterruptedException {
ConcurrentHashMap<String, Integer> userScores = new ConcurrentHashMap<>();
// 基本的put操作
userScores.put("Alice", 100);
userScores.put("Bob", 95);
System.out.println("初始分数: " + userScores); // 输出: 初始分数: {Alice=100, Bob=95}
// 基本的get操作
Integer aliceScore = userScores.get("Alice");
System.out.println("Alice的分数: " + aliceScore); // 输出: Alice的分数: 100
// 基本的remove操作
userScores.remove("Bob");
System.out.println("移除Bob后: " + userScores); // 输出: 移除Bob后: {Alice=100}
// putIfAbsent: 如果key不存在，则放入；如果存在，则不操作并返回旧值
userScores.putIfAbsent("Alice", 110); // Alice已存在，不会更新
userScores.putIfAbsent("Charlie", 88); // Charlie不存在，会放入
System.out.println("使用putIfAbsent后: " + userScores); // 输出: 使用putIfAbsent后: {Alice=100, Charlie=88}
// compute: 原子地计算并更新一个值
// 假设我们要给Alice的分数加10
userScores.compute("Alice", (key, oldValue) -> oldValue == null ? 0 : oldValue + 10);
System.out.println("Alice分数更新后: " + userScores.get("Alice")); // 输出: Alice分数更新后: 110
// merge: 如果key存在，则使用remappingFunction合并旧值和新值；如果key不存在，则放入新值
userScores.merge("Alice", 5, (oldValue, newValue) -> oldValue + newValue); // 110 + 5 = 115
userScores.merge("David", 70, (oldValue, newValue) -> oldValue + newValue); // David不存在，直接放入70
System.out.println("使用merge后: " + userScores); // 输出: 使用merge后: {Alice=115, Charlie=88, David=70}
// 遍历ConcurrentHashMap
// 注意：迭代器是弱一致性的，它反映的是在迭代器创建时或创建后某个时刻的映射状态，不保证实时性。
// 但它不会抛出ConcurrentModificationException。
System.out.println("遍历ConcurrentHashMap:");
userScores.forEach((user, score) -> System.out.println(user + ": " + score));
// 模拟多线程并发操作
ExecutorService executor = Executors.newFixedThreadPool(5);
for (int i = 0; i < 100; i++) {
final String user = "User" + (i % 10); // 10个用户
executor.submit(() -> {
userScores.compute(user, (k, v) -> v == null ? 1 : v + 1);
});
}
executor.shutdown();
executor.awaitTermination(1, TimeUnit.MINUTES);
System.out.println("并发更新后: " + userScores);
// 理论上每个用户的值都应该是10，因为有100次操作，10个用户，每个用户被操作了10次。
// 验证：userScores.get("User0") 应该等于10
}
}在实际应用中，
putIfAbsent、
compute和
merge这些方法尤其重要，它们提供了原子性的复合操作，避免了“先检查后执行”可能导致的并发问题。例如，如果你想给一个计数器加一，直接使用
compute比
get再
put要安全得多。
立即学习“Java免费学习笔记（深入）”；
ConcurrentHashMap与HashMap、HashTable有何本质区别，何时选择ConcurrentHashMap？
这个问题，我个人觉得是理解ConcurrentHashMap价值的关键。我们先从源头说起：
HashMap：这是我们日常开发中最常用的哈希表，效率极高。但它天生就是为单线程环境设计的，在多线程下，如果你不加任何同步措施就去操作它，那简直是一场灾难。数据丢失、无限循环、内存溢出……各种诡异的Bug会层出不穷。所以，
HashMap是“快但不安全”的代表。
HashTable：Java早期的线程安全哈希表实现。它通过在所有公共方法上加
synchronized关键字来保证线程安全。听起来不错，但这意味着任何时候，只有一个线程能访问
HashTable的任何一个方法。当一个线程在
put数据时，其他线程无论是想
get还是
put，都得老老实实地等着。这种“全局锁”的机制，在并发量高的时候，性能会急剧下降，几乎完全串行化了。所以，
HashTable是“安全但慢”的典型。
ConcurrentHashMap：它就是为了解决
HashTable的性能瓶颈而生的。它的核心思想是“分段锁”或者更精确地说是“节点锁”。在Java 7及以前，它通过
Segment（分段）来实现，每个
Segment自身是一个独立的
ReentrantLock，只锁定哈希表的一部分，这样不同的线程就可以同时操作不同的
Segment，大大提升了并发度。到了Java 8，实现方式有所变化，它抛弃了
Segment，转而采用
CAS（Compare-And-Swap）操作和对
Node（节点）进行
synchronized锁定的方式。当哈希冲突严重时，链表会转换为红黑树，进一步优化性能。这种设计让
ConcurrentHashMap在保证线程安全的同时，能提供接近
HashMap的性能。
何时选择ConcurrentHashMap？
我的经验是，只要你的应用是多线程的，并且你需要一个共享的、可变的数据结构来存储键值对，那么几乎总是应该考虑
ConcurrentHashMap。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 高并发读写场景： 例如，一个缓存系统，多个线程需要同时查询和更新缓存项。
-
统计计数： 多个线程需要对某个事件进行计数，
compute
或merge
方法可以非常优雅地实现原子计数。 - 共享配置或状态： 当多个组件或服务需要访问和修改同一个配置或状态集合时。
如果你确定是单线程环境，或者只是作为局部变量使用，那
HashMap无疑是更轻量、更快的选择。而
HashTable，说实话，现在已经很少有场景会主动去使用了，
ConcurrentHashMap在几乎所有方面都优于它。
ConcurrentHashMap的底层实现原理是怎样的？（Java 8及以后版本）
理解ConcurrentHashMap的内部机制，能让我们更好地驾驭它，甚至在遇到一些“奇特”行为时能有所预判。Java 8的ConcurrentHashMap实现与Java 7及之前版本有显著不同，放弃了
Segment分段锁的模式，转而采用了一种更细粒度的锁定策略：CAS操作结合
synchronized锁。
简单来说，它的底层是一个
Node<K,V>[] table数组，每个数组元素可能是一个链表头，也可能是红黑树的根节点。
-
初始化与扩容：
table
数组的初始化是懒惰的，只有第一次put
操作时才会进行。- 扩容（
resize
）发生在table
容量不足时。与HashMap
类似，它会创建一个两倍大小的新数组，并将旧数组的元素迁移过去。但这个迁移过程是并发友好的，通过ForwardingNode
和辅助线程来协同完成，避免了长时间的全局停顿。
-
put
操作的核心流程：-
计算哈希： 首先，对键进行哈希处理，定位到
table
数组中的索引位置。 -
CAS尝试： 如果该位置为空，
ConcurrentHashMap
会尝试使用CAS
操作（Unsafe.compareAndSwapObject
）直接将新的Node
放置进去。这是非阻塞的，效率很高。 -
加锁处理： 如果该位置不为空（说明已经有元素或正在进行扩容），那么
ConcurrentHashMap
会锁定该索引位置的头节点（或ForwardingNode
）。注意，这里使用的是synchronized
关键字，锁的是具体的Node
对象，而不是整个table
。 -
链表/红黑树操作： 在获得锁之后，线程会检查该位置的结构。
- 如果是链表，就遍历链表，如果找到相同的键，就更新值；如果没找到，就添加到链表尾部。
- 如果链表长度超过阈值（默认8），链表会转换为红黑树，以保证在极端哈希冲突下的查找效率为O(logN)。
- 如果是红黑树，则按照红黑树的规则进行插入或更新。
-
计数与扩容：
put
成功后，会原子地更新size
计数器。如果size
超过了阈值，就会触发扩容。
-
计算哈希： 首先，对键进行哈希处理，定位到
-
get
操作：get
操作是完全无锁的。它也是先计算哈希，然后定位到table
数组的索引位置。- 接着，遍历链表或红黑树找到对应的键。由于
Node
的value
字段是volatile
的，所以get
操作能够保证读取到最新的值。 - 这种无锁读取的机制，是
ConcurrentHashMap
高并发读性能的关键。
volatile
与CAS
：ConcurrentHashMap
大量使用了volatile
关键字来保证内存可见性，以及CAS
操作来保证一些关键操作的原子性，例如在数组槽位上放置第一个节点。当CAS
失败时，才会退化到synchronized
锁。
总结一下，Java 8的ConcurrentHashMap通过
CAS的乐观锁尝试和
synchronized的悲观锁（针对单个
Node）结合，实现了在大多数情况下无锁或低锁竞争的高性能并发访问，同时在哈希冲突严重时通过红黑树保证了性能的稳定性。这是一种非常精妙的设计，体现了并发编程的艺术。
在使用ConcurrentHashMap时，有哪些常见的陷阱或性能考量？
尽管ConcurrentHashMap功能强大且性能卓越，但在实际使用中，仍然有一些点需要注意，否则可能会遇到一些意料之外的行为或性能问题。
-
复合操作的非原子性： 虽然
ConcurrentHashMap
的put
、get
、remove
等单个操作是线程安全的，但由这些操作组合而成的复合操作（例如get
一个值，根据它计算一个新值，再put
回去）并不是原子性的。 陷阱：// 假设多个线程同时执行这段代码，期望每次都递增1 Integer value = map.get("counter"); if (value == null) { map.put("counter", 1); } else { map.put("counter", value + 1); // 这里可能出现问题，两个线程同时get到旧值，导致只递增了一次 }解决方案： 使用
putIfAbsent
、compute
、merge
这些原子性的复合操作。// 正确的递增方式 map.compute("counter", (key, oldValue) -> oldValue == null ? 1 : oldValue + 1); 不允许null键或null值：
ConcurrentHashMap
和HashTable
一样，不允许null
作为键或值。这是为了避免歧义，因为get(key)
返回null
可能意味着键不存在，也可能意味着键存在但其值为null
。 陷阱： 如果你不小心尝试put(null, value)
或put(key, null)
，会直接抛出NullPointerException
。 解决方案： 始终确保你的键和值是非null
的。如果业务上需要表示“无值”，可以考虑使用Optional
或特定的占位符对象。迭代器的弱一致性：
ConcurrentHashMap
的迭代器是弱一致性的（weakly consistent），这意味着它不会抛出ConcurrentModificationException
，但在迭代过程中，如果其他线程修改了Map，迭代器可能不会反映这些修改，也可能部分反映。它反映的是在迭代器创建时或创建后某个时刻的映射状态。 陷阱： 如果你的业务逻辑强依赖于迭代时的数据快照，并且要求数据在迭代过程中不能有任何变化，那么弱一致性可能会导致问题。 解决方案： 如果需要一个严格的快照，你可能需要先将ConcurrentHashMap
的内容复制到一个线程安全的集合中（例如new ArrayList<>(map.entrySet())
），然后迭代这个副本。当然，这会引入额外的内存和复制开销。对于大多数并发场景，弱一致性通常是可接受的。-
初始容量与负载因子： 虽然
ConcurrentHashMap
在扩容方面做得很好，但如果你能预估Map的大小，并设置一个合理的初始容量（initialCapacity
），仍然可以减少扩容的次数，从而避免扩容带来的性能开销。 考量： 过小的初始容量会导致频繁扩容；过大的初始容量会浪费内存。通常，将其设置为你预计最大元素数量的两倍是一个不错的起点，因为ConcurrentHashMap
的默认负载因子是0.75。// 假设你预计会有大约1000个元素 ConcurrentHashMap<String, Data> myCache = new ConcurrentHashMap<>(1500); // 1500 * 0.75 约等于 1125
键的哈希性能：
ConcurrentHashMap
的性能高度依赖于键的hashCode()
和equals()
方法的实现。一个设计糟糕的哈希函数会导致大量的哈希冲突，使得大部分元素都集中在少数几个桶中，从而退化成链表或红黑树，降低查找效率。 考量： 确保你的自定义键类正确且高效地实现了hashCode()
和equals()
。一个好的哈希函数应该能将键均匀地分布在哈希空间中。内存占用：
ConcurrentHashMap
为了实现线程安全和高并发，每个Node
（或Entry
）通常会比HashMap
多一些字段（例如用于链表/红黑树的指针、哈希值等）。这会导致在存储大量小对象时，其内存占用会略高于HashMap
。 考量： 在内存极其敏感的场景下，需要权衡并发性能和内存消耗。
理解这些点，可以帮助我们更自信、更高效地在项目中运用ConcurrentHashMap。它是一个强大的工具，但任何工具都有其最佳使用场景和需要注意的细节。
