Java库存扣减超卖与死锁本质是并发控制不足，需数据库事务+合理加锁+避免长事务三者协同；用SELECT FOR UPDATE行级锁（须走主键/唯一索引）、固定ID升序加锁、拆分事务、设置锁超时、乐观锁+版本号校验、数据库CHECK约束兜底。
Java 中库存扣减的超卖和死锁问题，本质是并发控制没做好。核心思路是：用数据库事务 + 合理加锁 + 避免长事务，三者缺一不可。
用 SELECT FOR UPDATE 实现行级悲观锁
超卖的根本原因是多个线程同时读到“还有库存”，然后都去扣减。解决办法是在读库存时就加锁，确保后续更新串行执行。
- SQL 必须走主键或唯一索引（如 SELECT stock FROM item WHERE id = ? FOR UPDATE），否则可能升级为表锁，引发大面积阻塞
- 事务必须开启且未提交，否则锁会立即释放；Spring 中建议用 @Transactional 包裹整个扣减逻辑
- 避免在 FOR UPDATE 查询后做耗时操作（如远程调用、复杂计算），否则锁持有时间过长，增加死锁概率
按固定顺序加锁，预防死锁
死锁常发生在多个事务以不同顺序更新多行数据。比如事务 A 先锁商品 1001 再锁 1002，事务 B 反过来，就容易卡住。
- 所有扣减操作统一按商品 ID 升序处理：若一次扣多个 SKU，先 Arrays.sort(ids) 再逐个 SELECT FOR UPDATE
- 不要在同一个事务里混合操作不同业务表（如扣库存 + 更新订单 + 发消息），尽量拆成原子步骤，或确保跨表加锁顺序一致
- MySQL 的 innodb_lock_wait_timeout 默认 50 秒，可适当调低（如 5 秒），让死锁更快暴露并回滚重试
结合版本号或 CAS 实现乐观锁（适合低冲突场景）
如果并发量不大、超卖容忍度极低（如秒杀尾单），可用乐观锁兜底，但不能单独依赖它防超卖。
立即学习“Java免费学习笔记（深入）”；
- 表加 version 字段，UPDATE 语句带上条件：UPDATE item SET stock = stock - 1, version = version + 1 WHERE id = ? AND stock >= 1 AND version = ?
- 检查 executeUpdate() 返回值是否为 1；为 0 表示更新失败（库存不足或版本不匹配），需主动抛异常或重试
- 注意：乐观锁不防超卖，只是事后校验；必须配合数据库约束（如 stock >= 0 的 CHECK 或触发器）做最终兜底
终极保障：数据库层面加约束
代码再严谨，也挡不住绕过应用直连 DB 的操作。库存字段必须有强一致性约束。
- 添加检查约束：ALTER TABLE item ADD CONSTRAINT chk_stock CHECK (stock >= 0);（MySQL 8.0.16+ 支持）
- 或用 BEFORE UPDATE 触发器拦截负库存更新
- 扣减 SQL 必须带条件 WHERE stock >= ?（如扣 1 件就写 WHERE stock >= 1），让 UPDATE 自动失效而非靠 Java 判断
