Java 中对象锁能否保护静态成员变量的安全

在 Ja va 并发编程里，有个老生常谈的问题：对象锁能不能保护静态成员变量？答案很明确——不能。原因在于对象锁锁的是实例，而静态成员属于类。换句话说，你用 synchronized 修饰一个非静态方法，或者写一段 synchronized(this) 代码块，它锁住的是当前对象本身，和静态变量根本不在同一个维度上。结果就是：多个线程各自拿着自己实例的锁去修改同一个静态变量，毫无互斥可言，形同虚设。

对象锁只保护实例数据，不作用于静态成员

对象锁（即 synchronized 修饰非静态方法或 synchronized(this)）锁定的是当前实例（this），而静态成员变量属于类本身，被所有实例共享，与任何具体对象无关。因此，即使多个线程操作不同实例，只要它们修改同一个静态变量，对象锁完全无法形成互斥——每个线程拿到的是各自对象的锁，彼此独立。

类锁才是保护静态变量的正确选择

静态变量必须由类级别的锁来协调访问，即使用该类的 Class 对象 作为锁载体：

• 静态同步方法：public static synchronized void update() { ... } → 自动以 MyClass.class 为锁
• 同步代码块：synchronized (MyClass.class) { count++; } → 显式、可控、推荐
• 错误示例：synchronized (this) 或 new Object() → 锁对象不统一，形同虚设

对象锁和类锁互不干扰，但不可混用

一个类可以同时存在对象锁方法和类锁方法，它们使用两把完全不同的锁：

• 线程 A 调用 obj1.doInstanceJob()（对象锁）不影响线程 B 调用 MyClass.doStaticJob()（类锁）
• 但如果对象锁方法内部读写静态变量，仍需额外加类锁，否则静态部分依然不安全

（学习提示：掌握锁的粒度区别是并发编程的基础，建议通过实际代码验证。）

更轻量的替代方案视场景而定

并非所有静态变量都必须上重量级锁：

• volatile：适用于单次写、多次读的布尔开关或状态标记，保障可见性，但不保证复合操作原子性
• AtomicInteger / AtomicReference：适合自增、CAS 比较更新等简单原子操作，无阻塞、高性能
• ConcurrentHashMap 等并发容器：替代静态 Map，避免手动同步
• ThreadLocal：当每个线程只需自己副本时，彻底规避共享，而非保护共享