synchronized修饰静态方法实现全局同步锁

synchronized修饰静态方法时，实际锁定的是当前类的Class对象（如MyClass.class），而非任何实例，因此所有线程调用该静态方法时必须串行执行，无论是否创建实例、使用哪个对象调用——这实现了真正的类级别全局同步；但它与synchronized实例方法互不干扰（后者锁this），也**无法保护实例变量**，仅适用于同步static字段等类共享状态；还需警惕多ClassLoader场景下Class对象不唯一导致的“伪全局”问题，以及临界区逻辑过重带来的性能隐患。

静态方法加 synchronized 等价于锁 Class 对象

直接说结论：synchronized 修饰静态方法时，锁的是当前类的 Class 对象（比如 MyClass.class），不是某个实例。这意味着所有线程调用该静态方法时，必须串行进入，哪怕它们操作的是不同实例、甚至压根没创建实例——只要调用这个静态方法，就竞争同一把锁。

本质等价于：

public static void doSomething() {
    synchronized (MyClass.class) {
        // 实际逻辑
    }
}

和普通 synchronized 实例方法的区别在哪

关键区别在锁粒度和作用域：

• synchronized 实例方法 → 锁的是 this（即调用该方法的对象实例），不同实例之间互不干扰
• synchronized 静态方法 → 锁的是 MyClass.class，整个类只有一个该锁，所有静态同步方法共享它
• 一个类里既有 synchronized 静态方法，又有 synchronized 实例方法，它们不互相阻塞：静态方法锁 Class，实例方法锁 this，是两把不同的锁

常见误用：以为静态 synchronized 能保护实例变量

这是高频误区。静态同步方法只保证方法体串行执行，但如果你在里面读写的是实例字段（比如 this.count++），而 this 是不同对象，那根本起不到“全局保护”效果——因为锁的是 Class，但数据分散在各个实例上。

正确做法是：要保护类级别的共享状态（如计数器、缓存、配置），必须用 static 字段，并确保所有访问都走同一把锁：

private static int globalCounter = 0;

public static synchronized void increment() {
    globalCounter++; // ✅ 安全：static 字段 + static 同步方法
}

public static void unsafeIncrement(MyObject obj) {
    obj.instanceCount++; // ❌ 危险：锁的是 Class，但改的是不同实例的字段
}

注意 JVM 层级和类加载器的影响

同一个类名，如果被不同 ClassLoader 加载（比如 Web 应用中多个模块隔离），会产生多个 Class 对象。此时 MyClass.class 在不同类加载器下是不同的对象，synchronized 静态方法也就无法跨加载器实现真正“全局”同步。

简单判断方式：

System.out.println(MyClass.class.getClassLoader());

如果日志里出现多个不同的 ClassLoader 实例，就得考虑用显式锁（如 ReentrantLock）配合类路径或命名空间做协调，而不是依赖 synchronized 静态方法。

另外，JVM 对静态同步方法有轻微优化（比如偏向锁不适用），但在高争用场景下，性能瓶颈往往不在锁本身，而在临界区逻辑是否过重——这点容易被忽略。

本篇关于《synchronized修饰静态方法实现全局同步锁》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！