ConcurrentHashMap常用方法及使用技巧

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 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要安全得多。

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。

• 高并发读写场景： 例如，一个缓存系统，多个线程需要同时查询和更新缓存项。
• 统计计数： 多个线程需要对某个事件进行计数，compute或merge方法可以非常优雅地实现原子计数。
• 共享配置或状态： 当多个组件或服务需要访问和修改同一个配置或状态集合时。

如果你确定是单线程环境，或者只是作为局部变量使用，那HashMap无疑是更轻量、更快的选择。而HashTable，说实话，现在已经很少有场景会主动去使用了，ConcurrentHashMap在几乎所有方面都优于它。

ConcurrentHashMap的底层实现原理是怎样的？（Java 8及以后版本）

理解ConcurrentHashMap的内部机制，能让我们更好地驾驭它，甚至在遇到一些“奇特”行为时能有所预判。Java 8的ConcurrentHashMap实现与Java 7及之前版本有显著不同，放弃了Segment分段锁的模式，转而采用了一种更细粒度的锁定策略：CAS操作结合synchronized锁。

简单来说，它的底层是一个Node[] table数组，每个数组元素可能是一个链表头，也可能是红黑树的根节点。

1. 初始化与扩容：

   • table数组的初始化是懒惰的，只有第一次put操作时才会进行。
   • 扩容（resize）发生在table容量不足时。与HashMap类似，它会创建一个两倍大小的新数组，并将旧数组的元素迁移过去。但这个迁移过程是并发友好的，通过ForwardingNode和辅助线程来协同完成，避免了长时间的全局停顿。

2. put操作的核心流程：

   • 计算哈希： 首先，对键进行哈希处理，定位到table数组中的索引位置。
   • CAS尝试： 如果该位置为空，ConcurrentHashMap会尝试使用CAS操作（Unsafe.compareAndSwapObject）直接将新的Node放置进去。这是非阻塞的，效率很高。
   • 加锁处理： 如果该位置不为空（说明已经有元素或正在进行扩容），那么ConcurrentHashMap会锁定该索引位置的头节点（或ForwardingNode）。注意，这里使用的是synchronized关键字，锁的是具体的Node对象，而不是整个table。
   • 链表/红黑树操作： 在获得锁之后，线程会检查该位置的结构。
     • 如果是链表，就遍历链表，如果找到相同的键，就更新值；如果没找到，就添加到链表尾部。
     • 如果链表长度超过阈值（默认8），链表会转换为红黑树，以保证在极端哈希冲突下的查找效率为O(logN)。
     • 如果是红黑树，则按照红黑树的规则进行插入或更新。
   • 计数与扩容： put成功后，会原子地更新size计数器。如果size超过了阈值，就会触发扩容。

3. get操作：

   • get操作是完全无锁的。它也是先计算哈希，然后定位到table数组的索引位置。
   • 接着，遍历链表或红黑树找到对应的键。由于Node的value字段是volatile的，所以get操作能够保证读取到最新的值。
   • 这种无锁读取的机制，是ConcurrentHashMap高并发读性能的关键。

4. volatile与CAS： ConcurrentHashMap大量使用了volatile关键字来保证内存可见性，以及CAS操作来保证一些关键操作的原子性，例如在数组槽位上放置第一个节点。当CAS失败时，才会退化到synchronized锁。

总结一下，Java 8的ConcurrentHashMap通过CAS的乐观锁尝试和synchronized的悲观锁（针对单个Node）结合，实现了在大多数情况下无锁或低锁竞争的高性能并发访问，同时在哈希冲突严重时通过红黑树保证了性能的稳定性。这是一种非常精妙的设计，体现了并发编程的艺术。

在使用ConcurrentHashMap时，有哪些常见的陷阱或性能考量？

尽管ConcurrentHashMap功能强大且性能卓越，但在实际使用中，仍然有一些点需要注意，否则可能会遇到一些意料之外的行为或性能问题。

1. 复合操作的非原子性： 虽然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);

2. 不允许null键或null值：ConcurrentHashMap和HashTable一样，不允许null作为键或值。这是为了避免歧义，因为get(key)返回null可能意味着键不存在，也可能意味着键存在但其值为null。 陷阱： 如果你不小心尝试put(null, value)或put(key, null)，会直接抛出NullPointerException。 解决方案： 始终确保你的键和值是非null的。如果业务上需要表示“无值”，可以考虑使用Optional或特定的占位符对象。

3. 迭代器的弱一致性：ConcurrentHashMap的迭代器是弱一致性的（weakly consistent），这意味着它不会抛出ConcurrentModificationException，但在迭代过程中，如果其他线程修改了Map，迭代器可能不会反映这些修改，也可能部分反映。它反映的是在迭代器创建时或创建后某个时刻的映射状态。 陷阱： 如果你的业务逻辑强依赖于迭代时的数据快照，并且要求数据在迭代过程中不能有任何变化，那么弱一致性可能会导致问题。 解决方案： 如果需要一个严格的快照，你可能需要先将ConcurrentHashMap的内容复制到一个线程安全的集合中（例如new ArrayList<>(map.entrySet())），然后迭代这个副本。当然，这会引入额外的内存和复制开销。对于大多数并发场景，弱一致性通常是可接受的。

4. 初始容量与负载因子： 虽然ConcurrentHashMap在扩容方面做得很好，但如果你能预估Map的大小，并设置一个合理的初始容量（initialCapacity），仍然可以减少扩容的次数，从而避免扩容带来的性能开销。 考量： 过小的初始容量会导致频繁扩容；过大的初始容量会浪费内存。通常，将其设置为你预计最大元素数量的两倍是一个不错的起点，因为ConcurrentHashMap的默认负载因子是0.75。

   // 假设你预计会有大约1000个元素
   ConcurrentHashMap myCache = new ConcurrentHashMap<>(1500); // 1500 * 0.75 约等于 1125

5. 键的哈希性能：ConcurrentHashMap的性能高度依赖于键的hashCode()和equals()方法的实现。一个设计糟糕的哈希函数会导致大量的哈希冲突，使得大部分元素都集中在少数几个桶中，从而退化成链表或红黑树，降低查找效率。 考量： 确保你的自定义键类正确且高效地实现了hashCode()和equals()。一个好的哈希函数应该能将键均匀地分布在哈希空间中。

6. 内存占用：ConcurrentHashMap为了实现线程安全和高并发，每个Node（或Entry）通常会比HashMap多一些字段（例如用于链表/红黑树的指针、哈希值等）。这会导致在存储大量小对象时，其内存占用会略高于HashMap。 考量： 在内存极其敏感的场景下，需要权衡并发性能和内存消耗。

理解这些点，可以帮助我们更自信、更高效地在项目中运用ConcurrentHashMap。它是一个强大的工具，但任何工具都有其最佳使用场景和需要注意的细节。