volatile仅保证被修饰变量（引用）的可见性与禁止重排序，不保证其指向对象内部状态的线程安全；需配合线程安全容器、不可变对象或同步机制才能确保内部状态可见。
volatile 本身不“避免”伪语义——它根本不管对象内部发生了什么。它只对被修饰的变量本身起作用，也就是那个引用地址的读写可见性与重排序约束。当你写 private volatile List<string> list = new ArrayList();</string>，volatile 保证的是：其他线程能立即看到 list 这个引用是否被替换成另一个 List 对象，但绝不保证你调用 list.add("x") 后，这个新增元素对其他线程可见。
volatile 只管“引用”，不管“内容”
被 volatile 修饰的是变量的值（即对象引用），不是对象内部状态。JVM 不会、也不能自动追踪该对象所有字段的变更。所以：
- 修改引用本身（如
list = new CopyOnWriteArrayList()）→ volatile 生效，其他线程立刻看到新引用 - 通过引用修改对象内部（如
list.add(...)、map.put(...)、obj.field = 1）→ volatile 完全不干预，这些操作仍受各自类本身的线程安全机制约束
嵌套对象要真正可见，得靠对象自身线程安全
如果需要让对象内部状态变更对其他线程可见，必须让该对象本身具备线程安全能力：
- 用线程安全容器：比如
CopyOnWriteArrayList、ConcurrentHashMap、AtomicIntegerArray - 用不可变对象（Immutable）：如
ImmutableList.of()，每次修改返回新对象，配合 volatile 引用才能实现“逻辑可见” - 手动加锁或使用原子类：若自定义类含多个字段，需用
synchronized或java.util.concurrent.atomic包下的原子类型封装关键字段
常见误用：以为 volatile + 普通对象 = 线程安全
下面这段代码是危险的：
立即学习“Java免费学习笔记（深入）”；
private volatile Map<string integer> cache = new HashMap();</string>cache.put("key", 42); // 其他线程看不到这个 put！
原因：volatile 仅确保 cache 引用没被缓存；但 HashMap 非线程安全，put 操作可能引发数据错乱，且其内部字段变更不触发 volatile 语义。
正确做法是换为：private volatile ConcurrentHashMap<string integer> cache = new ConcurrentHashMap();</string>，或干脆去掉 volatile，直接用 ConcurrentHashMap 自身的线程安全保证。
真正需要 volatile 的典型场景
它适合做“开关”“标志位”“单次发布”的轻量同步：
- 线程运行控制：
private volatile boolean running = true; - 单例双重检查锁中的 instance 引用：
private static volatile Singleton instance; - 一次性状态发布（如配置加载完成）：
private volatile Config config;，之后只做config = loadedConfig;
只要不指望它让 config.someField 的修改也自动可见——那就得让 Config 类自己保证字段的可见性（比如字段也加 volatile，或用 final，或封装在原子类里）。
