volatile修饰数组仅保证引用可见性，不保证元素可见性；因其语义作用于引用变量本身，而非所指向数组对象的内部元素，故arr[0] = 42不会触发主内存刷新，读线程可能持续读取工作内存旧值。
volatile 修饰数组时，仅保证数组引用的可见性，不保证数组内部元素修改的可见性。 这是 Java 内存模型（JMM）的明确行为，不是偶然现象或 JVM 差异，所有符合规范的 JDK 实现都如此。关键在于：volatile 的语义作用于变量本身（这里是“数组引用”），而非它所指向的对象内容。
为什么 arr[0] = 42 不被其他线程立即看到？
因为 volatile 修饰的是 arr 这个引用变量，不是 arr 所指向的 int[] 对象内部的每个 int 元素。当执行 arr[0] = 42 时：
- JVM 只将该写操作视为对堆中数组对象某字段的普通更新；
- 没有 volatile 语义加持，该写操作不会强制刷新到主内存，也不要求其他线程从主内存重读该位置；
- 读线程可能一直读取自己工作内存中缓存的旧值（如 0），陷入无限循环。
两个典型对比实验
✅ 引用变更可见（volatile 生效）：
线程 A 执行 a = new int[]{0}; —— 修改的是 volatile 修饰的引用变量 a，其他线程能立即看到 a 指向了新数组。
❌ 元素变更不可见（volatile 失效）：
线程 A 执行 a[0] = 0; —— 修改的是数组对象内部的元素，volatile 不覆盖这一层，其他线程可能永远读不到 0。
为什么有些实验看似“成功”了？
某些测试代码中，while(a[0] != 9) {} 最终退出，并非因为 volatile 保证了元素可见，而是受以下干扰因素影响：
- 主线程 sleep 或 System.out.println() 引入了隐式内存屏障（如 synchronized 锁操作），意外触发了工作内存刷新；
- JIT 编译器优化未生效（如未进入激进优化阶段），掩盖了可见性问题；
如何真正保证数组元素可见？
不能依赖 volatile 数组，需改用以下任一方式：
- 用
AtomicIntegerArray替代普通数组，它对每个元素的读写都带 volatile 语义； - 用
synchronized块保护数组读写，借助锁的内存语义强制刷新； - 将数组元素声明为独立的 volatile 字段（如 volatile int a0, a1, a2…），但失去数组结构优势；
- 像 ConcurrentHashMap 那样，用
Unsafe.getObjectVolatile()手动插入读屏障（不推荐日常使用）。
简单说：volatile 数组 ≠ volatile 元素。想让元素安全发布，得在元素层面下功夫，而不是指望数组引用上的 volatile “传染”过去。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
