Java静态变量的线程可见性问题本质是JMM与CPU缓存导致一个线程修改后其他线程读不到最新值；volatile强制读写主内存并禁止重排，适用于状态标志等单次读写场景，但不保证i++等复合操作的原子性。
Java 中静态变量的线程可见性问题，本质是：一个线程修改了静态变量的值，其他线程可能读不到最新值，仍看到旧值（甚至永远卡在旧值）。这不是代码写错，而是 JVM 内存模型（JMM）和 CPU 缓存机制共同导致的底层行为。
这个问题在静态变量上尤其典型——因为它是类级别共享的，所有线程都通过 Class 对象访问同一份数据，但各自读取的是自己工作内存里的副本，而非实时同步的主内存值。
为什么静态变量容易暴露可见性问题？
- 静态变量存储在方法区（元空间），被所有线程共享；
- 每个线程有自己的工作内存（对应 CPU 缓存），首次读取时会把静态变量值拷贝一份；
- 若没有明确同步机制，JVM 不保证该副本何时更新——线程可能一直用缓存值，哪怕主内存早已被其他线程改写。
例如：
public class FlagHolder {
static boolean ready = false;
public static void main(String[] args) throws InterruptedException {
Thread t1 = new Thread(() -> {
while (!ready) { // 可能永远循环：t1 看不到 t2 的修改
Thread.yield();
}
System.out.println("done");
});
Thread t2 = new Thread(() -> {
try { Thread.sleep(100); } catch (InterruptedException e) {}
ready = true; // t2 修改了，但 t1 不一定“看见”
System.out.println("flag set to true");
});
t1.start(); t2.start();
t1.join();
}
}运行结果常常是卡死——t1 永远不退出循环，因为它读的一直是自己工作内存中 ready = false 的副本。
立即学习“Java免费学习笔记（深入）”；
真正起作用的解决方式
-
volatile是最轻量、最直接的方案
它强制每次读都从主内存加载，每次写都立即刷回主内存，并禁止相关指令重排序：static volatile boolean ready = false;
✅ 适用于“仅需保证可见性 + 无复合操作”的场景（如开关标志、状态信号）。
-
synchronized或Lock不仅保可见性，还保原子性与有序性
进入同步块前，线程会清空工作内存中相关变量的缓存；退出时，将修改强制写回主内存：static boolean ready = false; static final Object lock = new Object(); // 写 synchronized(lock) { ready = true; } // 读 synchronized(lock) { if (ready) { ... } }✅ 适合需要读-改-写连贯操作的场景（比如
count++）。 -
AtomicBoolean/AtomicInteger等原子类
底层基于volatile+ CAS，既可见又原子：static AtomicBoolean ready = new AtomicBoolean(false); // 使用 ready.set(true) 和 ready.get()，安全可靠
✅ 推荐用于计数、状态切换等简单共享状态。
-
避免共享可变静态变量（根本性规避）
- 改用
ThreadLocal为每个线程提供独立副本； - 将逻辑封装为无状态工具类，参数传入、结果返回；
- 静态变量只初始化一次，之后只读（
static final）。
- 改用
哪些做法不能解决问题？
- 单纯加
static或final（final只对构造完成那一刻的可见性有保障）； - 仅用
synchronized包裹写操作，但读操作没同步——读线程仍可能看到过期值； -
volatile不能解决i++这类非原子操作（它只保单次读/写可见，不保“读+改+写”整体原子）。
不复杂但容易忽略。
