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

对象锁不能保护静态成员，因其锁定的是实例而非类；静态变量需类锁（如static synchronized或synchronized(MyClass.class)）；volatile、AtomicInteger等可作轻量替代。

不能。

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

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

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

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

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

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

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

立即学习“Java免费学习笔记（深入）”；

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

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

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

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