synchronized修饰静态方法时锁的是当前类的Class对象，等价于synchronized(MyClass.class)，所有线程串行执行，与实例无关；而实例方法锁this，二者互不干扰。
静态方法加 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 对静态同步方法有轻微优化（比如偏向锁不适用），但在高争用场景下，性能瓶颈往往不在锁本身，而在临界区逻辑是否过重——这点容易被忽略。
