乐于分享
好东西不私藏

死锁排查实战:从日志到源码

死锁排查实战:从日志到源码

🚨 场景复现:支付系统死锁

问题现象

线上报警:订单处理超时,部分接口响应时间从50ms飙升到30秒,CPU使用率正常但大量请求卡住。

第一步:查看日志找线索

# 查看应用日志tail -f /app/logs/order-service.log# 发现大量超时日志2026-03-09 14:23:45 ERROR [http-nio-8080-exec-12] OrderController - 订单处理超时: orderId=123452026-03-09 14:23:46 ERROR [http-nio-8080-exec-24] PaymentController - 支付超时: paymentId=678902026-03-09 14:23:47 WARN  [http-nio-8080-exec-56] ThreadPoolTaskExecutor - 队列已满,任务被拒绝

第二步:使用jstack抓取线程快照

# 找到Java进程IDjps -l | grep order-service# 输出:12345 com.example.order.OrderApplication# 抓取线程堆栈(连续抓3次,间隔5秒)jstack -l 12345 > /tmp/jstack_1.logsleep 5jstack -l 12345 > /tmp/jstack_2.logsleep 5jstack -l 12345 > /tmp/jstack_3.log

🔎 第三步:分析jstack输出

查看线程状态统计

grep "java.lang.Thread.State" /tmp/jstack_1.log | sort | uniq -c# 输出:#  45 java.lang.Thread.State: BLOCKED (on object monitor)#  23 java.lang.Thread.State: RUNNABLE#  12 java.lang.Thread.State: TIMED_WAITING (sleeping)#   5 java.lang.Thread.State: WAITING (parking)# 发现大量线程处于BLOCKED状态,死锁嫌疑很大!

查找死锁线索

# 方法1:直接搜索死锁关键词(jstack会自动检测死锁)cat /tmp/jstack_1.log | grep -A 20 -B 10 "deadlock"# 输出关键信息:Found one Java-level deadlock:============================="Thread-123":  waiting to lock monitor 0x00007f9b0c00a800 (object 0x000000076b5f8a98, a java.lang.Object),  which is held by "Thread-456""Thread-456":  waiting to lock monitor 0x00007f9b0c00b200 (object 0x000000076b5f8b20, a java.lang.Object),  which is held by "Thread-123"Java stack information for the threads:---------------------------------------------------"Thread-123":    at com.example.service.OrderService.cancelOrder(OrderService.java:234)    - waiting to lock <0x000000076b5f8a98> (a com.example.entity.Order)    - locked <0x000000076b5f8b20> (a com.example.entity.Payment)"Thread-456":    at com.example.service.PaymentService.refund(PaymentService.java:123)    - waiting to lock <0x000000076b5f8b20> (a com.example.entity.Payment)    - locked <0x000000076b5f8a98> (a com.example.entity.Order)

💻 第四步:定位到源码

根据堆栈信息找到问题代码

OrderService.java

@Servicepublic class OrderService {    @Autowired    private PaymentService paymentService;    @Transactional    public void cancelOrder(Long orderId, Long paymentId) {        Order order = orderRepository.findById(orderId).orElseThrow();        Payment payment = paymentRepository.findById(paymentId).orElseThrow();        // 先锁Order,再锁Payment        synchronized (order) {           // 锁1            log.info("已锁定订单: {}", orderId);            // 模拟业务处理            order.setStatus(OrderStatus.CANCELLED);            orderRepository.save(order);            // 调用支付服务退款            paymentService.refund(payment);  // 这里需要锁Payment            synchronized (payment) {      // 锁2                payment.setStatus(PaymentStatus.REFUNDED);                paymentRepository.save(payment);            }        }    }}

PaymentService.java

@Servicepublic class PaymentService {    @Autowired    private OrderService orderService;    @Transactional    public void refund(Long paymentId, Long orderId) {        Payment payment = paymentRepository.findById(paymentId).orElseThrow();        Order order = orderRepository.findById(orderId).orElseThrow();        // 先锁Payment,再锁Order(和OrderService相反的顺序)        synchronized (payment) {          // 锁2            log.info("已锁定支付: {}", paymentId);            payment.setStatus(PaymentStatus.REFUNDING);            paymentRepository.save(payment);            // 回调订单服务            orderService.cancelOrder(orderId, paymentId);  // 这里需要锁Order            synchronized (order) {         // 锁1                order.setStatus(OrderStatus.CANCELLED);                orderRepository.save(order);            }        }    }}

🔬 第五步:复现死锁条件

编写测试用例验证

@SpringBootTestpublic class DeadlockTest {    @Autowired    private OrderService orderService;    @Autowired    private PaymentService paymentService;    @Test    public void testDeadlock() throws InterruptedException {        Long orderId = 123L;        Long paymentId = 456L;        // 线程1:从订单开始        Thread t1 = new Thread(() -> {            try {                orderService.cancelOrder(orderId, paymentId);            } catch (Exception e) {                log.error("线程1异常", e);            }        }, "Thread-Order");        // 线程2:从支付开始        Thread t2 = new Thread(() -> {            try {                paymentService.refund(paymentId, orderId);            } catch (Exception e) {                log.error("线程2异常", e);            }        }, "Thread-Payment");        // 同时启动        t1.start();        t2.start();        // 等待观察        Thread.sleep(10000);        // 检查线程状态        log.info("线程1状态: {}", t1.getState());        log.info("线程2状态: {}", t2.getState());    }}// 运行结果:两个线程都卡在BLOCKED状态,死锁复现!

🎯 第六步:解决方案

方案1:固定锁获取顺序(推荐)

@Servicepublic class OrderService {    public void cancelOrder(Long orderId, Long paymentId) {        Order order = orderRepository.findById(orderId).orElseThrow();        Payment payment = paymentRepository.findById(paymentId).orElseThrow();        // 统一按照:先order后payment的顺序        // 或者使用System.identityHashCode决定顺序        Object lock1 = order;        Object lock2 = payment;        // 确保总是以相同的顺序获取锁        if (System.identityHashCode(order) > System.identityHashCode(payment)) {            lock1 = payment;            lock2 = order;        }        synchronized (lock1) {            synchronized (lock2) {                // 业务处理            }        }    }}

方案2:使用ReentrantLock的tryLock超时机制

@Servicepublic class PaymentService {    private final ReentrantLock orderLock = new ReentrantLock();    private final ReentrantLock paymentLock = new ReentrantLock();    public void refund(Long paymentId, Long orderId) {        boolean gotOrderLock = false;        boolean gotPaymentLock = false;        try {            // 尝试获取两个锁,设置超时时间            gotPaymentLock = paymentLock.tryLock(3, TimeUnit.SECONDS);            if (!gotPaymentLock) {                throw new RuntimeException("获取支付锁超时");            }            gotOrderLock = orderLock.tryLock(3, TimeUnit.SECONDS);            if (!gotOrderLock) {                throw new RuntimeException("获取订单锁超时");            }            // 业务处理            doRefund(paymentId, orderId);        } catch (InterruptedException e) {            Thread.currentThread().interrupt();            throw new RuntimeException("操作被中断");        } finally {            // 释放锁,注意顺序            if (gotOrderLock) {                orderLock.unlock();            }            if (gotPaymentLock) {                paymentLock.unlock();            }        }    }}

方案3:使用数据库行锁代替应用锁

@Servicepublic class OrderService {    @Transactional    public void cancelOrder(Long orderId, Long paymentId) {        // 使用数据库的悲观锁,由数据库管理锁顺序        Order order = orderRepository.findByIdWithLock(orderId);        Payment payment = paymentRepository.findByIdWithLock(paymentId);        // 业务处理,数据库会处理死锁检测        order.setStatus(OrderStatus.CANCELLED);        payment.setStatus(PaymentStatus.REFUNDED);        // 事务提交时释放锁    }}@Repositorypublic interface OrderRepository extends JpaRepository<Order, Long> {    @Lock(LockModeType.PESSIMISTIC_WRITE)    @Query("select o from Order o where o.id = :id")    Optional<Order> findByIdWithLock(@Param("id") Long id);}

🛠 第七步:预防措施

1. 代码规范检查

// 自定义注解,标记方法需要多锁@Target(ElementType.METHOD)@Retention(RetentionPolicy.RUNTIME)public @interface MultiLockOperation {    String[] lockOrder() default {};  // 锁获取顺序}// 切面检查锁顺序@Aspect@Componentpublic class DeadlockPreventionAspect {    @Before("@annotation(multiLock)")    public void checkLockOrder(MultiLockOperation multiLock) {        // 检查当前线程的锁获取顺序是否符合规范        String[] requiredOrder = multiLock.lockOrder();        List<String> currentOrder = LockRecorder.getCurrentThreadLocks();        if (!isValidOrder(requiredOrder, currentOrder)) {            throw new IllegalStateException("锁获取顺序可能引发死锁!");        }    }}

2. 监控告警

# 定期检查死锁#!/bin/bashwhile truedo    jstack $(jps | grep OrderApplication | awk '{print $1}') > /tmp/jstack.log    if grep -q "deadlock" /tmp/jstack.log; then        echo "检测到死锁!时间: $(date)" | mail -s "死锁告警" dev@company.com        cp /tmp/jstack.log /tmp/deadlock_$(date +%Y%m%d_%H%M%S).log    fi    sleep 60done

📊 死锁排查工具对比

工具
优点
缺点
适用场景
jstack
系统自带,轻量
需要人工分析
快速定位
VisualVM
可视化,直观
线上环境慎用
开发测试
Arthas
功能强大,在线
需要学习成本
生产环境
FastThread
在线分析工具
上传数据风险
离线分析

🎓 经验总结

死锁产生的四个必要条件

  1. 互斥:资源一次只能被一个线程占用

  2. 占有且等待:线程持有锁还在等待其他锁

  3. 不可剥夺:锁只能自己释放

  4. 循环等待:线程间形成循环依赖

排查口诀

日志报警先发现,jstack抓线程BLOCKED线程多,死锁很可能搜索deadlock关键词,锁定两个线程查看堆栈找代码,锁顺序反了解决方案有三种,顺序最重要监控告警加规范,死锁不再来