对非final字段的ImmutableCollection操作是否线程安全？

咱们先拆解你的问题，一步步说清楚：

首先，ImmutableMap本身是绝对线程安全的——因为它的设计就是一旦创建就完全不可变，没有任何修改内部状态的方法，所以不管多少线程同时调用它的get方法，都不会出现并发问题，也不会读到内部的无效状态。

接下来看你的场景里的核心风险点：非final的states字段的可见性和赋值原子性：

1. 会不会读到“nonsense”？绝对不会
   Java里对引用类型的赋值是原子操作，也就是说states = ImmutableMap.of(hashMap)这行代码，要么完全把新的ImmutableMap实例的引用赋值给states，要么还是旧的引用，不会出现“一半新一半旧”的中间状态。而且ImmutableMap.of()返回的是完全构造好的、状态稳定的实例，所以读线程不管什么时候读states，拿到的要么是初始的空ImmutableMap，要么是某次写操作生成的完整的新ImmutableMap，绝不会读到构造到一半的无效对象。

2. 能不能保证线性化？不能
   你提到的线性化要求所有操作看起来像是在某个全局一致的时间点完成的，但现在的写法做不到：

   • 写线程的synchronized方法确实能保证写操作内部的逻辑（复制旧map、添加新值、赋值新map）是原子的，而且退出synchronized块时会触发内存屏障，把更新同步到主内存。但读线程没有任何内存屏障——它可能会一直从自己的线程缓存里读取旧的states值，哪怕写线程已经完成了赋值。也就是说，读线程可能在写操作完成很久之后，还在读取旧的map，这就不符合线性化的要求，因为不同线程看到的操作顺序不一致。

3. 怎么修复才能保证可见性和线性化？
   最简洁高效的方案是把states字段声明为volatile：

   private volatile ImmutableMap<String, State> states = ImmutableMap.of();
   

   volatile关键字会保证：

   • 每次读states都会直接从主内存获取最新值，不会用线程缓存的旧值；
   • 每次写states都会立即把新值刷新到主内存，让其他线程能看到；
   • 同时引用赋值的原子性依然保留，完美解决你的问题。

   当然，你也可以把读方法也改成synchronized，但这样会带来不必要的锁竞争，性能不如用volatile划算——毕竟我们只需要保证引用的可见性，而不是整个读操作的原子性。

备注：内容来源于stack exchange，提问作者blonded04