Java中static类变量可见性问题源于JMM下工作内存与主内存同步延迟；可用volatile保证基础可见性、原子类解决复合操作原子性、同步机制处理复杂逻辑、ThreadLocal实现线程独占副本。
Java 中 static 类变量的可见性问题，本质是线程间无法及时感知彼此对共享变量的修改。这不是“能不能看到”的问题，而是 JVM 内存模型（JMM）下工作内存与主内存同步延迟导致的——一个线程改了值，另一个线程还在用自己缓存的老副本。
用 volatile 保证基础可见性
当 static 变量仅需被多线程读写、且操作本身不要求原子性（比如开关标志、初始化完成状态），volatile 是最轻量、最直接的解法：
- 它强制每次读都从主内存取最新值，每次写都立即刷回主内存
- 还能禁止编译器和处理器对该变量的指令重排序，保障执行顺序
- 例如：public static volatile boolean initialized = false;，主线程设为 true 后，子线程 while(!initialized) 能立刻退出
注意：volatile 不解决 count++ 这类复合操作的原子性，只保可见性。
用原子类替代基础类型变量
如果 static 变量要参与计数、累加、条件更新等操作，直接用 AtomicInteger、AtomicLong、AtomicBoolean 等：
立即学习“Java免费学习笔记（深入）”；
- 它们内部基于 CAS（Compare-and-Swap）实现，既保证原子性，又天然具备 volatile 的可见性语义
- 比 synchronized 更高效，无锁，适合高并发读写场景
- 例如：public static final AtomicInteger requestCount = new AtomicInteger(0);，调用 incrementAndGet() 即可安全递增
用同步机制控制读写边界
当逻辑复杂（如“检查-再更新”）、或涉及多个变量协同变更时，必须引入显式同步：
- 优先使用专用静态锁对象：private static final Object LOCK = new Object();，避免锁住 Counter.class 影响其他无关静态方法
- 只包裹真正需要保护的代码段，比如仅同步赋值或状态切换部分，而非整个方法体
- 若需尝试获取、超时控制或响应中断，ReentrantLock 比 synchronized 更灵活
按需隔离：ThreadLocal 不用于共享，而用于独占
如果每个线程都需要一份独立副本（如 SimpleDateFormat、数据库连接、上下文参数），别共享 static 变量，改用 ThreadLocal：
- 声明为 private static final ThreadLocal
formatter = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd")); - 在线程池环境中务必在使用后调用 formatter.remove()，防止内存泄漏
- 它不解决“共享可见”，而是绕开共享——每个线程自管自用，自然无可见性冲突
