静态变量在多线程下天然共享，易引发可见性缺失、指令重排和复合操作非原子三类问题；volatile仅保证可见性和禁止重排，适用于状态标志等单次写场景，不保证原子性；原子操作（如AtomicInteger）通过volatile+ CAS同时保障可见性与原子性，适合计数类更新；复杂多步逻辑则需synchronized加锁。
静态变量在多线程环境下天然共享，一旦被多个线程并发读写，就容易出问题。volatile 和原子操作（如 AtomicInteger）都能缓解风险，但作用不同、适用场景也不同。
静态变量为什么容易出问题
static 变量属于类，所有线程共用同一份内存。如果没加同步措施，会出现三类典型问题：
- 可见性缺失：线程 A 修改了 static 变量，线程 B 可能长时间读到旧值（因 CPU 缓存未及时刷新）；
- 指令重排干扰：JVM 或 CPU 可能调整代码执行顺序，导致初始化未完成就被其他线程使用（比如单例双重检查锁中 instance = new Singleton() 被拆解）；
- 复合操作非原子：像 count++ 这种“读-改-写”三步操作，即使变量是 static，多个线程同时执行也会丢失更新。
volatile 能解决什么，不能解决什么
volatile 修饰 static 变量后，能强制每次读都从主内存取，每次写都立即刷回主内存，并禁止相关指令重排。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 适合场景：状态标志位（如 static volatile boolean running = false）、单次写入的配置项（如 static volatile String configPath）；
- 不适合场景：任何依赖当前值的更新，比如 static volatile int counter; counter++ 或 counter += 1 —— 这些仍是线程不安全的；
- 关键限制：它不提供互斥，不阻止多个线程同时进入临界区，只保证“看到的是最新值”，不保证“修改不冲突”。
原子操作更适合计数类更新
对于需要增减、比较再设置等操作的 static 变量，推荐直接用原子类替代普通变量：
立即学习“Java免费学习笔记（深入）”；
- 把 static int count 换成 static AtomicInteger count = new AtomicInteger(0)；
- 用 count.incrementAndGet() 替代 count++，用 count.compareAndSet(expected, updated) 实现条件更新；
- 底层靠 volatile + CAS（Compare-And-Swap）实现：既保证可见性，又保证操作的原子性，比 synchronized 更轻量。
什么时候该用 synchronized
当操作涉及多个变量、或逻辑跨多步（比如先判断再更新、读取 A 后更新 B），仅靠 volatile 或原子类不够时，就得上锁：
- 例如：if (staticCounter > threshold) { staticCounter = 0; resetOtherState(); } —— 这个 if + 赋值 + 方法调用必须整体原子；
- 用 synchronized (SomeClass.class) { ... } 或静态同步方法，确保同一时刻只有一个线程执行这段逻辑；
- 注意：synchronized 锁的是类对象（Class 对象），对所有线程生效，正好匹配 static 变量的作用域。
