Java中synchronized对象锁对不同实例不互斥的致命死穴-java教程-PHP中文网

synchronized对象锁只对同一实例互斥，不同实例不互斥是设计使然；若误用（如prototype多实例或集群部署），将导致超卖等并发问题，此时须改用单例锁对象或分布式锁。

java中synchronized对象锁对不同实例不互斥的致命死穴

Java中synchronized对象锁对不同实例不互斥，不是“bug”，而是设计使然；但若开发者误以为“加了synchronized就万事大吉”，它就成了高发并发问题的致命死穴。

对象锁只锁住this，不锁方法或类名

每个synchronized实例方法背后，等价于synchronized(this)。锁的是调用该方法的那个具体对象（即当前实例），不是方法签名，也不是类定义。所以：

同一个对象的多个synchronized方法——串行执行，互斥成立
两个不同对象（哪怕类型完全相同）的同名synchronized方法——可同时运行，毫无互斥
静态synchronized方法锁的是MyClass.class，和实例锁根本不在一个维度，彼此不干扰

典型踩坑场景：伪单例+多实例并发

比如库存扣减服务写成这样：

public class InventoryService {
    private int stock = 100;
    public synchronized void decrease() {
        if (stock > 0) {
            stock--;
        }
    }
}

如果每次请求都new一个InventoryService（如Spring中配置为prototype作用域），那100个请求就会创建100个实例——100个线程各自拿到自己的锁，全部冲进decrease()，结果stock可能被扣成负数。表面有synchronized，实际形同虚设。

真正需要互斥的是“库存”这个共享资源，而不是某个临时对象。

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

集群环境下更彻底失效

即使你在单机上正确用了对象锁（比如用单例+this锁），一旦部署到3台机器上：

每台机器有自己的JVM进程
每台机器上的InventoryService实例互不感知
synchronized只能拦住本机线程，拦不住其他机器的请求

这就是为什么大促时超卖频发——单机测试全过，上线集群就崩。synchronized是JVM内存级的锁，跨不了进程，更跨不了网络。

怎么绕开这个死穴

关键不是“怎么让synchronized管更多”，而是“认清它的边界，换对工具”：

同一JVM内多线程竞争？优先用synchronized或ReentrantLock，但必须确保锁对象是全局唯一的（如static final Object、单例bean）
跨JVM/集群竞争？必须升级为分布式锁（Redis + Lua脚本、ZooKeeper临时顺序节点、etcd等）
数据库强一致性场景？可用select for update（注意事务隔离级别和索引）或乐观锁（version字段）
避免把锁对象设为字符串字面量、this、或方法参数——它们极易导致锁粒度失控或意外共享

不复杂但容易忽略：锁的本质是“共识”，synchronized只在单个JVM里建立共识；要跨机器，就得靠所有节点都信任的第三方协调者。