多线程下用 ConcurrentHashMap，到底要不要加 volatile？

这段时间在看并发相关的面试题，碰到一个特别容易让人绕晕的问题：多线程环境里使用 ConcurrentHashMap，要不要把它声明成 volatile 才能保证线程安全？

单独拎出来 ConcurrentHashMap 和 volatile，每个知识点我都能说上几句，可把它们放在一起提问，瞬间就有种熟悉又陌生的感觉，琢磨了好一会儿才理清楚里面的逻辑，今天就把自己的思考过程整理出来，都是很实在的理解，没有什么官方套话。

先把两个核心概念掰扯明白，这是搞懂整个问题的基础，后续的分析都要围绕这两个点展开。

先搞懂两个关键角色

ConcurrentHashMap 是做什么的

日常开发里，ConcurrentHashMap 算是并发场景的常客，面试里也总爱把它和 HashMap 放在一起对比。大家都知道 HashMap 不支持多线程并发操作，在多线程环境下会出现数据错乱的问题，而 ConcurrentHashMap 就是 Java 提供的线程安全的哈希表实现。

但这里必须抓住一个核心点：ConcurrentHashMap 的线程安全，只局限在它自身方法内部的操作。
比如调用它的 put、get、remove 这些方法，多个线程同时执行，底层通过 CAS 加同步机制等方式，能保证单个方法执行的原子性和数据一致性，不会出现并发修改导致的异常。但它管不了的是，这个 ConcurrentHashMap 实例的引用，在多线程之间的可见性问题。

volatile 又是做什么的

volatile 也是并发编程里的高频关键字，它的作用其实很明确，主要解决两个问题：一是保证变量的可见性，一个线程修改了被 volatile 修饰的变量，其他线程能立刻读取到最新的值，不会出现线程本地缓存和主内存数据不一致的情况；二是禁止指令重排序，避免编译器和处理器对指令的执行顺序做优化，导致多线程下出现意料之外的问题。

这里要划一个重点：volatile 修饰的是变量，也就是对象的引用，而不是对象内部的数据。想把 ConcurrentHashMap 和 volatile 关联起来，前提是 ConcurrentHashMap 作为一个引用变量，存在被修改的可能，否则讨论 volatile 就没有任何意义。

分场景看，到底要不要加 volatile

这个问题根本没有绝对的“要”或“不要”，必须结合实际的代码场景来判断，两种情况的区别非常明显。

场景一：ConcurrentHashMap 引用不会改变，不需要加 volatile

当我们在代码中，初始化 ConcurrentHashMap 之后，全程只调用它的内部方法操作数据，从来不会重新给这个变量赋值，让它指向新的实例，这种情况下完全不需要加 volatile。

最典型的写法就是用 final 修饰，直接锁定引用：

public class CacheService {
    // 用 final 保证引用不可变，全程只会操作这一个 CHM 实例
    private static final ConcurrentHashMap<String, Object> concurrentCache = new ConcurrentHashMap<>();

    public void putData(String key, Object value) {
        // 仅调用 CHM 自身的方法，内部已保证线程安全
        concurrentCache.put(key, value);
    }

    public Object getData(String key) {
        return concurrentCache.get(key);
    }
}

在这段代码里，concurrentCache 的引用从初始化后就不会再改变，所有线程操作的都是同一个 ConcurrentHashMap 实例。此时线程安全完全由 ConcurrentHashMap 自身的方法保证，volatile 在这里没有任何发挥的空间，加上反而属于多余的代码。

场景二：ConcurrentHashMap 引用会被重新赋值，必须加 volatile

如果业务逻辑中，需要替换掉原来的 ConcurrentHashMap 实例，把新的实例赋值给同一个变量，这时候就必须使用 volatile 来保证引用的可见性。

比如常见的缓存全量更新场景，代码大概是这样：

public class CacheService {
    // 引用可能被替换，必须加 volatile 保证可见性
    private volatile ConcurrentHashMap<String, Object> concurrentCache = new ConcurrentHashMap<>();

    /**
     * 全量更新缓存，直接替换整个 CHM 实例
     */
    public void refreshCache() {
        // 创建新的缓存实例，加载全量数据
        ConcurrentHashMap<String, Object> newCache = new ConcurrentHashMap<>();
        // 模拟加载缓存数据的逻辑
        newCache.put("user:1", "张三");
        newCache.put("user:2", "李四");
        // 替换原有的缓存引用
        concurrentCache = newCache;
    }

    public Object getData(String key) {
        return concurrentCache.get(key);
    }
}

在这个场景里，concurrentCache 这个引用变量会被重新赋值，指向新的 ConcurrentHashMap 实例。如果不加 volatile，当一个线程执行了 refreshCache 方法替换了引用后，其他线程可能还在读取旧的引用，使用的是过时的缓存数据，这就产生了线程安全问题。
而加上 volatile 之后，就能保证引用修改的可见性，所有线程都能立即获取到最新的实例引用，再结合 ConcurrentHashMap 自身的方法安全，整个流程才是完整的线程安全。

结合实际业务，再加深理解

平时做 Spring Web 开发的时候，经常会把 ConcurrentHashMap 作为成员变量放在 Controller 里，这里就很容易踩坑，我们可以看一段实际的示例代码：

@RestController
public class DataController {
    // 单例 Bean 下的 CHM 成员变量
    private ConcurrentHashMap<String, String> dataMap = new ConcurrentHashMap<>();

    @GetMapping("/add")
    public String addData(String key, String value) {
        dataMap.put(key, value);
        return "添加成功";
    }

    @GetMapping("/get")
    public String getData(String key) {
        return dataMap.get(key);
    }

    /**
     * 新增的方法，直接替换 CHM 引用
     */
    @GetMapping("/reset")
    public String resetData() {
        // 此处直接重新赋值，修改了引用
        dataMap = new ConcurrentHashMap<>();
        return "缓存已重置";
    }
}

Spring 的 Controller 默认是单例作用域，所有的请求都会共享同一个 DataController 实例，也就共享同一个 dataMap 变量。
在只调用 addData 和 getData 方法时，dataMap 的引用没有改变，依靠 ConcurrentHashMap 自身的安全性，不会出现线程问题。但新增了 resetData 方法后，dataMap 会被重新赋值，指向新的实例，此时没有 volatile 修饰，就会出现部分线程读取到旧实例、部分读取到新实例的问题，导致数据不一致。

解决这个问题的方式也很清晰：

1. 给 dataMap 加上 volatile 关键字，保证引用的可见性；
2. 给 dataMap 加上 final 关键字，禁止引用被重新赋值，从根源上杜绝问题；
3. 将 Controller 的作用域改为 prototype，每次请求创建新实例，让每个线程操作独立的 CHM，但这种方式会增加内存开销，需要结合业务权衡。

再延伸一个容易忽略的点

这里还要补充一个很重要的误区，就算我们用了线程安全的 ConcurrentHashMap，也不代表所有场景下都绝对安全，尤其是涉及到复合操作的时候。

举个简单的例子，想要实现“如果 key 不存在，就放入数据”的逻辑：

public void putIfNotExist(String key, String value) {
    // 先查询，再插入，两步操作
    if (!concurrentCache.containsKey(key)) {
        concurrentCache.put(key, value);
    }
}

ConcurrentHashMap 的 containsKey 和 put 方法都是线程安全的，但这两个方法组合在一起，就变成了非原子操作。多线程环境下，可能两个线程同时判断 key 不存在，然后先后执行 put 方法，导致后执行的线程覆盖了先执行的线程的数据。

这种情况，ConcurrentHashMap 自身的线程安全解决不了，需要我们额外处理，比如使用 ConcurrentHashMap 提供的原子方法 putIfAbsent，或者通过加锁来保证复合操作的原子性。

这也印证了一个道理：线程安全是一个全局的问题，不能只依赖某一个组件的特性，就觉得万事大吉，所有的逻辑都要结合具体的使用场景去分析。

回到最开始的问题，现在再看，答案其实已经很清晰了。ConcurrentHashMap 负责自身方法的线程安全，volatile 负责引用变量的可见性，两者的作用颗粒度完全不同。只有当 ConcurrentHashMap 的引用存在被修改的场景时，才需要使用 volatile，否则完全没有必要添加。