ConcurrentHashMap线程安全原理解析

本文深入剖析了Java并发集合的核心代表——ConcurrentHashMap的底层原理与设计智慧，揭示其为何在高并发场景下远超HashTable和Collections.synchronizedMap：通过JDK 7的分段锁到JDK 8的CAS+synchronized精细化协同，实现无锁读、桶级细粒度写、链表/红黑树动态优化及多线程协作扩容，让并发性能跃升；同时对比介绍了CopyOnWriteArrayList、ConcurrentLinkedQueue等并发集合的适用边界，强调在真实业务中应优先选用java.util.concurrent包中为并发而生的高性能原生组件——读懂它，就是掌握Java高并发编程的关键突破口。

在Java中，实现线程安全集合的首选方式是使用java.util.concurrent包中的并发集合类。1. ConcurrentHashMap通过分段锁（JDK 7及之前）或CAS+synchronized（JDK 8及以上）机制提供高并发性能，避免了全局锁带来的性能瓶颈；2. CopyOnWriteArrayList适用于读多写少场景，通过写时复制保证线程安全；3. ConcurrentLinkedQueue和ArrayBlockingQueue分别适用于无界非阻塞和有界阻塞队列需求。相较于HashTable和Collections.synchronizedMap的粗粒度锁机制，ConcurrentHashMap通过细粒度锁和无锁读操作显著提升了并发效率。其get方法利用volatile变量和不可变Node对象实现无需加锁的线程安全读取。put操作则结合CAS尝试无锁插入，并在冲突时锁定单个桶节点以支持并发修改。扩容时采用多线程协作迁移数据的方式，进一步减少了对整体性能的影响。因此，在并发编程中应优先选用这些专为并发优化的集合类。

在Java中，要实现多线程安全的集合，最直接且高效的方式是使用java.util.concurrent包下提供的并发集合类。这些类经过精心设计，能够在高并发场景下提供优秀的性能和线程安全性，其中ConcurrentHashMap就是典范。当然，你也可以通过Collections.synchronizedMap()等方式对现有集合进行包装，但其并发性能通常不如专门的并发集合。

解决方案

当我们需要一个线程安全的Map时，ConcurrentHashMap是首选。它通过精细的锁控制（而非全局锁）实现了高并发访问。对于列表，CopyOnWriteArrayList在读多写少场景下表现出色，因为它在写入时会复制底层数组，保证了读操作的无锁化。而对于队列，ConcurrentLinkedQueue和ArrayBlockingQueue等则提供了不同的并发队列实现，前者是无界非阻塞的，后者是有界阻塞的。选择哪种取决于具体的业务需求和并发模式。通常，优先考虑java.util.concurrent包中的类，它们在设计上就考虑到了并发问题，且性能经过了高度优化。

ConcurrentHashMap为什么比HashTable和Collections.synchronizedMap更高效？

这其实是个很有趣的问题，它揭示了并发编程中锁粒度对性能的决定性影响。HashTable和通过Collections.synchronizedMap包装的HashMap，它们实现线程安全的方式是简单粗暴的：在几乎所有公共方法上都加上了synchronized关键字。这意味着，无论你是在读数据还是写数据，只要有一个线程在操作这个Map，整个Map就被锁住了，其他所有试图访问的线程都得排队等待。这就像一家餐厅，只有一个服务员，每次只能服务一位顾客，效率自然低下。

ConcurrentHashMap则完全不同。在JDK 7及之前的版本，它采用了“分段锁”（Segment Lock）的机制，将整个Map划分为若干个Segment，每个Segment都是一个独立的HashTable。当一个线程修改某个Segment时，只会锁住这个Segment，其他线程仍然可以访问其他Segment。这就大大提升了并发度。

而到了JDK 8，ConcurrentHashMap的实现进一步优化，取消了Segment的概念，转而采用了“CAS（Compare-And-Swap）+ synchronized”的策略。它的核心思想是：

• 无锁读操作： get操作通常不需要加锁，因为它利用了volatile和内存屏障的特性，保证了读取到的数据是最新的。
• CAS操作： 对于一些简单的修改操作，例如在桶（bucket）为空时尝试放入第一个节点，ConcurrentHashMap会尝试使用CAS操作来原子性地更新。如果成功，则无需加锁。
• 细粒度锁： 只有当发生哈希冲突，需要修改链表或红黑树结构时，才会对链表或红黑树的头节点进行synchronized锁定。这意味着，即使在同一个桶内，只要不是修改同一个链表或树的结构，不同的线程也可以同时进行操作。当链表过长时，还会转换为红黑树以优化查找性能。

这种设计使得ConcurrentHashMap在大多数情况下都能实现很高的并发度，因为大部分操作都不需要等待全局锁，甚至不需要等待桶级别的锁，只有在真正需要修改共享结构时才加锁，而且锁的粒度非常小。

ConcurrentHashMap的get方法是如何实现线程安全的？

ConcurrentHashMap的get方法实现线程安全，但又无需加锁，这得益于Java内存模型（JMM）中的volatile关键字和其内部数据结构的巧妙设计。

ConcurrentHashMap的底层是一个Node数组，这个数组被volatile修饰。volatile确保了两点：

1. 可见性： 当一个线程修改了Node数组中的某个元素（比如替换了一个Node对象），这个修改会立即对所有其他线程可见。
2. 有序性： 编译器和处理器不会对volatile变量的操作进行重排序，保证了操作的顺序性。

在get操作中：

• 它首先会读取volatile修饰的table数组，确保获取到的是最新的数组引用。
• 接着，根据键的哈希值定位到对应的桶（Node数组的索引）。
• 然后，它遍历该桶中的链表或红黑树来查找目标键值对。

这里的关键在于，Node对象本身（存储键值对）一旦被创建并放入桶中，其内部的键和值通常是不可变的（final修饰）。即使需要更新某个键的值，ConcurrentHashMap也可能通过创建新的Node并替换旧Node的方式来实现，或者利用CAS操作原子性地更新Node内部的值。由于get操作只是读取已经存在的Node及其内容，而volatile保证了Node数组的可见性，使得get总是能看到最新的Node引用。在遍历链表或红黑树时，由于Node之间的引用也是通过volatile或CAS保证了可见性和原子性，因此get操作可以在没有显式锁的情况下安全地进行。它避免了读写冲突，因为读操作不会阻塞写操作，写操作也不会阻塞读操作（除非写操作正在改变整个桶的结构，比如链表转红黑树，但即便如此，get也只是读取旧的引用，最终会看到最新的状态）。

ConcurrentHashMap在put操作中如何处理并发冲突和扩容？

ConcurrentHashMap的put操作是其并发性能的核心体现，它巧妙地结合了CAS和synchronized来处理并发冲突和扩容。

处理并发冲突： 当一个线程调用put方法时：

1. 计算哈希值： 首先根据键计算哈希值，并确定目标桶（Node数组的索引）。
2. 检查桶状态：
   • 如果目标桶为空，put操作会尝试使用CAS来放置第一个Node。如果CAS成功，操作完成，无需加锁。
   • 如果目标桶不为空，说明该桶已经有元素。此时，put操作会尝试对该桶的头节点进行synchronized锁定。这个锁是针对单个桶的，而不是整个Map。
3. 遍历与插入/更新：
   • 在获取到桶锁后，线程会遍历链表或红黑树。
   • 如果找到相同的键，则更新其值。这可能涉及CAS操作（如果Node支持原子更新）或在锁内直接修改。
   • 如果未找到相同键，则将新的Node插入到链表末尾或红黑树中。
4. 链表转红黑树： 如果某个桶的链表长度超过了TREEIFY_THRESHOLD（默认为8），ConcurrentHashMap会将该链表转换为红黑树，以优化查找性能。这个转换过程也是在桶锁的保护下进行的。

通过这种方式，ConcurrentHashMap避免了对整个Map的锁定，允许多个线程同时修改不同桶中的元素，大大提高了并发度。只有当多个线程恰好要修改同一个桶时，才需要竞争同一个桶锁。

处理扩容（Resizing）：ConcurrentHashMap的扩容机制也设计得非常巧妙，支持并发扩容：

1. 触发扩容： 当Map中的元素数量达到一定阈值（capacity * loadFactor）时，会触发扩容。
2. 创建新表： ConcurrentHashMap会创建一个两倍于当前容量的新Node数组。
3. 并发迁移： 扩容并不是由一个线程独自完成的，而是可以由多个线程协助完成。
   • 当一个线程发现Map正在扩容时（通过检查桶中是否有ForwardingNode标记），它会加入到迁移工作中。
   • 每个线程负责迁移一部分桶。它会从旧表的末尾开始，向头部遍历，每次处理一个或多个桶。
   • 在迁移每个桶时，该线程会锁定当前桶的头节点，然后将该桶中的所有Node重新哈希并复制到新表中对应的位置。
   • 迁移完成后，旧表中的对应桶会被放置一个ForwardingNode，表示该桶的数据已经迁移到新表，并指向新表。
4. CAS更新表引用： 当所有桶都迁移完成后，ConcurrentHashMap会使用CAS操作原子性地将table引用指向新的Node数组。

这种并发迁移的设计，使得扩容过程不会长时间阻塞整个Map的读写操作，进一步提升了ConcurrentHashMap在高并发场景下的可用性和性能。它巧妙地利用了CAS和细粒度锁，将一个看似复杂的全局操作分解为多个可以并行执行的小任务。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。