1. 死锁现象的本质与危害当两个或多个线程在执行过程中因争夺资源而造成的一种互相等待的现象若无外力干涉这些线程将永远阻塞下去这就是死锁。想象一下十字路口四辆车同时到达每辆车都在等待其他车先通过结果谁都无法前进的场景。在Java中死锁通常发生在多线程对共享资源进行同步访问时。我曾在生产环境遇到过这样一个案例支付系统在高峰期频繁出现交易卡死最终排查发现是订单状态更新与库存扣减两个操作形成了循环等待。这种问题一旦发生轻则导致部分功能不可用重则引发系统雪崩。死锁的四个必要条件必须同时满足互斥条件资源一次只能被一个线程占用 2.请求与保持线程持有资源的同时请求新资源 3.不可剥夺已获得的资源不能被其他线程强行夺取 4.循环等待多个线程形成头尾相接的资源等待环关键提示在实际开发中循环等待是最容易通过代码设计避免的条件也是我们排查死锁问题的首要切入点。2. Java死锁的典型代码模式2.1 经典的双锁嵌套场景下面这段代码展示了一个教科书级的死锁案例我在面试候选人时经常用它作为考察点public class ClassicDeadlock { private static final Object lockA new Object(); private static final Object lockB new Object(); public static void method1() { synchronized (lockA) { System.out.println(Thread1 acquired lockA); try { Thread.sleep(100); } catch (InterruptedException e) {} synchronized (lockB) { System.out.println(Thread1 acquired lockB); } } } public static void method2() { synchronized (lockB) { System.out.println(Thread2 acquired lockB); try { Thread.sleep(100); } catch (InterruptedException e) {} synchronized (lockA) { System.out.println(Thread2 acquired lockA); } } } public static void main(String[] args) { new Thread(ClassicDeadlock::method1).start(); new Thread(ClassicDeadlock::method2).start(); } }运行这段代码你会发现控制台输出卡在Thread1 acquired lockA Thread2 acquired lockB2.2 数据库事务中的死锁变种数据库操作中的死锁更为隐蔽。我曾处理过一个电商平台的案例两个事务同时执行如下操作事务1UPDATE products SET stock stock - 1 WHERE id 1; UPDATE products SET stock stock - 1 WHERE id 2;事务2UPDATE products SET stock stock - 1 WHERE id 2; UPDATE products SET stock stock - 1 WHERE id 1;当这两个事务并发执行时就可能形成数据库层面的死锁。MySQL会检测到这种情况并自动回滚其中一个事务但应用层需要做好重试机制。3. 死锁诊断与排查工具3.1 使用jstack进行线程分析当应用出现疑似死锁时jstack是最直接的诊断工具。通过以下步骤获取线程转储# 查找Java进程ID jps -l # 生成线程转储 jstack -l pid thread_dump.log在输出的日志中搜索deadlock关键词jstack会自动标识出死锁的线程和锁信息。一个真实的诊断输出示例如下Found one Java-level deadlock: Thread-1: waiting to lock monitor 0x00007f88b4003f58 (object 0x000000076ab270c8, a java.lang.Object), which is held by Thread-0 Thread-0: waiting to lock monitor 0x00007f88b4006328 (object 0x000000076ab270d8, a java.lang.Object), which is held by Thread-13.2 JConsole与VisualVM的可视化监控对于图形化工具爱好者JConsole和VisualVM提供了更直观的线程监控启动JConsole在JDK的bin目录下执行jconsole选择目标Java进程切换到线程标签页点击检测死锁按钮VisualVM还提供了线程dump的对比功能适合分析死锁的发展过程。我在分析一个间歇性死锁问题时就是通过定期生成线程快照对比发现了锁的竞争模式。3.3 商业APM工具的进阶诊断在生产环境New Relic、Dynatrace等APM工具可以自动捕获死锁事件并关联到具体业务代码。它们通常提供死锁发生时的完整调用链受影响请求的业务参数历史死锁事件的统计与分析4. 死锁预防与解决方案4.1 锁排序技术解决循环等待最有效的方法是实现一致的锁获取顺序。以前面的双锁问题为例我们可以改造为public class FixedLockOrder { private static final Object lockA new Object(); private static final Object lockB new Object(); public static void method1() { synchronized (lockA) { synchronized (lockB) { // 业务逻辑 } } } public static void method2() { synchronized (lockA) { // 与method1相同的获取顺序 synchronized (lockB) { // 业务逻辑 } } } }对于动态资源如数据库记录可以使用哈希值或业务主键排序。我在支付系统中处理账户转账时总是先锁ID小的账户再锁ID大的账户。4.2 尝试锁机制Java的ReentrantLock提供了更灵活的锁控制public class TryLockSolution { private static final ReentrantLock lockA new ReentrantLock(); private static final ReentrantLock lockB new ReentrantLock(); public static void method1() { while (true) { if (lockA.tryLock()) { try { if (lockB.tryLock()) { try { // 业务逻辑 return; } finally { lockB.unlock(); } } } finally { lockA.unlock(); } } // 随机休眠避免活锁 try { Thread.sleep((long)(Math.random()*100)); } catch (InterruptedException e) {} } } }4.3 数据库事务优化对于数据库死锁除了调整SQL顺序外还可以减小事务粒度将大事务拆分为多个小事务降低隔离级别从SERIALIZABLE降级到READ_COMMITTED添加重试机制捕获死锁异常后自动重试Spring框架中可以通过Retryable注解方便地实现重试Retryable(value {DeadlockLoserDataAccessException.class}, maxAttempts 3, backoff Backoff(delay 100)) public void updateInventory(Long productId, int quantity) { // 库存更新逻辑 }5. 生产环境死锁案例分析5.1 缓存与数据库的双写死锁某社交平台曾出现这样的死锁场景线程A先获取Redis分布式锁然后请求数据库行锁线程B先获取数据库行锁然后请求Redis分布式锁两者形成跨组件的死锁解决方案是统一锁获取顺序总是先获取数据库锁再获取缓存锁。同时设置Redis锁的超时时间作为安全网。5.2 线程池任务间的隐式死锁考虑以下线程池使用场景ExecutorService executor Executors.newFixedThreadPool(1); FutureString future executor.submit(() - { FutureString innerFuture executor.submit(() - Hello); return innerFuture.get(); // 死锁 });单线程池中外部任务等待内部任务完成但内部任务无法执行因为线程被外部任务占用。解决方案是使用不同线程池或调整线程池大小。5.3 第三方库导致的死锁我遇到过最棘手的死锁是Hibernate初始化时与Tomcat类加载器形成的死锁。这类问题通常需要更新库版本到已知修复版本调整类加载顺序在启动参数中添加-XX:AlwaysPreTouch提前触发类加载6. 死锁检测与自动恢复机制6.1 基于定时器的死锁检测可以创建一个监控线程定期检查死锁状态public class DeadlockDetector extends Thread { private static final long CHECK_INTERVAL 10000; Override public void run() { ThreadMXBean threadBean ManagementFactory.getThreadMXBean(); while (!Thread.currentThread().isInterrupted()) { long[] threadIds threadBean.findDeadlockedThreads(); if (threadIds ! null) { ThreadInfo[] infos threadBean.getThreadInfo(threadIds); // 发送告警或尝试恢复 recoverFromDeadlock(infos); } try { Thread.sleep(CHECK_INTERVAL); } catch (InterruptedException e) { break; } } } private void recoverFromDeadlock(ThreadInfo[] infos) { // 实际项目中可能需要更复杂的恢复逻辑 for (ThreadInfo info : infos) { Thread thread findThreadById(info.getThreadId()); if (thread ! null) { thread.interrupt(); } } } }6.2 基于JVM Agent的增强监控对于关键业务系统可以开发自定义的Java Agent来监控锁获取行为public class LockTrackingAgent { public static void premain(String args, Instrumentation inst) { inst.addTransformer(new ClassFileTransformer() { Override public byte[] transform(ClassLoader loader, String className, Class? classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer) { // 使用ASM修改字节码在monitorenter/exit处插入监控代码 return instrumentClass(classfileBuffer); } }); } }这种方案可以记录完整的锁获取顺序帮助复现死锁场景。7. 并发编程的最佳实践7.1 锁粒度控制原则尽量缩小同步代码块范围区分读写场景读多写少时使用ReadWriteLock对于状态组合操作考虑使用不可变对象7.2 避免锁的常见陷阱不要在同步块内调用外部方法容易引发意想不到的锁竞争谨慎使用类级别锁synchronized static方法避免在持有锁时进行IO操作注意锁的可重入性虽然ReentrantLock和synchronized都支持重入但过度重入可能导致逻辑混乱7.3 无锁编程替代方案在某些场景下可以考虑使用ConcurrentHashMap等并发集合采用CAS操作AtomicInteger等使用Actor模型如Akka框架基于线程本地存储ThreadLocal避免共享比如计数器场景// 有锁实现 public class Counter { private int value; public synchronized int increment() { return value; } } // 无锁实现 public class LockFreeCounter { private final AtomicInteger value new AtomicInteger(); public int increment() { return value.incrementAndGet(); } }在实际项目中我会根据竞争激烈程度选择实现方案。低竞争时synchronized性能更好高竞争时无锁方案优势明显。