synchronized能防单机超卖，因其将查库存、判断、扣减三步变为原子操作，强制线程排队执行，使后继线程读到已更新的库存；但它仅作用于单JVM，多节点部署时失效，且与@Transactional存在生命周期错位风险。
synchronized 防止超卖，核心是把“查库存—判断是否充足—扣减库存”这三步变成一个不可分割的原子操作，让多个线程无法同时执行这一整段逻辑。
为什么加 synchronized 能起作用
超卖本质是多个线程读到同一份旧库存（比如都是 1），各自扣减后都写回 0，导致实际卖出 2 件。synchronized 强制这些线程排队执行——只有拿到锁的线程能进入临界区，其他线程必须等待。这样，第二个线程进来时，看到的已是第一个线程更新后的库存（比如已变为 0），自然就拦住了后续非法下单。
关键细节：锁的范围和对象必须合理
不能只在方法签名上加 synchronized，尤其不能直接加在带 @Transactional 的 Service 方法上。原因有二：
- 如果锁的是实例方法（
public synchronized void method()），而 Spring 默认是单例 Bean，那所有请求共用同一个锁对象，看似可行；但若服务被部署多实例，该锁完全失效——它只管本机线程，不管其他服务器上的请求。 - 更严重的是事务与锁的生命周期错位：synchronized 在方法结束就释放锁，但 @Transactional 的事务可能还在提交中。下一个线程抢到锁后，查库存时数据库还没刷盘，仍读到旧值，照样超卖。
推荐写法：同步块 + 明确锁对象 + 手动事务控制
把锁粒度收窄到真正需要保护的代码段，并确保锁覆盖整个数据库读写流程：
立即学习“Java免费学习笔记（深入）”；
- 使用私有 final 对象作为锁，避免锁住 this 或 class 导致意外竞争；
- 把查询、判断、更新、生成订单等关键操作包进
synchronized(lockObj)块内； - 事务由编程式方式控制（如
TransactionTemplate），确保事务提交完成后再退出同步块； - 避免在 synchronized 块里做耗时操作（如远程调用、大文件 IO），否则会严重拖慢吞吐量。
它适合什么场景
synchronized 是单机环境下的轻量方案，适合：
- 系统未做集群部署，或集群流量可由网关路由到同一台机器；
- 并发量不高（例如每秒几十到几百请求）；
- 对响应延迟不敏感，能接受一定排队等待。
一旦上了多节点、高并发、低延时要求的生产环境，synchronized 就力不从心了，必须升级为 Redis 分布式锁或数据库行锁等跨进程方案。
