Java中static变量无并发保护，需用原子类、正确加锁、volatile慎用、线程隔离或不可变设计来解决竞争问题。
Java 中 static 变量本身不提供任何并发保护，所有线程共享同一份内存空间，一旦多个线程同时读写（尤其是含“读-改-写”逻辑的操作），就会出现数据丢失、结果偏小、状态不一致等典型竞争问题。
优先用原子类替代基础类型
对计数器、开关标志、版本号等简单数值操作，直接替换为 java.util.concurrent.atomic 包中的类型：
-
计数场景：用
private static AtomicInteger counter = new AtomicInteger(0);，调用counter.incrementAndGet()或compareAndSet() -
布尔状态：用
AtomicBoolean替代volatile boolean，尤其当需要“先检查再设置”时 -
对象引用：用
AtomicReference<T>管理可变对象，避免锁但保证引用更新的原子性
原子类底层基于 CAS 指令，无阻塞、高性能，且天然满足可见性与原子性要求。
必须同步时，锁对象要选对
静态变量属于类级别，锁必须作用于全局唯一的对象，否则形同虚设：
立即学习“Java免费学习笔记（深入）”；
-
推荐方式：用
synchronized (MyClass.class) { ... }或声明public static synchronized void method() { ... } -
禁止做法：用
this、new Object()或实例字段作锁——它们无法跨线程唯一标识静态域 -
细粒度优化：若操作涉及多个独立字段（如缓存中不同 key 的值），优先用
ConcurrentHashMap；若需复合更新（如 total 和 count 联动），仍须统一锁住整个逻辑块
volatile 不是万能解，只适用于特定模式
volatile 能解决可见性和重排序问题，但不能保证复合操作原子性：
-
安全用法：单次写入后只读的配置项（
public static final String URL = "...";）、运行时开关（private static volatile boolean isRunning = true;） -
危险用法：任何含计算的赋值，如
count++、list.add(x)、map.put(k, v)—— 即使加了volatile也无效 - 配合使用：常作为“初始化完成”标记，配合 double-checked locking 或与原子类组合使用
重新审视设计：是否真需要共享？
很多并发问题根源不在同步机制，而在过度依赖全局状态：
-
线程内隔离：用
ThreadLocal<Integer> localCount = ThreadLocal.withInitial(() -> 0);，彻底消除竞争，适合上下文 ID、格式化器、临时缓存等场景 - 实例化替代：将静态变量改为 Spring 管理的单例 Bean 的实例字段，通过构造注入或方法参数传递数据，更易测试和扩展
-
不可变优先：配置类尽量声明为
public static final，对象内部字段也设为final，从源头杜绝修改可能
不复杂但容易忽略。关键不是“怎么加锁”，而是先判断这个变量是否真的需要被多线程共同写入。
