synchronized对象锁只对同一实例互斥，不同实例不互斥是设计使然；若误用（如prototype多实例或集群部署），将导致超卖等并发问题，此时须改用单例锁对象或分布式锁。
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免费学习笔记（深入）”；
真正需要互斥的是“库存”这个共享资源，而不是某个临时对象。
集群环境下更彻底失效
即使你在单机上正确用了对象锁（比如用单例+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里建立共识；要跨机器，就得靠所有节点都信任的第三方协调者。
