真实业务场景死锁案例：电商订单处理

1. 业务场景介绍

场景：电商系统的订单确认流程，需要处理三个核心资源：

1. 订单锁：防止同一订单被重复处理
2. 库存锁：防止库存超卖
3. 支付锁：防止重复支付

2. 死锁发生的真实代码

2.1 订单处理服务

@ServicepublicclassOrderService{@AutowiredprivateRedissonClientredissonClient;@AutowiredprivateInventoryServiceinventoryService;@AutowiredprivatePaymentServicepaymentService;/** * 确认订单（路径1：先锁订单，再锁库存，最后锁支付） */publicvoidconfirmOrder(StringorderId,StringproductId,StringuserId){// 1. 锁定订单RLockorderLock=redissonClient.getLock("order:lock:"+orderId);orderLock.lock();// 线程A持有订单锁try{// 2. 锁定库存RLockinventoryLock=redissonClient.getLock("inventory:lock:"+productId);inventoryLock.lock();// 线程A持有库存锁try{// 3. 锁定支付RLockpaymentLock=redissonClient.getLock("payment:lock:"+userId);paymentLock.lock();// 线程A请求支付锁try{// 业务逻辑：确认订单、扣减库存、创建支付记录doConfirmOrder(orderId,productId,userId);}finally{paymentLock.unlock();}}finally{inventoryLock.unlock();}}finally{orderLock.unlock();}}/** * 快速确认订单（路径2：先锁支付，再锁库存，最后锁订单） */publicvoidquickConfirmOrder(StringorderId,StringproductId,StringuserId){// 1. 锁定支付（与confirmOrder顺序不同）RLockpaymentLock=redissonClient.getLock("payment:lock:"+userId);paymentLock.lock();// 线程B持有支付锁try{// 2. 锁定库存RLockinventoryLock=redissonClient.getLock("inventory:lock:"+productId);inventoryLock.lock();// 线程B持有库存锁try{// 3. 锁定订单（与confirmOrder顺序不同）RLockorderLock=redissonClient.getLock("order:lock:"+orderId);orderLock.lock();// 线程B请求订单锁try{// 业务逻辑：快速确认订单、扣减库存、创建支付记录doQuickConfirmOrder(orderId,productId,userId);}finally{orderLock.unlock();}}finally{inventoryLock.unlock();}}finally{paymentLock.unlock();}}// 其他方法...}

3. 死锁发生的详细流程

3.1 前置条件

• 线程A：处理用户请求，调用confirmOrder()方法
• 线程B：处理同一用户的另一个请求，调用quickConfirmOrder()方法
• 共享资源：
  • 订单ID：order_123
  • 商品ID：product_456
  • 用户ID：user_789

3.2 执行时序图

3.3 死锁的具体表现

4. 死锁的根本原因

4.1 死锁的四个必要条件都满足

4.2 业务设计缺陷

1. 锁获取顺序不一致：confirmOrder()和quickConfirmOrder()两个方法的锁获取顺序不同
2. 嵌套锁使用不当：同时使用多个嵌套锁，增加了死锁风险
3. 缺乏超时机制：使用lock()而非tryLock()，导致无限等待
4. 锁粒度不够细：支付锁按用户ID加锁，可能导致同一用户的所有请求串行化

5. 解决方案：如何避免死锁

5.1 方案1：统一锁获取顺序（推荐）

核心原则：所有线程必须按照相同的顺序获取锁

5.1.1 优化后的代码

@ServicepublicclassOrderService{// 定义全局锁顺序：订单锁 → 库存锁 → 支付锁privatestaticfinalList<String>LOCK_ORDER=Arrays.asList("order:lock:","inventory:lock:","payment:lock:");/** * 确认订单（统一锁顺序） */publicvoidconfirmOrder(StringorderId,StringproductId,StringuserId){// 1. 收集所有需要的锁List<String>lockKeys=Arrays.asList("order:lock:"+orderId,"inventory:lock:"+productId,"payment:lock:"+userId);// 2. 按统一顺序排序锁List<String>sortedLockKeys=sortLocks(lockKeys);// 3. 按顺序获取锁List<RLock>acquiredLocks=newArrayList<>();try{for(StringlockKey:sortedLockKeys){RLocklock=redissonClient.getLock(lockKey);lock.lock();acquiredLocks.add(lock);}// 4. 执行业务逻辑doConfirmOrder(orderId,productId,userId);}finally{// 5. 按相反顺序释放锁Collections.reverse(acquiredLocks);for(RLocklock:acquiredLocks){lock.unlock();}}}/** * 快速确认订单（同样的锁顺序） */publicvoidquickConfirmOrder(StringorderId,StringproductId,StringuserId){// 使用完全相同的锁顺序，避免死锁confirmOrder(orderId,productId,userId);}/** * 按预定义顺序排序锁 */privateList<String>sortLocks(List<String>lockKeys){returnlockKeys.stream().sorted(Comparator.comparing(key->{// 根据锁前缀获取排序值for(inti=0;i<LOCK_ORDER.size();i++){if(key.startsWith(LOCK_ORDER.get(i))){returni;}}returnInteger.MAX_VALUE;})).collect(Collectors.toList());}}

5.2 方案2：使用tryLock替代lock

核心原则：避免无限等待，设置合理的超时时间

publicvoidconfirmOrder(StringorderId,StringproductId,StringuserId){RLockorderLock=redissonClient.getLock("order:lock:"+orderId);RLockinventoryLock=redissonClient.getLock("inventory:lock:"+productId);RLockpaymentLock=redissonClient.getLock("payment:lock:"+userId);try{// 尝试获取订单锁，最多等待3秒if(!orderLock.tryLock(3,TimeUnit.SECONDS)){thrownewRuntimeException("获取订单锁失败");}try{// 尝试获取库存锁，最多等待3秒if(!inventoryLock.tryLock(3,TimeUnit.SECONDS)){thrownewRuntimeException("获取库存锁失败");}try{// 尝试获取支付锁，最多等待3秒if(!paymentLock.tryLock(3,TimeUnit.SECONDS)){thrownewRuntimeException("获取支付锁失败");}try{doConfirmOrder(orderId,productId,userId);}finally{paymentLock.unlock();}}finally{inventoryLock.unlock();}}finally{orderLock.unlock();}}catch(InterruptedExceptione){Thread.currentThread().interrupt();thrownewRuntimeException("获取锁被中断");}}

5.3 方案3：减少锁的嵌套（推荐）

核心原则：最小化锁的使用，避免嵌套锁

@ServicepublicclassOrderService{/** * 优化后：减少锁的嵌套，降低死锁风险 */publicvoidconfirmOrder(StringorderId,StringproductId,StringuserId){// 1. 先检查库存（无锁，快速失败）if(!inventoryService.checkInventory(productId)){thrownewRuntimeException("库存不足");}// 2. 锁定订单（最核心的锁）RLockorderLock=redissonClient.getLock("order:lock:"+orderId);try{if(!orderLock.tryLock(5,30,TimeUnit.SECONDS)){thrownewRuntimeException("获取订单锁失败");}// 3. 再次检查库存（双重检查，防止并发更新）if(!inventoryService.checkInventory(productId)){thrownewRuntimeException("库存不足");}// 4. 扣减库存（原子操作，数据库乐观锁）inventoryService.deductInventory(productId);// 5. 创建支付记录（幂等设计，无需锁）paymentService.createPaymentRecord(orderId,userId);// 6. 确认订单doConfirmOrder(orderId,productId,userId);}catch(InterruptedExceptione){Thread.currentThread().interrupt();thrownewRuntimeException("获取锁被中断");}finally{orderLock.unlock();}}}

6. 死锁监控与排查工具

6.1 生产环境监控

6.2 死锁排查命令

# 1. 查看JVM线程状态，检测死锁jstack-l<PID>|grep-A20"Found one Java-level deadlock"# 2. 查看线程详情jstack<PID>>jstack.txt# 分析jstack.txt文件，寻找BLOCKED状态的线程# 3. 使用VisualVM图形化工具jvisualvm# 启动VisualVM，连接到JVM进程，查看线程状态

7. 总结

7.1 死锁的本质

死锁的本质是资源的无序竞争+无限等待。

7.2 真实业务场景的死锁预防

7.3 最终建议

在库存扣减等核心业务场景中：

1. 优先使用数据库乐观锁，减少对分布式锁的依赖
2. 使用细粒度锁，按商品ID/订单ID加锁
3. 设置合理的tryLock参数，避免无限等待
4. 统一锁获取顺序，避免循环等待
5. 实现幂等性，确保重复执行不会产生副作用

通过以上措施，可以有效避免真实业务场景中的死锁问题，确保系统的高可用性和可靠性。