当列表的生命周期遵循“只读访问 + 全量替换”这个模式时——也就是只有 refresh() 方法会整体赋值一个新列表，压根儿没有 add、remove、set 这些原地修改操作——直接用 synchronized 方法固然能保证安全，但有点大炮打蚊子的感觉，白白引入了不必要的串行化开销。实际上，Java 内存模型中那些轻量级的可见性保证，才是更对路的解法。

先说一个核心判断：这种情况下，使用 volatile 字段是最干净利落的方案。

private volatile List list = Collections.emptyList();

public Foo getFoo(Condition condition) {
    // 读取是无锁、非阻塞的
    for (Foo foo : list) {
        if (condition.check(foo)) {
            return foo;
        }
    }
    return null;
}

public void refresh() {
    // 原子写入新列表引用，对所有线程立即可见
    list = List.copyOf(fetchFromDB()); // Java 10+，安全不可变副本
    // 或：list = Collections.unmodifiableList(new ArrayList<>(fetchFromDB()));
}

volatile 干了件什么事呢？它保证了 list 引用的写可见性和读一致性。也就是说，任何线程只要调用了 refresh()，其他线程后续再去读 list，看到的绝对是最新引用，而且不会出现看到部分构造的中间状态这种尴尬局面。

如果你想再稳妥一点，语义上更明确一些，可以考虑 AtomicReference>。

private final AtomicReference> listRef = new AtomicReference<>(Collections.emptyList());

public Foo getFoo(Condition condition) {
    for (Foo foo : listRef.get()) {
        if (condition.check(foo)) {
            return foo;
        }
    }
    return null;
}

public void refresh() {
    List fresh = List.copyOf(fetchFromDB());
    listRef.set(fresh); // 或使用 compareAndSet 实现条件更新
}

AtomicReference 提供了更强的 API 语义——比如 get()、set() 和 compareAndSet()，如果未来你可能会扩展原子性条件更新的逻辑，这个方案会更顺手。性能上和 volatile 基本一个水平，可以放心使用。

不过，这里有个绝对不能含糊的前提：被引用的 List 以及它里面的元素 Foo，必须是不可变的，或者线程安全的。否则，局面就很尴尬了——引用更新是原子的，但读的时候可能还是会撞上竞态数据。

举个反例：如果你写了 list = new ArrayList<>(fetchFromDB())，那返回的 ArrayList 是可变的，外部线程一不小心就能给你改了，线程安全瞬间崩塌。正确做法是始终用 List.copyOf()（JDK 10+ 推荐，零拷贝且语义明确）、Collections.unmodifiableList() 或者 Guava 的 ImmutableList 来封装。

// 推荐（JDK 10+）—— 零拷贝（若源集合本身不可变）+ 显式不可变语义
list = List.copyOf(fetchFromDB());

// 兼容旧版 JDK
list = Collections.unmodifiableList(new ArrayList<>(fetchFromDB()));

建议在字段声明旁加个注释，强化这个契约，免得后来接手的人踩坑：

// IMPORTANT: list must be unmodifiable; mutation breaks thread-safety!
private volatile List list = Collections.emptyList();

有朋友可能会问：那为什么不选 CopyOnWriteArrayList？

这问题问得好。CopyOnWriteArrayList 的定位是高频读 + 低频单元素写的场景——比如偶尔 add 或 remove 一个元素。它的每次写操作都会复制整个数组，成本不低。而我们这个场景里，refresh() 本身就是全量重建，CopyOnWriteArrayList 不仅复用不了已有结构，还多了一层冗余复制，加上还需要额外同步来保证 getFoo() 遍历的原子性，实在得不偿失。

最后总结一下这张表格里的权衡：

对于绝大多数场景，直接用 volatile 就够了——用最小的代码成本，换来无锁、高吞吐、强一致的线程安全保证，这才是真正务实的写法。