Java单线程写读数组是否线程安全及自定义环形缓冲竞态问题

问题1：Java数组单线程写单线程读场景是否线程安全？ #

不是线程安全的，核心原因有两点：

• 可见性无法保证：普通Java数组的元素读写没有volatile语义，JMM不保证写线程对数组元素的修改能立刻被读线程感知，读线程可能长时间读到旧值，甚至永远读不到更新。
  注意：即便是你把数组引用声明为volatile，也只能保证数组引用本身的可见性，无法保证数组内部元素的读写有volatile语义。如果需要数组元素的原子读写+可见性保证，应该使用java.util.concurrent.atomic包下的原子数组类（比如AtomicReferenceArray、AtomicIntegerArray等）。
• 对于long/double类型的数组元素，32位JVM下甚至连写入的原子性都无法保证，读线程可能读到高32位和低32位拼接的异常值。

问题2：单生产者单消费者场景未复现竞态的原因&复现方法 #

未复现的核心原因 #

你的测试没有触发问题，本质是现有实现和测试场景碰巧掩盖了并发风险，不代表代码本身线程安全：

1. AtomicInteger的内存屏障附带同步效果：你用AtomicInteger类型的size做空满判断，AtomicInteger的get()是volatile读、getAndIncrement()/getAndDecrement()是volatile写，这两个操作都会触发JMM的内存屏障：
   • 生产者执行size.getAndIncrement()时，会把之前对buffer、writeIndex的修改强制刷入主存
   • 消费者执行size.get()时，会强制让本地缓存失效，从主存拉取buffer、readIndex的最新值
     相当于你靠size的原子操作，顺带保证了其他变量的可见性，也阻止了指令重排。
2. x86架构的强内存模型特性：x86 CPU天然不允许写-写、读-读重排，普通写的可见性延迟极低，进一步降低了并发问题触发的概率。
3. 索引变量的访问隔离：单生产者单消费者场景下，writeIndex只有生产者修改、readIndex只有消费者修改，两个线程不会同时修改同一个索引变量，进一步减少了竞态触发的可能。

触发竞态的方法 #

你可以通过以下任意一种方式快速复现问题：

1. 修改空满判断逻辑，移除size的同步效果：把空满判断改成直接用readIndex和writeIndex计算，完全去掉size变量，这样就失去了AtomicInteger带来的内存屏障保护，很快就会出现可见性问题：

// 示例修改后的空满判断，去掉size变量
public boolean isEmpty() {
    return readIndex == writeIndex;
}
public boolean isFull() {
    return (writeIndex + 1) % capacity == readIndex;
}

这种场景下跑测试，大概率会出现消费者读到null、或者数据顺序错乱的问题。
2. 把size改成普通int变量：直接把private AtomicInteger size;改成private int size;，去掉原子类的内存屏障效果，跑几次测试就能触发check为false，甚至出现生产者、消费者死循环的情况。
3. 使用专业并发测试工具：用OpenJDK的jcstress并发测试框架跑你的原有代码，它会自动构造高压力的执行场景，比你手写循环测试的触发效率高几十倍，如果有条件在ARM架构的设备上运行，触发概率会更高。
4. 缩小缓冲区容量：把环形缓冲的容量从1000改成1，放大生产消费速度匹配的边界场景，也能提升问题触发概率。

内容的提问来源于stack exchange，提问作者Trần Văn Dem