类变量因被所有线程共享且复合操作非原子，天然线程不安全；必须通过同步方法、同步代码块或避免共享等方式保障一致性。
Java 类变量（即 static 成员变量）被所有实例共享，一旦多个线程并发读写它，就极易出现数据错乱——这不是偶发 bug，而是必然结果。关键不在于“会不会出问题”，而在于“如何用对的方式守住一致性”。
类变量为何天生不安全
类变量存储在方法区（JDK 8+ 是元空间），由所有线程共享。而像 count++ 这样的操作实际包含三步：读取当前值 → 加 1 → 写回内存。这三步不是原子的，线程可能在任意一步被抢占。比如两个线程同时读到 count = 5，各自加 1 后都写回 6，结果本该是 7 却仍是 6。
- 只有读操作：通常安全（如配置常量、只读标志位）
- 有写操作：必须同步，否则结果不可预测
- 复合操作（如
if (count > 0) count--;）：即使用了volatile也无法保证安全，因为“判断+修改”不是原子动作
静态同步方法：最简明的锁粒度
给静态方法加 synchronized，等价于用当前类的 Class 对象作锁。所有线程竞争同一把锁，天然保护整个方法体内的共享逻辑。
public class Counter {
private static int count = 0;
public static synchronized void increment() {
count++; // 原子执行
}
public static synchronized int getCount() {
return count;
}
}
- 优点：写法简洁，语义清晰，适合逻辑简单、调用不频繁的场景
- 注意：锁的是
Counter.class，不是某个实例；哪怕创建 100 个 Counter 对象，也只有一把锁 - 缺点：整个方法串行化，若方法体内含耗时非共享操作（如日志、IO），会拖慢整体吞吐
同步代码块 + 静态锁对象：精准控制临界区
当方法里只有部分代码需要保护，或需与其他逻辑共用锁时，用显式锁对象更灵活。推荐声明为 private static final Object，避免被外部误用。
立即学习“Java免费学习笔记（深入）”；
public class Counter {
private static int count = 0;
private static final Object LOCK = new Object();
public static void increment() {
// 其他非共享逻辑（可并发）
synchronized (LOCK) {
count++; // 仅此处受保护
}
// 其他非共享逻辑（可并发）
}
}
- 优势：锁范围最小化，提升并发效率
- 关键：锁对象必须是 static 的，且不可被修改（
final更稳妥） - 对比：不用
this或实例引用——它们对静态方法无效，也不起作用
替代方案：从源头规避共享
同步是兜底手段，优先考虑是否真需要共享类变量：
- 能用局部变量代替？例如循环计数、临时缓存——每个线程栈独立，零成本安全
- 能否让每个线程持有独立对象？如
ThreadLocal<SimpleDateFormat>或池化实例——避免争抢同一资源 - 是否可用原子类？
AtomicInteger等基于 CAS，无锁且高效，适合简单计数、状态切换 - 是否只需可见性？
volatile能保证最新值被看到，但不能解决count++这类复合操作
真正可靠的线程安全，不是靠堆砌同步块，而是先问一句：“这个变量，非得被所有线程一起改吗？” 想清楚这点，一半问题已经消解了。
