1. 项目概述从一次“卡死”的线上事故说起那天下午监控系统突然告警一个核心的后台数据处理服务响应时间飙升最终彻底无响应。登录服务器一看CPU和内存占用都不高但服务就是“卡”住了新的请求进不来旧的请求也处理不完。凭着经验我第一反应就是线程死锁了。果然通过jstack命令导出线程堆栈信息后在一堆复杂的调用链中清晰地看到了几个线程互相等待对方释放锁的经典画面。这次事故让我损失了几个小时的排查时间和一部分用户信任但也让我对“线程死锁”这个老生常谈却又极易踩坑的问题有了更刻骨铭心的理解。今天我们就来彻底拆解它尤其是死锁产生的四个必要条件。理解这四个条件不仅是面试时的八股文更是我们日常开发中设计、编码和排查问题时脑子里必须绷紧的一根弦。无论你是用Java、C、Python还是Go只要涉及多线程并发这个概念就是绕不开的基石。接下来我会结合代码实例、排查工具和实战经验带你从原理到实践把死锁问题看得清清楚楚。2. 死锁产生的四个必要条件深度解析死锁不是凭空产生的它的发生必须同时满足四个条件缺一不可。这就像一场悲剧上演所需的四个要素我们理解了它们就能在编写代码时有意地破坏其中至少一个从而避免悲剧发生。2.1 互斥条件资源的排他性占有互斥条件是并发编程的基础也是死锁的起点。它指的是资源如锁、文件句柄、数据库连接在任意时刻只能被一个线程持有。如果资源可以被共享那么就不会有等待自然也就没有死锁。核心原理操作系统或编程语言提供的锁机制如synchronized关键字、ReentrantLock、pthread_mutex_t本质上就是在实现互斥。当一个线程持有锁时其他尝试获取该锁的线程会被阻塞进入等待队列。代码示例Javapublic class MutexCondition { private final Object lockA new Object(); public void method1() { synchronized (lockA) { // 线程T1进入lockA被独占 // 访问共享资源 } } public void method2() { synchronized (lockA) { // 线程T2尝试进入必须等待T1释放lockA // 访问共享资源 } } }在这个例子里lockA就是一个互斥资源。method1和method2不能同时进入synchronized块。这是合理的也是我们保护共享数据所必需的。互斥本身不是问题问题是多个互斥资源以不当的顺序被多个线程请求时就会埋下祸根。注意互斥条件通常无法被破坏因为我们需要它来保证数据一致性。我们的防御策略主要针对后面三个条件。2.2 请求与保持条件吃着碗里的看着锅里的这个条件描述的是线程的一种“贪婪”行为线程已经持有了至少一个资源但又提出了对新的资源的请求而该新资源已被其他线程持有此时该线程进入等待状态但对自己已持有的资源保持不放。场景还原想象一下在餐厅你需要刀和叉才能吃饭。你先拿到了刀资源A然后去拿叉资源B但发现叉被别人拿走了。于是你决定就站在原地等叉但手里紧紧握着刀不放开。另一边拿着叉的人也在等你的刀。你们俩就僵持住了。代码示例典型死锁public class RequestAndHold { private final Object lock1 new Object(); private final Object lock2 new Object(); public void thread1Work() { synchronized (lock1) { // 步骤1持有lock1 try { Thread.sleep(50); } catch (InterruptedException e) {} // 模拟业务操作 synchronized (lock2) { // 步骤3请求lock2此时可能被thread2持有 System.out.println(Thread1 got both locks); } } } public void thread2Work() { synchronized (lock2) { // 步骤2持有lock2 try { Thread.sleep(50); } catch (InterruptedException e) {} synchronized (lock1) { // 步骤4请求lock1此时被thread1持有 System.out.println(Thread2 got both locks); } } } }让两个线程分别执行thread1Work和thread2Work只要时机合适两个线程几乎同时开始并在对方进入第二个synchronized前完成第一个synchronized死锁必然发生。线程1持有lock1请求lock2线程2持有lock2请求lock1双方都“请求并保持”完美符合条件。破坏方法这是最容易也是我们最应该主动破坏的条件。核心思路是一次性申请所有所需资源。如果无法一次性获取全部则先释放已持有的资源再重新尝试获取所有资源。Java中的Lock接口及其实现类如ReentrantLock配合tryLock()方法可以比synchronized更灵活地实现这种“申请不到就释放”的策略。2.3 不剥夺条件资源只能由持有者主动释放不剥夺条件是指线程已获得的资源在其使用完之前不能被其他线程强行抢占只能由该线程主动释放。如果资源可以被强制剥夺那么死锁的僵局就能被外力打破。操作系统层面的对比CPU资源是可剥夺的。操作系统可以通过调度器强行挂起一个线程把CPU分配给另一个线程。但像锁这样的资源在用户态编程中通常设计为不可剥夺的因为强行释放一个线程持有的锁可能导致该线程正在修改的数据处于不一致的中间状态引发更严重的数据损坏问题。编程语言中的体现无论是Java的synchronized还是ReentrantLock.lock()获取锁的操作都是阻塞式的一旦获取成功除非线程自己执行到同步块结束或调用unlock()否则锁不会被释放。没有“强制解锁另一个线程的锁”的标准API。破坏的难度与风险在应用层我们几乎不会去破坏这个条件因为它违背了锁设计的初衷会引入巨大的复杂性和数据安全风险。但在某些高级场景或特定框架如数据库死锁检测系统检测到死锁后可能会选择一个“牺牲者”强制回滚其事务相当于剥夺其持有的资源从而打破死锁。在Java中我们可以通过Lock的lockInterruptibly()方法响应中断或者使用带超时的tryLock(long time, TimeUnit unit)这算是一种温和的“剥夺”——不是系统强行抢而是给线程一个主动放弃的机会。2.4 循环等待条件一个闭环的等待链循环等待条件是死锁的最终表现形式。它指的是存在一个线程集合{T1, T2, ..., Tn}其中T1等待T2占用的资源T2等待T3占用的资源...Tn等待T1占用的资源形成一个首尾相接的循环等待链。图解循环等待线程T1 ---持有--- 资源R1 线程T2 ---持有--- 资源R2 线程T1 ---等待--- 资源R2 线程T2 ---等待--- 资源R1这就是一个最简单的二元循环等待。在复杂的系统中这个链可能很长涉及多个线程和资源。代码中的体现它就是2.2节中代码示例运行时的状态。通过jstack工具看到的线程堆栈信息会清晰地显示这种循环依赖Thread-1 #12 prio5 os_prio0 tid0x00007f48740f8000 nid0x6d1c waiting for monitor entry [0x00007f486b7f6000] java.lang.Thread.State: BLOCKED (on object monitor at 0x000000076c1e8dd8) at com.example.RequestAndHold.thread1Work(RequestAndHold.java:10) - waiting to lock 0x000000076c1e8de0 (a java.lang.Object) // 在等lock2 - locked 0x000000076c1e8dd8 (a java.lang.Object) // 已锁住lock1 Thread-2 #13 prio5 os_prio0 tid0x00007f48740fa000 nid0x6d1d waiting for monitor entry [0x00007f486b6f5000] java.lang.Thread.State: BLOCKED (on object monitor at 0x000000076c1e8de0) at com.example.RequestAndHold.thread2Work(RequestAndHold.java:18) - waiting to lock 0x000000076c1e8dd8 (a java.lang.Object) // 在等lock1 - locked 0x000000076c1e8de0 (a java.lang.Object) // 已锁住lock2输出明确显示了“Thread-1 locked A, waiting for B” 和 “Thread-2 locked B, waiting for A”的循环。最有效的破坏方法资源有序分配法。这是实践中预防死锁最常用、最有效的方法。其核心思想是给所有需要加锁的资源定义一个全局的、严格的获取顺序例如按内存地址哈希值排序或按业务逻辑定义优先级所有线程在任何时候都必须按照这个顺序去申请资源。有序分配代码示例public class OrderedLocking { private final Object lock1 new Object(); private final Object lock2 new Object(); // 定义顺序总是先申请lock1再申请lock2 public void safeMethod1() { synchronized (lock1) { synchronized (lock2) { // 安全地操作共享资源 } } } public void safeMethod2() { synchronized (lock1) { // 即使safeMethod2只需要lock2也必须先申请lock1 synchronized (lock2) { // 安全地操作共享资源 } } } }通过强制规定顺序我们彻底杜绝了“线程1先A后B线程2先B后A”这种交叉申请的可能性。无论线程的业务逻辑是什么它们申请资源的路径在全局上是一条“单行道”不可能形成环。这是解决哲学家就餐问题的经典思路。3. 死锁的实战排查与诊断技巧知道原理是为了预防但线上系统复杂依赖众多死锁仍可能发生。当服务出现“卡死”、吞吐量骤降但CPU不高时快速定位死锁是关键。3.1 利用JVM工具链进行现场分析对于Java应用JDK自带了一套强大的诊断工具。1. 使用jstack命令获取线程转储jstack是首要工具。通过jstack pid命令可以将指定Java进程的所有线程状态、调用栈和锁信息输出到控制台或文件。# 找到Java进程ID jps -l # 生成线程转储 jstack -l pid thread_dump.log在输出的日志中直接搜索“deadlock”关键词JVM的死锁检测器可能会直接告诉你发现了一个死锁并列出涉及的线程。即使没有直接提示你也可以通过分析线程状态来发现。2. 解读线程转储信息重点关注BLOCKED状态的线程。看它们的堆栈信息waiting to lock 0x...表示该线程正在等待这个地址对应的锁。locked 0x...表示该线程已经持有了这个地址对应的锁。 通过对比多个BLOCKED线程的“waiting to lock”和“locked”对象地址很容易就能拼出循环等待链。就像前面2.4节展示的那样。3. 使用jconsole或VisualVM进行可视化监控对于图形界面友好的环境jconsole或更强大的VisualVM是更好的选择。它们可以连接到本地或远程的JVM进程在“线程”选项卡中通常有一个“检测死锁”的按钮一键点击就能可视化地展示出哪些线程陷入了死锁以及它们之间的资源依赖关系图非常直观。3.2 针对特定场景的排查策略死锁不只发生在简单的synchronized代码块里它可能隐藏在框架、数据库连接池、第三方库中。数据库死锁排查 数据库死锁是另一个常见源头。当两个事务以不同顺序更新多张表的多条记录时就可能发生。排查时开启数据库的死锁日志如MySQL的innodb_print_all_deadlocksON。查看数据库错误日志找到死锁发生时的事务信息。分析日志中输出的WAITING FOR THIS LOCK TO BE GRANTED和HOLDS THE LOCK(S)部分理清事务间的等待关系。解决方案同样是保证应用层以相同的顺序访问表记录或使用更小的事务粒度。使用Grafana等监控工具辅助排查Java死锁/OOM 单纯的jstack是事后分析。对于线上系统我们需要监控和预警。可以将jstack的定期执行与监控平台结合。脚本化定期采集编写一个Shell脚本定时如每分钟执行jstack并利用grep分析输出中BLOCKED线程的数量或直接搜索死锁特征。如果超过阈值则发出告警。与Prometheus/Grafana集成通过JMX暴露JVM的Threading相关MBean如java.lang:typeThreading的ThreadCount、DaemonThreadCount以及自定义的DeadlockCount——如果你通过程序检测到的话。Prometheus抓取这些指标在Grafana中绘制图表并设置告警规则。当BLOCKED线程数持续增长或长时间不释放时就能提前发现问题苗头。结合OOM排查死锁可能导致线程堆积间接引发内存问题。监控jmap -histo或jstat -gc的输出观察老年代内存增长是否与线程数增长相关。Grafana面板上同时展示线程数、堆内存使用率、GC次数能帮你建立关联性分析。排查中的注意事项多次采样死锁可能不是持续存在的或者转储的瞬间可能捕捉不到。建议在问题发生时连续执行多次jstack如间隔5秒执行3次对比分析。关注“Ownable Synchronizers”在使用java.util.concurrent.locks包下的锁如ReentrantLock时线程转储中这部分信息很重要它显示了Lock对象的具体持有者。结合业务日志将线程转储中的线程名如果设置了有意义的名称与业务日志中的上下文关联起来能更快定位到出问题的代码段和业务场景。4. 高级场景下的死锁预防与最佳实践理解了基本条件和排查方法我们还需要在更复杂的并发设计中将死锁风险降到最低。4.1 线程池与资源管理不当引发的死锁线程池用不好本身就会成为死锁的帮凶。一个经典的陷阱是在同一个线程池中提交有依赖关系的任务。场景模拟 假设我们有一个固定大小为2的线程池。我们向池中提交了任务A和任务B。任务A内部又需要提交一个子任务C到同一个线程池并等待其结果例如使用Future.get()。如果任务B长时间运行不结束那么线程池的两个线程都被占用A和B。任务A在等待子任务C完成但子任务C因为线程池已满永远得不到执行。于是任务A永远等下去形成了线程池内部的资源死锁。解决方案使用不同的线程池将相互独立的任务和存在父子依赖关系的任务隔离到不同的线程池中。使用无界队列需谨慎ThreadPoolExecutor使用无界队列如LinkedBlockingQueue时可能会掩盖资源耗尽的问题但依赖任务死锁的风险依然存在。避免在任务内等待同一池中的其他任务这是根本。如果必须等待考虑使用CompletableFuture等更灵活的异步编程模型或者确保线程池大小足以处理这种嵌套。Fork/Join框架的特别说明 你提到的热词“fork join介绍 里面线程1结束之后 执行fork join后面的内容 此时线程2还在运行”这描述了Fork/Join框架的工作窃取Work-Stealing机制。一个线程比如线程1完成了自己的任务后不会闲着它会去“偷”其他线程队列里未执行的任务来执行。这种机制本身是为了提高效率但它也可能引入复杂的依赖。在Fork/Join中如果任务设计不当比如一个任务在join()等待其子任务时又需要获取某个被其他任务可能是被“偷”去执行的任务持有的锁同样可能引发死锁。因此在Fork/Join任务中也应遵循资源有序获取等原则尽量减少甚至避免在分解的子任务中使用阻塞锁。4.2 锁的粒度与范围优化锁的粒度太粗会增加竞争降低性能但锁的粒度设计不当也可能增加死锁的概率。缩小锁范围尽可能只锁住共享数据被访问和修改的最小代码段尽快释放锁。这减少了锁持有的时间也就缩短了其他线程可能等待的时间窗口降低了死锁发生的概率。// 不推荐锁住整个方法范围太大 public synchronized void processBigData() { // 步骤1读取数据无需同步 // 步骤2修改共享变量需要同步 // 步骤3写入文件无需同步 } // 推荐只锁住必要的部分 public void processBigData() { // 步骤1读取数据无需同步 synchronized (this) { // 步骤2修改共享变量需要同步 } // 步骤3写入文件无需同步 }使用线程安全的数据结构很多时候我们加锁只是为了保护一个HashMap或ArrayList。Java并发包提供了ConcurrentHashMap、CopyOnWriteArrayList等高效线程安全的容器。使用它们可以消除很多显式加锁的代码从根本上避免因锁顺序问题导致的死锁。4.3 尝试锁与超时机制这是破坏“请求与保持”和“不剥夺”条件的工程化手段。与其一直阻塞等待不如“尝试一下不行就撤”。使用ReentrantLock.tryLock()private final ReentrantLock lock1 new ReentrantLock(); private final ReentrantLock lock2 new ReentrantLock(); public boolean tryTransfer() { // 尝试获取第一个锁 if (!lock1.tryLock()) { return false; // 获取失败立即返回不阻塞 } try { // 尝试获取第二个锁带超时 if (!lock2.tryLock(1, TimeUnit.SECONDS)) { // 获取第二个锁超时释放第一个锁避免持有等待 lock1.unlock(); return false; } try { // 成功获取两把锁执行业务逻辑 doBusiness(); return true; } finally { lock2.unlock(); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); lock1.unlock(); // 发生中断也释放锁 return false; } finally { // 注意第一个锁的解锁在更外层的finally确保异常时释放 // 但这里因为内层失败时已手动解锁需要小心处理。更好的模式见下文。 } }更健壮的模板上面的代码在异常处理上有些复杂。一个更好的模式是“回退重试”或者使用一个工具方法来统一管理多个锁的尝试获取。public boolean acquireLocks(Lock firstLock, Lock secondLock) { boolean acquiredFirst false; boolean acquiredSecond false; try { acquiredFirst firstLock.tryLock(100, TimeUnit.MILLISECONDS); if (!acquiredFirst) { return false; } acquiredSecond secondLock.tryLock(100, TimeUnit.MILLISECONDS); if (!acquiredSecond) { return false; } return true; // 两个锁都获取成功 } catch (InterruptedException e) { Thread.currentThread().interrupt(); return false; } finally { // 如果没成功获取第二个锁释放第一个锁 if (!acquiredSecond acquiredFirst) { firstLock.unlock(); } // 如果任何地方失败确保状态干净 if (!(acquiredFirst acquiredSecond)) { // 清理逻辑 } } }使用超时机制给了线程一个“放弃”的机会。当获取锁失败时线程可以释放已持有的资源破坏“请求与保持”记录日志进行重试或者执行降级逻辑而不是无限期地等下去这极大地提高了系统的健壮性。5. 不同编程语言与生态中的死锁考量死锁是一个跨语言的通用并发问题但在不同语言和其生态中表现形式和应对工具略有不同。5.1 C/C中的死锁排查C/C由于更接近系统层且内存、锁需要手动管理死锁风险更高排查也更依赖系统工具。工具在Linux下gdb调试器是核心。可以使用thread apply all bt命令打印所有线程的调用栈。结合pstack pid命令也能快速查看线程堆栈。对于使用pthread库的程序要仔细检查pthread_mutex_lock的调用顺序。特点C11引入了mutex、atomic等标准库提供了std::lock、std::try_lock等可以一次性锁定多个互斥量且避免死锁的实用函数其原理就是内部实现了“资源有序分配”或“尝试回退”算法。务必使用这些现代C并发设施而不是手动操作原生锁。排查难点没有JVM那样统一的运行时和jstack这样的神器更需要依赖核心转储core dump和事后分析。5.2 Python (threading) 中的死锁Python由于存在全局解释器锁GIL通常认为多线程无法实现真正的并行计算。但GIL只保护了解释器状态和内存管理对于用户自定义的锁threading.Lock和涉及I/O的操作线程仍然会切换因此死锁问题同样存在。Python的threading模块提供的锁也是不可重入的threading.RLock是可重入锁死锁条件完全适用。排查时可以使用faulthandler模块或sys._current_frames()来获取线程状态。5.3 数据库事务中的死锁这是另一个重灾区。如前所述解决方案包括保持一致的访问顺序在应用层代码中确保所有业务逻辑在更新多个表时都按照相同的顺序例如按表名字母顺序或按业务主次顺序进行。减小事务粒度尽快提交事务缩短锁持有的时间。将大事务拆分成多个小事务。使用较低的隔离级别如读已提交Read Committed可以避免很多间隙锁Gap Lock导致的死锁但需要评估对数据一致性的影响。重试机制在应用代码中捕获数据库抛出的死锁错误如MySQL的1213错误码并进行有限次数的重试。5.4 前端与客户端开发中的“死锁”虽然JavaScript是单线程的不存在传统意义上的线程死锁但在异步编程中存在类似的“回调地狱”或“Promise链僵局”。例如两个异步操作互相等待对方的结果才能解析自己的Promise。这更多是逻辑设计问题。使用async/await编写清晰的顺序逻辑并仔细梳理异步任务间的依赖关系可以避免此类问题。6. 设计阶段规避死锁的系统性思考最好的死锁处理是在设计和代码审查阶段就将其扼杀。1. 静态代码分析工具集成SonarQube、FindBugs/SpotBugs等工具到CI/CD流程中。这些工具内置了检测潜在死锁模式的规则如“两个方法以不同顺序获取相同的两个锁”能在代码提交前就发出警告。2. 代码审查清单在团队代码审查中将并发代码作为重点。审查时自问这段代码涉及几个锁所有路径上锁的获取顺序是否一致资源有序分配锁的范围是否最小化是否存在嵌套锁嵌套顺序是否可能形成环是否可以使用线程安全容器替代显式锁是否考虑了超时和中断3. 架构设计层面减少共享状态这是解决并发问题的根本之道。考虑能否使用无状态设计、Actor模型如Akka、或将状态封装到单个线程中线程封闭技术。使用更高级的并发抽象如java.util.concurrent包中的CyclicBarrier、CountDownLatch、Semaphore等它们封装了复杂的同步逻辑比自己操作锁更安全。异步非阻塞对于I/O密集型应用考虑使用Netty、Vert.x等异步框架或CompletableFuture、反应式流Reactive Streams将线程从阻塞等待中解放出来减少线程因等待资源而阻塞的场景从而降低死锁风险。死锁就像并发世界里的一个幽灵理解它产生的四个条件——互斥、请求与保持、不剥夺、循环等待——是我们对抗它的第一道防线。通过有序分配资源、使用尝试锁与超时、缩小锁范围、利用现代并发工具等实践我们可以在很大程度上预防它。而当问题真的出现时熟练使用jstack、线程转储分析、数据库日志等工具进行排查则是我们快速恢复服务的保障。记住并发编程没有银弹保持对锁的敬畏在设计和编码时多思考一步就能让我们的系统更加稳健。在我经历的那次事故后团队引入了强制性的锁顺序规范和代码扫描类似的问题再也没出现过。这或许就是踩坑带来的最大价值。
1. 项目概述从一次“卡死”的线上事故说起那天下午监控系统突然告警一个核心的后台数据处理服务响应时间飙升最终彻底无响应。登录服务器一看CPU和内存占用都不高但服务就是“卡”住了新的请求进不来旧的请求也处理不完。凭着经验我第一反应就是线程死锁了。果然通过jstack命令导出线程堆栈信息后在一堆复杂的调用链中清晰地看到了几个线程互相等待对方释放锁的经典画面。这次事故让我损失了几个小时的排查时间和一部分用户信任但也让我对“线程死锁”这个老生常谈却又极易踩坑的问题有了更刻骨铭心的理解。今天我们就来彻底拆解它尤其是死锁产生的四个必要条件。理解这四个条件不仅是面试时的八股文更是我们日常开发中设计、编码和排查问题时脑子里必须绷紧的一根弦。无论你是用Java、C、Python还是Go只要涉及多线程并发这个概念就是绕不开的基石。接下来我会结合代码实例、排查工具和实战经验带你从原理到实践把死锁问题看得清清楚楚。2. 死锁产生的四个必要条件深度解析死锁不是凭空产生的它的发生必须同时满足四个条件缺一不可。这就像一场悲剧上演所需的四个要素我们理解了它们就能在编写代码时有意地破坏其中至少一个从而避免悲剧发生。2.1 互斥条件资源的排他性占有互斥条件是并发编程的基础也是死锁的起点。它指的是资源如锁、文件句柄、数据库连接在任意时刻只能被一个线程持有。如果资源可以被共享那么就不会有等待自然也就没有死锁。核心原理操作系统或编程语言提供的锁机制如synchronized关键字、ReentrantLock、pthread_mutex_t本质上就是在实现互斥。当一个线程持有锁时其他尝试获取该锁的线程会被阻塞进入等待队列。代码示例Javapublic class MutexCondition { private final Object lockA new Object(); public void method1() { synchronized (lockA) { // 线程T1进入lockA被独占 // 访问共享资源 } } public void method2() { synchronized (lockA) { // 线程T2尝试进入必须等待T1释放lockA // 访问共享资源 } } }在这个例子里lockA就是一个互斥资源。method1和method2不能同时进入synchronized块。这是合理的也是我们保护共享数据所必需的。互斥本身不是问题问题是多个互斥资源以不当的顺序被多个线程请求时就会埋下祸根。注意互斥条件通常无法被破坏因为我们需要它来保证数据一致性。我们的防御策略主要针对后面三个条件。2.2 请求与保持条件吃着碗里的看着锅里的这个条件描述的是线程的一种“贪婪”行为线程已经持有了至少一个资源但又提出了对新的资源的请求而该新资源已被其他线程持有此时该线程进入等待状态但对自己已持有的资源保持不放。场景还原想象一下在餐厅你需要刀和叉才能吃饭。你先拿到了刀资源A然后去拿叉资源B但发现叉被别人拿走了。于是你决定就站在原地等叉但手里紧紧握着刀不放开。另一边拿着叉的人也在等你的刀。你们俩就僵持住了。代码示例典型死锁public class RequestAndHold { private final Object lock1 new Object(); private final Object lock2 new Object(); public void thread1Work() { synchronized (lock1) { // 步骤1持有lock1 try { Thread.sleep(50); } catch (InterruptedException e) {} // 模拟业务操作 synchronized (lock2) { // 步骤3请求lock2此时可能被thread2持有 System.out.println(Thread1 got both locks); } } } public void thread2Work() { synchronized (lock2) { // 步骤2持有lock2 try { Thread.sleep(50); } catch (InterruptedException e) {} synchronized (lock1) { // 步骤4请求lock1此时被thread1持有 System.out.println(Thread2 got both locks); } } } }让两个线程分别执行thread1Work和thread2Work只要时机合适两个线程几乎同时开始并在对方进入第二个synchronized前完成第一个synchronized死锁必然发生。线程1持有lock1请求lock2线程2持有lock2请求lock1双方都“请求并保持”完美符合条件。破坏方法这是最容易也是我们最应该主动破坏的条件。核心思路是一次性申请所有所需资源。如果无法一次性获取全部则先释放已持有的资源再重新尝试获取所有资源。Java中的Lock接口及其实现类如ReentrantLock配合tryLock()方法可以比synchronized更灵活地实现这种“申请不到就释放”的策略。2.3 不剥夺条件资源只能由持有者主动释放不剥夺条件是指线程已获得的资源在其使用完之前不能被其他线程强行抢占只能由该线程主动释放。如果资源可以被强制剥夺那么死锁的僵局就能被外力打破。操作系统层面的对比CPU资源是可剥夺的。操作系统可以通过调度器强行挂起一个线程把CPU分配给另一个线程。但像锁这样的资源在用户态编程中通常设计为不可剥夺的因为强行释放一个线程持有的锁可能导致该线程正在修改的数据处于不一致的中间状态引发更严重的数据损坏问题。编程语言中的体现无论是Java的synchronized还是ReentrantLock.lock()获取锁的操作都是阻塞式的一旦获取成功除非线程自己执行到同步块结束或调用unlock()否则锁不会被释放。没有“强制解锁另一个线程的锁”的标准API。破坏的难度与风险在应用层我们几乎不会去破坏这个条件因为它违背了锁设计的初衷会引入巨大的复杂性和数据安全风险。但在某些高级场景或特定框架如数据库死锁检测系统检测到死锁后可能会选择一个“牺牲者”强制回滚其事务相当于剥夺其持有的资源从而打破死锁。在Java中我们可以通过Lock的lockInterruptibly()方法响应中断或者使用带超时的tryLock(long time, TimeUnit unit)这算是一种温和的“剥夺”——不是系统强行抢而是给线程一个主动放弃的机会。2.4 循环等待条件一个闭环的等待链循环等待条件是死锁的最终表现形式。它指的是存在一个线程集合{T1, T2, ..., Tn}其中T1等待T2占用的资源T2等待T3占用的资源...Tn等待T1占用的资源形成一个首尾相接的循环等待链。图解循环等待线程T1 ---持有--- 资源R1 线程T2 ---持有--- 资源R2 线程T1 ---等待--- 资源R2 线程T2 ---等待--- 资源R1这就是一个最简单的二元循环等待。在复杂的系统中这个链可能很长涉及多个线程和资源。代码中的体现它就是2.2节中代码示例运行时的状态。通过jstack工具看到的线程堆栈信息会清晰地显示这种循环依赖Thread-1 #12 prio5 os_prio0 tid0x00007f48740f8000 nid0x6d1c waiting for monitor entry [0x00007f486b7f6000] java.lang.Thread.State: BLOCKED (on object monitor at 0x000000076c1e8dd8) at com.example.RequestAndHold.thread1Work(RequestAndHold.java:10) - waiting to lock 0x000000076c1e8de0 (a java.lang.Object) // 在等lock2 - locked 0x000000076c1e8dd8 (a java.lang.Object) // 已锁住lock1 Thread-2 #13 prio5 os_prio0 tid0x00007f48740fa000 nid0x6d1d waiting for monitor entry [0x00007f486b6f5000] java.lang.Thread.State: BLOCKED (on object monitor at 0x000000076c1e8de0) at com.example.RequestAndHold.thread2Work(RequestAndHold.java:18) - waiting to lock 0x000000076c1e8dd8 (a java.lang.Object) // 在等lock1 - locked 0x000000076c1e8de0 (a java.lang.Object) // 已锁住lock2输出明确显示了“Thread-1 locked A, waiting for B” 和 “Thread-2 locked B, waiting for A”的循环。最有效的破坏方法资源有序分配法。这是实践中预防死锁最常用、最有效的方法。其核心思想是给所有需要加锁的资源定义一个全局的、严格的获取顺序例如按内存地址哈希值排序或按业务逻辑定义优先级所有线程在任何时候都必须按照这个顺序去申请资源。有序分配代码示例public class OrderedLocking { private final Object lock1 new Object(); private final Object lock2 new Object(); // 定义顺序总是先申请lock1再申请lock2 public void safeMethod1() { synchronized (lock1) { synchronized (lock2) { // 安全地操作共享资源 } } } public void safeMethod2() { synchronized (lock1) { // 即使safeMethod2只需要lock2也必须先申请lock1 synchronized (lock2) { // 安全地操作共享资源 } } } }通过强制规定顺序我们彻底杜绝了“线程1先A后B线程2先B后A”这种交叉申请的可能性。无论线程的业务逻辑是什么它们申请资源的路径在全局上是一条“单行道”不可能形成环。这是解决哲学家就餐问题的经典思路。3. 死锁的实战排查与诊断技巧知道原理是为了预防但线上系统复杂依赖众多死锁仍可能发生。当服务出现“卡死”、吞吐量骤降但CPU不高时快速定位死锁是关键。3.1 利用JVM工具链进行现场分析对于Java应用JDK自带了一套强大的诊断工具。1. 使用jstack命令获取线程转储jstack是首要工具。通过jstack pid命令可以将指定Java进程的所有线程状态、调用栈和锁信息输出到控制台或文件。# 找到Java进程ID jps -l # 生成线程转储 jstack -l pid thread_dump.log在输出的日志中直接搜索“deadlock”关键词JVM的死锁检测器可能会直接告诉你发现了一个死锁并列出涉及的线程。即使没有直接提示你也可以通过分析线程状态来发现。2. 解读线程转储信息重点关注BLOCKED状态的线程。看它们的堆栈信息waiting to lock 0x...表示该线程正在等待这个地址对应的锁。locked 0x...表示该线程已经持有了这个地址对应的锁。 通过对比多个BLOCKED线程的“waiting to lock”和“locked”对象地址很容易就能拼出循环等待链。就像前面2.4节展示的那样。3. 使用jconsole或VisualVM进行可视化监控对于图形界面友好的环境jconsole或更强大的VisualVM是更好的选择。它们可以连接到本地或远程的JVM进程在“线程”选项卡中通常有一个“检测死锁”的按钮一键点击就能可视化地展示出哪些线程陷入了死锁以及它们之间的资源依赖关系图非常直观。3.2 针对特定场景的排查策略死锁不只发生在简单的synchronized代码块里它可能隐藏在框架、数据库连接池、第三方库中。数据库死锁排查 数据库死锁是另一个常见源头。当两个事务以不同顺序更新多张表的多条记录时就可能发生。排查时开启数据库的死锁日志如MySQL的innodb_print_all_deadlocksON。查看数据库错误日志找到死锁发生时的事务信息。分析日志中输出的WAITING FOR THIS LOCK TO BE GRANTED和HOLDS THE LOCK(S)部分理清事务间的等待关系。解决方案同样是保证应用层以相同的顺序访问表记录或使用更小的事务粒度。使用Grafana等监控工具辅助排查Java死锁/OOM 单纯的jstack是事后分析。对于线上系统我们需要监控和预警。可以将jstack的定期执行与监控平台结合。脚本化定期采集编写一个Shell脚本定时如每分钟执行jstack并利用grep分析输出中BLOCKED线程的数量或直接搜索死锁特征。如果超过阈值则发出告警。与Prometheus/Grafana集成通过JMX暴露JVM的Threading相关MBean如java.lang:typeThreading的ThreadCount、DaemonThreadCount以及自定义的DeadlockCount——如果你通过程序检测到的话。Prometheus抓取这些指标在Grafana中绘制图表并设置告警规则。当BLOCKED线程数持续增长或长时间不释放时就能提前发现问题苗头。结合OOM排查死锁可能导致线程堆积间接引发内存问题。监控jmap -histo或jstat -gc的输出观察老年代内存增长是否与线程数增长相关。Grafana面板上同时展示线程数、堆内存使用率、GC次数能帮你建立关联性分析。排查中的注意事项多次采样死锁可能不是持续存在的或者转储的瞬间可能捕捉不到。建议在问题发生时连续执行多次jstack如间隔5秒执行3次对比分析。关注“Ownable Synchronizers”在使用java.util.concurrent.locks包下的锁如ReentrantLock时线程转储中这部分信息很重要它显示了Lock对象的具体持有者。结合业务日志将线程转储中的线程名如果设置了有意义的名称与业务日志中的上下文关联起来能更快定位到出问题的代码段和业务场景。4. 高级场景下的死锁预防与最佳实践理解了基本条件和排查方法我们还需要在更复杂的并发设计中将死锁风险降到最低。4.1 线程池与资源管理不当引发的死锁线程池用不好本身就会成为死锁的帮凶。一个经典的陷阱是在同一个线程池中提交有依赖关系的任务。场景模拟 假设我们有一个固定大小为2的线程池。我们向池中提交了任务A和任务B。任务A内部又需要提交一个子任务C到同一个线程池并等待其结果例如使用Future.get()。如果任务B长时间运行不结束那么线程池的两个线程都被占用A和B。任务A在等待子任务C完成但子任务C因为线程池已满永远得不到执行。于是任务A永远等下去形成了线程池内部的资源死锁。解决方案使用不同的线程池将相互独立的任务和存在父子依赖关系的任务隔离到不同的线程池中。使用无界队列需谨慎ThreadPoolExecutor使用无界队列如LinkedBlockingQueue时可能会掩盖资源耗尽的问题但依赖任务死锁的风险依然存在。避免在任务内等待同一池中的其他任务这是根本。如果必须等待考虑使用CompletableFuture等更灵活的异步编程模型或者确保线程池大小足以处理这种嵌套。Fork/Join框架的特别说明 你提到的热词“fork join介绍 里面线程1结束之后 执行fork join后面的内容 此时线程2还在运行”这描述了Fork/Join框架的工作窃取Work-Stealing机制。一个线程比如线程1完成了自己的任务后不会闲着它会去“偷”其他线程队列里未执行的任务来执行。这种机制本身是为了提高效率但它也可能引入复杂的依赖。在Fork/Join中如果任务设计不当比如一个任务在join()等待其子任务时又需要获取某个被其他任务可能是被“偷”去执行的任务持有的锁同样可能引发死锁。因此在Fork/Join任务中也应遵循资源有序获取等原则尽量减少甚至避免在分解的子任务中使用阻塞锁。4.2 锁的粒度与范围优化锁的粒度太粗会增加竞争降低性能但锁的粒度设计不当也可能增加死锁的概率。缩小锁范围尽可能只锁住共享数据被访问和修改的最小代码段尽快释放锁。这减少了锁持有的时间也就缩短了其他线程可能等待的时间窗口降低了死锁发生的概率。// 不推荐锁住整个方法范围太大 public synchronized void processBigData() { // 步骤1读取数据无需同步 // 步骤2修改共享变量需要同步 // 步骤3写入文件无需同步 } // 推荐只锁住必要的部分 public void processBigData() { // 步骤1读取数据无需同步 synchronized (this) { // 步骤2修改共享变量需要同步 } // 步骤3写入文件无需同步 }使用线程安全的数据结构很多时候我们加锁只是为了保护一个HashMap或ArrayList。Java并发包提供了ConcurrentHashMap、CopyOnWriteArrayList等高效线程安全的容器。使用它们可以消除很多显式加锁的代码从根本上避免因锁顺序问题导致的死锁。4.3 尝试锁与超时机制这是破坏“请求与保持”和“不剥夺”条件的工程化手段。与其一直阻塞等待不如“尝试一下不行就撤”。使用ReentrantLock.tryLock()private final ReentrantLock lock1 new ReentrantLock(); private final ReentrantLock lock2 new ReentrantLock(); public boolean tryTransfer() { // 尝试获取第一个锁 if (!lock1.tryLock()) { return false; // 获取失败立即返回不阻塞 } try { // 尝试获取第二个锁带超时 if (!lock2.tryLock(1, TimeUnit.SECONDS)) { // 获取第二个锁超时释放第一个锁避免持有等待 lock1.unlock(); return false; } try { // 成功获取两把锁执行业务逻辑 doBusiness(); return true; } finally { lock2.unlock(); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); lock1.unlock(); // 发生中断也释放锁 return false; } finally { // 注意第一个锁的解锁在更外层的finally确保异常时释放 // 但这里因为内层失败时已手动解锁需要小心处理。更好的模式见下文。 } }更健壮的模板上面的代码在异常处理上有些复杂。一个更好的模式是“回退重试”或者使用一个工具方法来统一管理多个锁的尝试获取。public boolean acquireLocks(Lock firstLock, Lock secondLock) { boolean acquiredFirst false; boolean acquiredSecond false; try { acquiredFirst firstLock.tryLock(100, TimeUnit.MILLISECONDS); if (!acquiredFirst) { return false; } acquiredSecond secondLock.tryLock(100, TimeUnit.MILLISECONDS); if (!acquiredSecond) { return false; } return true; // 两个锁都获取成功 } catch (InterruptedException e) { Thread.currentThread().interrupt(); return false; } finally { // 如果没成功获取第二个锁释放第一个锁 if (!acquiredSecond acquiredFirst) { firstLock.unlock(); } // 如果任何地方失败确保状态干净 if (!(acquiredFirst acquiredSecond)) { // 清理逻辑 } } }使用超时机制给了线程一个“放弃”的机会。当获取锁失败时线程可以释放已持有的资源破坏“请求与保持”记录日志进行重试或者执行降级逻辑而不是无限期地等下去这极大地提高了系统的健壮性。5. 不同编程语言与生态中的死锁考量死锁是一个跨语言的通用并发问题但在不同语言和其生态中表现形式和应对工具略有不同。5.1 C/C中的死锁排查C/C由于更接近系统层且内存、锁需要手动管理死锁风险更高排查也更依赖系统工具。工具在Linux下gdb调试器是核心。可以使用thread apply all bt命令打印所有线程的调用栈。结合pstack pid命令也能快速查看线程堆栈。对于使用pthread库的程序要仔细检查pthread_mutex_lock的调用顺序。特点C11引入了mutex、atomic等标准库提供了std::lock、std::try_lock等可以一次性锁定多个互斥量且避免死锁的实用函数其原理就是内部实现了“资源有序分配”或“尝试回退”算法。务必使用这些现代C并发设施而不是手动操作原生锁。排查难点没有JVM那样统一的运行时和jstack这样的神器更需要依赖核心转储core dump和事后分析。5.2 Python (threading) 中的死锁Python由于存在全局解释器锁GIL通常认为多线程无法实现真正的并行计算。但GIL只保护了解释器状态和内存管理对于用户自定义的锁threading.Lock和涉及I/O的操作线程仍然会切换因此死锁问题同样存在。Python的threading模块提供的锁也是不可重入的threading.RLock是可重入锁死锁条件完全适用。排查时可以使用faulthandler模块或sys._current_frames()来获取线程状态。5.3 数据库事务中的死锁这是另一个重灾区。如前所述解决方案包括保持一致的访问顺序在应用层代码中确保所有业务逻辑在更新多个表时都按照相同的顺序例如按表名字母顺序或按业务主次顺序进行。减小事务粒度尽快提交事务缩短锁持有的时间。将大事务拆分成多个小事务。使用较低的隔离级别如读已提交Read Committed可以避免很多间隙锁Gap Lock导致的死锁但需要评估对数据一致性的影响。重试机制在应用代码中捕获数据库抛出的死锁错误如MySQL的1213错误码并进行有限次数的重试。5.4 前端与客户端开发中的“死锁”虽然JavaScript是单线程的不存在传统意义上的线程死锁但在异步编程中存在类似的“回调地狱”或“Promise链僵局”。例如两个异步操作互相等待对方的结果才能解析自己的Promise。这更多是逻辑设计问题。使用async/await编写清晰的顺序逻辑并仔细梳理异步任务间的依赖关系可以避免此类问题。6. 设计阶段规避死锁的系统性思考最好的死锁处理是在设计和代码审查阶段就将其扼杀。1. 静态代码分析工具集成SonarQube、FindBugs/SpotBugs等工具到CI/CD流程中。这些工具内置了检测潜在死锁模式的规则如“两个方法以不同顺序获取相同的两个锁”能在代码提交前就发出警告。2. 代码审查清单在团队代码审查中将并发代码作为重点。审查时自问这段代码涉及几个锁所有路径上锁的获取顺序是否一致资源有序分配锁的范围是否最小化是否存在嵌套锁嵌套顺序是否可能形成环是否可以使用线程安全容器替代显式锁是否考虑了超时和中断3. 架构设计层面减少共享状态这是解决并发问题的根本之道。考虑能否使用无状态设计、Actor模型如Akka、或将状态封装到单个线程中线程封闭技术。使用更高级的并发抽象如java.util.concurrent包中的CyclicBarrier、CountDownLatch、Semaphore等它们封装了复杂的同步逻辑比自己操作锁更安全。异步非阻塞对于I/O密集型应用考虑使用Netty、Vert.x等异步框架或CompletableFuture、反应式流Reactive Streams将线程从阻塞等待中解放出来减少线程因等待资源而阻塞的场景从而降低死锁风险。死锁就像并发世界里的一个幽灵理解它产生的四个条件——互斥、请求与保持、不剥夺、循环等待——是我们对抗它的第一道防线。通过有序分配资源、使用尝试锁与超时、缩小锁范围、利用现代并发工具等实践我们可以在很大程度上预防它。而当问题真的出现时熟练使用jstack、线程转储分析、数据库日志等工具进行排查则是我们快速恢复服务的保障。记住并发编程没有银弹保持对锁的敬畏在设计和编码时多思考一步就能让我们的系统更加稳健。在我经历的那次事故后团队引入了强制性的锁顺序规范和代码扫描类似的问题再也没出现过。这或许就是踩坑带来的最大价值。
