静态类变量线程不安全，需通过synchronized锁、原子类、volatile（仅限简单赋值）、threadlocal或改用实例变量等方式保障线程安全。
静态类变量本质上是所有实例共享的，多线程同时读写时极易引发数据竞争，导致结果不可预测。防止不安全的核心思路是：**控制并发访问，确保操作的原子性、可见性和有序性**。以下是几种实用、可落地的解决方式：
用 synchronized 保证临界区互斥
对访问静态变量的代码块或方法加锁，是最直接的方式。锁对象建议使用类的 Class 对象（如 MyClass.class），避免用 this 或任意实例对象，确保锁的全局唯一性。
- 修饰静态方法：自动以当前类的 Class 对象为锁，适合整个方法逻辑都需要同步的场景
- 同步代码块：粒度更细，只锁真正操作静态变量的部分，减少性能影响
- 示例：synchronized (Counter.class) { count++; } 比同步整个方法更高效
用 java.util.concurrent.atomic 包下的原子类
对于简单的数值增减、布尔状态切换等操作，优先选用 AtomicInteger、AtomicLong、AtomicBoolean 等。它们底层基于 CAS（Compare-And-Swap）指令，无锁且高效，天然支持可见性和原子性。
- 无需手动加锁，代码简洁，性能通常优于 synchronized
- 注意：仅适用于单个变量的原子操作；多个变量协同更新时，CAS 无法保证整体原子性，仍需锁或其他机制
- 示例：private static AtomicInteger counter = new AtomicInteger(0); 后续调用 counter.incrementAndGet() 即可线程安全
用 volatile 修饰 + 无锁编程约束
volatile 能保证变量的可见性和禁止指令重排序，但不保证复合操作的原子性（如 i++）。因此它只适用于“纯赋值”或“状态标志”类场景。
- 适用：开关标志（如 private static volatile boolean running = true;）、单次写入后只读的配置项
- 不适用：count++、list.add() 等含读-改-写三步的操作
- 常与原子类或锁配合使用，比如用 volatile 标记某个初始化完成的状态，再配合 double-checked locking
避免共享 —— 改用 ThreadLocal 或实例变量
如果静态变量只是用来暂存线程内计算中间结果，考虑是否真的需要跨线程共享。很多时候，问题根源在于设计上过度依赖全局状态。
- ThreadLocal 为每个线程提供独立副本，彻底消除竞争，适合存储线程上下文信息（如用户ID、事务ID、格式化器）
- 若业务逻辑允许，将静态变量改为实例变量，由 Spring 等容器管理单例 Bean 的生命周期，再通过方法参数或构造注入传递数据
- 关键判断：这个变量是否必须被所有线程共同读写？如果不是，解耦比加锁更治本
