volatile修饰数组时，真正被保护的仅是数组引用本身，而非数组元素；即其他线程能及时看到数组是否被重新赋值，但对array[i]的读写不具可见性与原子性。
volatile 能解决数组元素的可见性问题，但效果非常有限，用错反而引入性能陷阱和逻辑漏洞。它只对单个数组引用本身起作用，对数组内部元素不自动生效；即使给数组加了 volatile，每个 array[i] 仍不是 volatile 的。
volatile 修饰数组时，真正被保护的是什么？
当声明 volatile int[] array = new int[10]; 时，volatile 仅作用于 array 这个引用变量，即：其他线程能及时看到 array 是否被重新赋值（比如 array = new int[20]），但对 array[0]、array[1] 等元素的读写，编译器和 CPU 不做额外同步保证。
换句话说：
- array = new int[5]; —— 这个赋值操作对其他线程可见（因引用是 volatile）
- array[0] = 1; —— 这个写入操作不保证立即刷到主内存，也不强制其他线程刷新本地缓存中的 array[0]
- int x = array[0]; —— 这个读取可能命中旧值，除非 array[0] 本身也被单独声明为 volatile（Java 不支持 volatile int[] 的元素级修饰）
为什么 array[0] 和 array[8] 分开写反而更快？—— 缓存行伪共享才是关键
你看到的“两个线程分别写 array[0] 和 array[8] 比写 array[0] 和 array[1] 快”，根本原因不是 volatile，而是 CPU 缓存一致性协议（如 MESI）下的 伪共享（False Sharing）。
典型现象：
- array[0] 和 array[1] 很可能落在同一缓存行（通常 64 字节）中
- 线程 A 修改 array[0] → 使该缓存行进入 Modified 状态 → 强制使线程 B 缓存中同缓存行失效
- 线程 B 随后写 array[1] → 触发缓存行重新加载与写回 → 频繁总线同步，性能骤降
- 而 array[0] 和 array[8] 若相距足够远（如 long 类型，8 字节 × 8 = 64 字节），大概率分属不同缓存行 → 避免干扰
volatile 在这里只是“暴露”了伪共享问题，并不能缓解它；加 volatile 反而可能加剧缓存行争用，因为每次写都带内存屏障语义。
哪些场景下 volatile 数组能真正起作用？
只有极少数明确依赖 数组引用变更可见性 的模式才适用，例如：
- 双缓冲切换：volatile int[] bufA = ..., bufB = ...；某线程原子切换引用 buf = bufB；其他线程立刻看到新 buf
- 状态标志数组引用：volatile boolean[] flags = null；初始化后 flags = new boolean[10]；后续线程检查 flags != null 再安全访问
- 配合 Unsafe 或 VarHandle 做手动内存控制时，volatile 引用可作为同步锚点
但注意：一旦涉及对数组内容的读-改-写（如 count++、list.add() 模拟），volatile 数组完全无法保障正确性，必须用 AtomicIntegerArray、synchronized 或 java.util.concurrent 工具类。
替代 volatile 数组的更可靠方案
若目标是让数组元素具备线程安全的可见性与原子性，应直接选用专用并发结构：
- AtomicIntegerArray：提供 get/set/compareAndSet/addAndGet 等原子操作，每个元素独立受控
- AtomicLongArray：适用于 long 类型计数或状态位
- VarHandle（JDK9+）：可为任意数组类型构造强语义的 volatile 访问（如 ArrayHandles.arrayElementHandle(int[].class).getVolatile(array, i)）
- 对小规模固定数组，用 synchronized(this) 或 ReentrantLock 保护整个读写段，逻辑清晰不易出错
这些方案在底层通过内存屏障 + CAS 或锁机制，真正实现了元素级的可见性与原子性，而非依赖 volatile 的间接语义。
