Java静态变量线程不安全，须用Class对象作锁确保全局唯一；粗粒度锁适用于整体操作，细粒度锁提升并发性能；volatile和原子类适用于简单操作，复合逻辑仍需同步；static块仅保初始化安全，可变对象后续操作仍需同步保护。
Java静态变量本身不带线程安全保证，多个线程并发读写时极易触发竞争条件——比如计数器错乱、状态不一致、甚至逻辑崩溃。关键不在“要不要加锁”，而在于“锁什么、怎么锁才既安全又高效”。
静态变量必须用类对象做锁根
静态变量属于类级别，所有实例共享同一份数据。因此同步必须基于该类的 Class 对象，确保锁的全局唯一性：
- ✅ 正确：synchronized (MyClass.class) { field.set(null, value); } —— Class 实例由 JVM 保证单例，天然适配静态域
- ❌ 错误：synchronized (this) 或 new Object() —— 锁对象不统一，完全起不到互斥作用
- ⚠️ 注意：若反射同时修改多个静态字段（如配置项 A 和 B），必须把全部读写操作包在同一把 Class 锁内，否则可能产生中间态不一致
粗粒度 vs 细粒度：选对锁范围才能兼顾安全与性能
锁粒度决定并发吞吐量。对静态变量而言，粗粒度锁简单但易成瓶颈；细粒度锁灵活但需谨慎设计：
- 粗粒度典型场景：整个工具类的静态缓存刷新操作，用 synchronized static 方法或 synchronized (Xxx.class) 包裹全部逻辑
- 细粒度适用情形：静态 Map 存储多类配置，可为每个 key 单独加锁（如 ConcurrentHashMap），或按业务维度拆分锁对象（如用 String.intern() 获取唯一锁对象）
- 避免误区：不要为每个静态字段定义独立的 private static final Object LOCK = new Object() —— 若字段间存在依赖关系（如 total 和 count 同步更新），仍需统一锁
比锁更轻量的选择：原子类与 volatile 的适用边界
不是所有静态变量都得上重量级锁。根据操作类型选择更合适的机制：
立即学习“Java免费学习笔记（深入）”；
- 单纯赋值或标志位切换（如开关 flag、版本号）：用 static volatile boolean enabled 或 static volatile int version，配合 happens-before 保证可见性
- 自增/自减/比较并设置等简单数值操作：优先用 AtomicInteger、AtomicLong 等，底层基于 CAS，无阻塞且高效
- 复合逻辑（如“先查再改”或涉及多个字段联动）：volatile 和原子类无法保证原子性，必须回归 synchronized 或 ReentrantLock
静态块初始化 ≠ 线程安全终点
static {} 块在类加载时执行一次，JVM 保证其线程安全，但这只覆盖“实例创建”阶段：
- INSTANCE 是 final 的，但它的内部状态（如 static Map cache）仍可被并发修改，需额外同步
- 若静态变量指向可变对象（如 ArrayList、HashMap），即使初始化完成，后续 add/remove 操作仍需保护
- 反射或序列化可能绕过构造逻辑，真正安全的单例建议结合静态内部类 + 构造校验 + readResolve
