当前位置：首页 > news >正文

多智能体系统的死锁预防：资源分配与超时机制设计

news 2026/6/15 1:33:32

多智能体系统的死锁预防：资源分配与超时机制设计

摘要/引言

开门见山（Hook）

你有没有遇到过这样的场景：在一个多人协作的游戏大厅里，玩家A等着玩家B让出来的“武器升级权限”，玩家B等着玩家C的“金币解锁槽”，玩家C又刚好攥着解锁槽不放、死死盯着玩家A刚抢到的“稀有图纸兑换卡”——大厅里所有准备打团的核心玩家就这么静止不动，游戏的整个协作流程彻底卡壳？

如果把这个游戏里的“玩家”换成自主决策的软件/硬件智能体（Agent），“武器升级权限、金币槽、兑换卡”换成系统中的共享资源，那这个“卡壳”的场景，就是计算机科学与分布式系统领域大名鼎鼎的——死锁（Deadlock）。

问题陈述（Problem Statement）

在单智能体系统（比如你电脑上运行的单个Word文档）里，资源的申请和释放大多是“串行化”或“单一线程/进程主导调度”的，死锁风险极低；但在多智能体系统（Multi-Agent System, MAS）——从工业机器人集群的协作搬运，到自动驾驶车队的路口交叉通过，再到云原生微服务架构下的跨服务资源调用——这类系统中，智能体的自主性（Autonomy）、异步性（Asynchrony）、分布性（Distribution）和资源的共享性（Shared Resources）三大核心特性，让死锁的发生概率呈指数级上升，一旦发生，轻则导致系统部分功能失效、响应延迟飙升，重则引发整个生产/服务系统的崩溃，造成不可估量的经济损失甚至安全事故（比如工业机器人集群在搬运易燃易爆品时死锁，可能错过最佳的冷却/转移窗口）。

目前，业界处理多智能体系统死锁的方法主要分为三类：

死锁避免（Deadlock Avoidance）：比如经典的银行家算法，但这种方法需要智能体提前声明所有的资源需求，对于自主性强、环境动态多变的MAS（比如无人车不知道下一秒会不会遇到临时施工需要抢占应急车道）几乎不可行；
死锁检测与恢复（Deadlock Detection & Recovery）：定期或触发式地扫描系统的资源等待图，发现死锁后通过“抢占资源、终止智能体、回滚操作”等方式打破死锁——这种方法虽然灵活，但恢复成本极高，且可能引入新的不一致性（比如无人车终止后可能会停在路中间，反而造成更大的交通拥堵）；
死锁预防（Deadlock Prevention）：通过改变智能体的行为规则或设计合理的资源分配策略，从根源上破坏死锁发生的四个必要条件（互斥、请求与保持、不可剥夺、循环等待），让死锁永远不可能发生——这种方法虽然会牺牲一定的系统吞吐量或智能体的自主性，但稳定性和可靠性最高，完全符合工业级/企业级多智能体系统的核心需求。

本文将聚焦于死锁预防这一最稳妥的方法，重点讲解两个最常用且最实用的技术方向：

资源分配机制设计：包括资源编号静态排序法、资源预分配法、分层资源分配法、多副本资源分配法；
超时机制设计：包括请求超时自动放弃法、释放超时资源回收法、自适应超时阈值调整法。

同时，为了让大家能够“学以致用”，本文还会结合云原生微服务电商系统和工业AGV（自动导引车）集群协作系统两个实际的项目案例，详细讲解如何在真实场景中落地这些死锁预防策略，并通过Python代码实现核心的资源分配与超时管理模块，最后分析策略的边界条件、行业发展趋势以及最佳实践。

核心价值（Value Proposition）

读完本文，你将能够：

从理论层面：深入理解死锁发生的四个必要条件，以及不同死锁预防策略的原理、优缺点和数学模型；
从技术层面：掌握资源编号静态排序法、自适应超时阈值调整法等核心死锁预防策略的算法流程和Python实现；
从实践层面：学会在真实的云原生微服务系统和工业AGV集群系统中落地这些策略，并通过性能测试评估策略的效果；
从设计层面：能够根据具体的多智能体系统需求，选择或组合合适的死锁预防策略，平衡系统的稳定性、可靠性和吞吐量。

文章概述（Roadmap）

本文的结构安排如下：

核心概念与问题背景：首先介绍多智能体系统、死锁的基本定义，然后详细分析死锁发生的四个必要条件，最后通过一个简单的AGV集群死锁案例，让大家直观地感受到死锁的危害；
资源分配机制设计：这是本文的第一个核心章节，将依次讲解资源编号静态排序法、资源预分配法、分层资源分配法、多副本资源分配法的原理、算法流程图、数学模型、Python实现、优缺点分析和边界条件；
超时机制设计：这是本文的第二个核心章节，将依次讲解请求超时自动放弃法、释放超时资源回收法、自适应超时阈值调整法的原理、算法流程图、数学模型、Python实现、优缺点分析和边界条件；
概念之间的关系与对比：这一部分将通过Markdown表格对比不同死锁预防策略的核心属性（破坏的必要条件、适用场景、系统吞吐量影响、智能体自主性影响、实现难度、成本），通过Mermaid ER图展示智能体、资源、请求、超时事件之间的实体关系，通过Mermaid交互关系图展示不同死锁预防策略之间的组合使用流程；
实际场景应用与项目案例：这是本文的第三个核心章节，将结合云原生微服务电商库存管理系统和工业AGV集群协作搬运系统两个真实的项目案例，详细讲解项目的背景、需求、环境安装、系统功能设计、系统架构设计、系统接口设计、核心实现源代码以及性能测试结果；
最佳实践Tips：这一部分将分享我在工业界和开源社区多年积累的死锁预防最佳实践，比如如何选择合适的资源分配策略、如何设计自适应的超时阈值、如何组合使用不同的死锁预防策略、如何进行死锁预防的性能测试和监控等；
行业发展与未来趋势：这一部分将通过Markdown表格梳理死锁预防方法的演变发展历史，然后分析死锁预防在边缘计算、元宇宙、生成式AI多智能体协作等新兴领域的应用场景和未来发展趋势；
本章小结：最后，本文将对全文的核心内容进行总结，再次强调死锁预防的重要性，并提出一些开放性的问题，引发大家的讨论。

核心概念与问题背景

1.1 核心概念

在正式讲解死锁预防策略之前，我们需要先明确几个核心概念：多智能体系统、智能体、共享资源、资源申请、资源释放、资源等待图。

1.1.1 多智能体系统（Multi-Agent System, MAS）

多智能体系统是由多个自主决策的智能体组成的分布式系统，这些智能体可以是软件程序（比如云原生微服务、聊天机器人、自动驾驶的决策模块），也可以是硬件设备（比如工业AGV、无人机、智能家居设备）。

根据美国计算机学会（ACM）和电气电子工程师学会（IEEE）联合发布的《多智能体系统规范》（IEEE Std 1900.6-2019），一个多智能体系统必须具备以下三个核心特性：

自主性（Autonomy）：每个智能体都能够在没有外部直接干预的情况下，根据自身的内部状态和感知到的外部环境信息，自主地做出决策和执行动作；
异步性（Asynchrony）：智能体之间的通信和协作是异步的，没有全局的时钟同步机制（或者说全局时钟同步的成本极高，无法在实际系统中大规模使用）；
分布性（Distribution）：智能体可以分布在不同的物理节点或逻辑节点上，每个节点都有自己的计算资源和存储资源；
协作性（Cooperation）/ 竞争性（Competition）：智能体之间可以通过协作来完成单个智能体无法完成的任务（比如AGV集群协作搬运一个重量超过单个AGV承载能力的货物），也可以通过竞争来获取有限的共享资源（比如微服务竞争数据库的连接池资源）。

1.1.2 智能体（Agent）

智能体是多智能体系统中的基本决策和执行单元，根据智能体的决策能力和复杂程度，可以将智能体分为以下几类：

简单反射型智能体（Simple Reflex Agent）：这类智能体的决策规则非常简单，只根据当前感知到的外部环境信息做出决策，不考虑自身的内部状态和历史信息（比如恒温器，当感知到的温度高于设定值时就关闭加热器，低于设定值时就打开加热器）；
基于模型的反射型智能体（Model-Based Reflex Agent）：这类智能体会维护一个内部的“世界模型”，用来记录历史的环境信息和自身的动作，然后根据当前的感知信息和内部的世界模型做出决策（比如自动驾驶的简单决策模块，会记录自己之前的行驶速度和方向，然后结合当前的路况信息做出决策）；
基于目标的智能体（Goal-Based Agent）：这类智能体会设定一个或多个“目标”，然后根据当前的感知信息、内部的世界模型和目标，选择能够最快或最有效地达到目标的动作（比如导航机器人，会设定一个“到达目标位置”的目标，然后结合地图信息和当前的位置信息，规划最优的路径）；
基于效用的智能体（Utility-Based Agent）：这类智能体会给每个可能的动作结果分配一个“效用值”（Utility Value），用来衡量该结果对智能体的“好坏程度”，然后选择效用值最高的动作（比如电商推荐系统的智能体，会给每个推荐的商品分配一个效用值——比如点击率、转化率、销售额，然后选择效用值最高的商品推荐给用户）；
学习型智能体（Learning Agent）：这类智能体会通过不断地与环境交互，学习和优化自己的决策规则、世界模型、目标或效用函数（比如围棋AI AlphaGo，就是通过不断地与自己下棋，学习和优化自己的围棋策略）。

在本文中，我们主要关注基于目标或效用的学习型智能体，因为这类智能体的自主性最强，死锁风险也最高。

1.1.3 共享资源（Shared Resources）

共享资源是指多智能体系统中可以被多个智能体同时或依次使用的有限资源，根据资源的使用方式，可以将共享资源分为以下两类：

可复用资源（Reusable Resources）：这类资源可以被智能体多次使用，使用完毕后会被释放，供其他智能体使用——比如数据库的连接池资源、AGV的行驶路径资源、文件的读写锁资源；
消耗性资源（Consumable Resources）：这类资源只能被智能体使用一次，使用完毕后就会被消耗掉——比如电商系统的库存资源、能源系统的电力资源、通信系统的带宽资源。

在本文中，我们主要关注可复用资源，因为消耗性资源的死锁问题通常可以通过“资源生产”或“资源补充”来解决，而可复用资源的死锁问题则更难处理。

根据资源的排他性，可以将共享资源分为以下两类：

互斥资源（Mutual Exclusion Resources）：这类资源在同一时刻只能被一个智能体使用——比如文件的写锁资源、AGV的单个行驶路径节点资源；
非互斥资源（Non-Mutual Exclusion Resources）：这类资源在同一时刻可以被多个智能体同时使用——比如文件的读锁资源、数据库的只读连接资源、通信系统的广播带宽资源。

在本文中，我们主要关注互斥资源，因为非互斥资源不会导致死锁（死锁的第一个必要条件就是“互斥”）。

1.1.4 资源申请（Resource Request）

资源申请是指智能体向系统的资源管理器（Resource Manager）发送的“请求使用某个或某些共享资源”的消息。

根据申请的资源数量，可以将资源申请分为以下两类：

单资源申请（Single Resource Request）：智能体一次只申请一个共享资源；
多资源申请（Multiple Resource Request）：智能体一次申请多个共享资源。

在本文中，我们主要关注多资源申请，因为单资源申请不会导致死锁（死锁的第三个必要条件虽然不是直接由多资源申请导致的，但多资源申请更容易导致“请求与保持”和“循环等待”）。

1.1.5 资源释放（Resource Release）

资源释放是指智能体使用完毕共享资源后，向系统的资源管理器发送的“释放某个或某些共享资源”的消息。

1.1.6 资源等待图（Resource Wait-for Graph, RWG）

资源等待图是一种用来直观地表示多智能体系统中智能体、资源、请求、释放之间关系的有向图，它是死锁检测和死锁避免的核心工具。

资源等待图由以下两类节点组成：

智能体节点（Agent Node）：用圆形表示，代表系统中的一个智能体；
资源节点（Resource Node）：用矩形表示，代表系统中的一类共享资源（注意：如果一类资源有多个副本，通常会用一个矩形加多个小圆圈表示，或者用矩形中的数字表示副本的数量）。

资源等待图由以下两类有向边组成：

请求边（Request Edge）：从智能体节点指向资源节点，表示该智能体正在请求该类资源；
分配边（Allocation Edge）：从资源节点指向智能体节点，表示该类资源已经被分配给了该智能体。

资源等待图的一个重要性质是：如果资源等待图中存在环（Cycle），那么系统中可能存在死锁；如果系统中的所有共享资源都是互斥且单副本的，那么资源等待图中存在环是系统存在死锁的充要条件。

为了让大家更直观地理解资源等待图，我们来看一个简单的例子：

假设系统中有两个智能体（Agent A、Agent B）和两类互斥且单副本的共享资源（Resource R1、Resource R2）：

Agent A已经被分配了Resource R1（存在一条从R1指向A的分配边），正在请求Resource R2（存在一条从A指向R2的请求边）；
Agent B已经被分配了Resource R2（存在一条从R2指向B的分配边），正在请求Resource R1（存在一条从B指向R1的请求边）。

对应的资源等待图如下：

很明显，这个资源等待图中存在一个环：A → R2 → B → R1 → A，因此系统中存在死锁——Agent A和Agent B都在等待对方释放自己需要的资源，永远不会主动释放自己已经分配到的资源，系统的整个流程彻底卡壳。

1.2 问题背景

死锁的概念最早是由荷兰计算机科学家Edsger W. Dijkstra在1965年发表的论文《Cooperating Sequential Processes》中提出的，当时他研究的是单处理器多进程系统中的死锁问题；随着计算机技术的发展，死锁问题逐渐扩展到了分布式系统、数据库系统、操作系统、多智能体系统等多个领域。

在单处理器多进程系统中，资源的数量通常是有限的（比如内存、CPU时间片、文件描述符），进程的调度是由操作系统统一管理的，因此死锁的发生概率相对较低，处理起来也相对容易（比如银行家算法在单处理器多进程系统中就有一定的应用场景）；但在多智能体系统中，情况则完全不同：

1.2.1 环境动态多变

多智能体系统的外部环境通常是动态多变的——比如工业AGV集群的车间环境可能会出现临时的货物掉落、设备故障，无人车的道路环境可能会出现临时的施工、行人横穿马路——这些动态变化的环境会导致智能体的资源需求发生变化，比如AGV可能需要临时抢占一条备用的行驶路径，无人车可能需要临时抢占应急车道。

在这种情况下，银行家算法这种需要智能体提前声明所有资源需求的死锁避免方法几乎不可行，因为智能体根本无法预测未来的环境变化和资源需求。

1.2.2 智能体自主性强

多智能体系统中的智能体通常是自主决策的——比如云原生微服务架构下的每个微服务都是由不同的团队开发和维护的，有自己的决策规则和目标，无法被其他微服务或系统的资源管理器直接干预——这些自主决策的智能体可能会为了自己的利益，一直保持已经分配到的资源，同时不断请求新的资源，从而导致死锁的发生。

在这种情况下，死锁检测与恢复方法虽然灵活，但恢复成本极高——比如终止一个正在处理用户支付请求的支付微服务，可能会导致用户的支付失败，造成用户流失和经济损失；抢占一个正在搬运易燃易爆品的AGV的行驶路径，可能会导致AGV无法及时到达目的地，错过最佳的冷却/转移窗口，造成安全事故。

1.2.3 资源数量有限且分布分散

多智能体系统中的共享资源通常是数量有限且分布分散的——比如云原生微服务架构下的数据库连接池资源可能分布在不同的数据库节点上，工业AGV集群的行驶路径资源可能分布在不同的车间区域上——这些分布分散的资源会导致资源管理器的调度难度大幅增加，同时也会增加死锁的发生概率。

1.2.4 异步通信延迟高

多智能体系统中的智能体之间的通信通常是异步的，且通信延迟可能会很高——比如云原生微服务架构下的跨区域微服务通信延迟可能会达到几百毫秒甚至几秒，工业AGV集群中的无线通信延迟可能会受到车间环境的干扰而变得不稳定——这些高延迟、不稳定的异步通信会导致资源管理器的状态信息更新不及时，从而增加死锁的发生概率（比如资源管理器可能还没有收到某个智能体释放资源的消息，就已经将该资源分配给了另一个智能体，或者资源管理器可能还没有收到某个智能体的资源请求消息，就已经认为该智能体处于空闲状态）。

1.3 问题描述

在详细讲解死锁预防策略之前，我们需要先明确死锁发生的四个必要条件——这四个条件是由Dijkstra在1971年提出的，并且被Coffman, Elphick, Shoshani在1971年发表的论文《System Deadlocks》中严格证明了：只有当这四个条件同时满足时，系统才会发生死锁；只要破坏其中的任何一个条件，死锁就永远不可能发生。

这四个必要条件分别是：

1.3.1 互斥条件（Mutual Exclusion）

互斥条件是指同一时刻，一类互斥且单副本的共享资源只能被一个智能体使用；如果有其他智能体请求该资源，那么请求的智能体必须等待，直到该资源被释放。

互斥条件是共享资源的固有属性，我们无法完全破坏它（比如文件的写锁资源必须是互斥的，否则会导致数据不一致；AGV的单个行驶路径节点资源必须是互斥的，否则会导致AGV碰撞）；但我们可以通过引入多副本资源或使用非互斥的资源访问方式（比如乐观锁）来削弱互斥条件，从而降低死锁的发生概率。

1.3.2 请求与保持条件（Hold and Wait）

请求与保持条件是指智能体已经保持了至少一个共享资源，同时又在请求新的共享资源，而新的共享资源已经被其他智能体占用，因此请求的智能体必须等待，但在等待的过程中，它不会释放自己已经保持的共享资源。

破坏请求与保持条件的方法主要有两种：

资源预分配法（Resource Preallocation）：要求智能体在开始执行任务之前，一次性申请并获得所有需要的共享资源；如果无法一次性获得所有需要的资源，那么智能体就不开始执行任务，也不占用任何资源；
请求时释放所有资源法（Release All Resources When Requesting）：要求智能体在请求新的共享资源之前，必须先释放自己已经保持的所有共享资源；如果请求失败，那么智能体可以重新申请之前释放的资源和新的资源。

1.3.3 不可剥夺条件（No Preemption）

不可剥夺条件是指智能体已经保持的共享资源不能被其他智能体或系统的资源管理器强行剥夺，只能由智能体自己主动释放。

破坏不可剥夺条件的方法主要有两种：

资源剥夺法（Resource Preemption）：如果智能体请求的共享资源已经被其他智能体占用，那么系统的资源管理器可以强行剥夺占用该资源的智能体的资源，分配给请求的智能体；被剥夺资源的智能体会进入等待状态，直到它重新获得所有需要的资源；
超时资源回收法（Timeout Resource Reclamation）：系统的资源管理器会给每个分配出去的共享资源设置一个“释放超时阈值”；如果智能体在释放超时阈值内没有释放该资源，那么系统的资源管理器会强行剥夺该资源，分配给其他请求的智能体；被剥夺资源的智能体会进入等待状态，或者重新执行任务。

需要注意的是，资源剥夺法和超时资源回收法虽然可以破坏不可剥夺条件，但它们都可能会引入新的不一致性——比如剥夺一个正在处理用户支付请求的支付微服务的数据库连接资源，可能会导致用户的支付数据只部分写入数据库，造成数据不一致；剥夺一个正在搬运货物的AGV的行驶路径资源，可能会导致AGV停在路中间，货物掉落，造成损失。

1.3.4 循环等待条件（Circular Wait）

循环等待条件是指系统中存在一个由两个或两个以上的智能体组成的环，环中的每个智能体都在等待环中下一个智能体已经保持的共享资源。

破坏循环等待条件的方法主要有两种：

资源编号静态排序法（Static Resource Numbering and Ordering）：给系统中的所有共享资源分配一个唯一的、静态的编号；要求智能体在申请共享资源时，必须按照编号的递增顺序（或递减顺序）申请；如果智能体需要申请编号比自己已经保持的资源的编号小的资源，那么它必须先释放所有编号比该资源大的资源，然后再按照递增顺序申请；
分层资源分配法（Hierarchical Resource Allocation）：将系统中的所有共享资源按照功能或优先级分成不同的层次；要求智能体在申请共享资源时，必须先申请低层次的资源，然后再申请高层次的资源；同一层次的资源可以按照任意顺序申请，或者按照资源编号静态排序法申请；智能体在释放资源时，必须先释放高层次的资源，然后再释放低层次的资源。

1.4 简单的AGV集群死锁案例

为了让大家更直观地感受到死锁的危害，我们来看一个简单的工业AGV集群协作搬运系统的死锁案例：

1.4.1 案例背景

假设我们有一个小型的电子制造车间，车间里有：

2台AGV：AGV A和AGV B，它们的承载能力都是100kg；
2个工位：工位1（用于组装电子产品的主板）和工位2（用于组装电子产品的外壳）；
2条互斥且单副本的行驶路径：
- 路径R1：从工位1到工位2；
- 路径R2：从工位2到工位1；
1个任务：将工位1上的一块50kg的主板运到工位2，然后将工位2上的一个50kg的外壳运到工位1。

1.4.2 任务分配

为了提高效率，我们将任务分成了两个子任务，分别分配给AGV A和AGV B：

子任务1（分配给AGV A）：将工位1上的主板运到工位2（需要使用路径R1）；
子任务2（分配给AGV B）：将工位2上的外壳运到工位1（需要使用路径R2）。

1.4.3 死锁发生过程

假设AGV A和AGV B同时开始执行自己的子任务：

时间点T1：AGV A到达工位1，成功申请到路径R1的入口节点，开始沿着路径R1向工位2行驶；
时间点T2：AGV B到达工位2，成功申请到路径R2的入口节点，开始沿着路径R2向工位1行驶；
时间点T3：AGV A行驶到路径R1和路径R2的交叉节点C（交叉节点C是路径R1和路径R2的公共节点，属于互斥且单副本的共享资源），AGV A需要申请交叉节点C才能继续行驶；
时间点T4：AGV B行驶到路径R2和路径R1的交叉节点C，AGV B也需要申请交叉节点C才能继续行驶；
时间点T5：AGV A先向系统的资源管理器发送了申请交叉节点C的请求，但此时交叉节点C还没有被任何AGV占用——等等，这里好像有问题？哦，不对，我刚才的案例设计有点问题，让我重新调整一下：

1.4.4 修正后的死锁发生过程

为了让死锁更容易发生，我们将任务和行驶路径调整一下：

AGV的任务：
- AGV A：先去工位1取主板（需要使用路径R1a：从起点A1到工位1），然后去工位2放主板（需要使用路径R1b：从工位1到交叉节点C，再到工位2），最后回到起点A1（需要使用路径R1c：从工位2到起点A1）；
- AGV B：先去工位2取外壳（需要使用路径R2a：从起点B1到工位2），然后去工位1放外壳（需要使用路径R2b：从工位2到交叉节点C，再到工位1），最后回到起点B1（需要使用路径R2c：从工位1到起点B1）；
行驶路径的节点：
- 路径R1a的节点：A1 → N1；
- 路径R1b的节点：N1 → C → N2；
- 路径R1c的节点：N2 → A1；
- 路径R2a的节点：B1 → N2；
- 路径R2b的节点：N2 → C → N1；
- 路径R2c的节点：N1 → B1；
- 所有的节点（A1、B1、N1、N2、C）都是互斥且单副本的共享资源。

现在，AGV A和AGV B同时开始执行自己的子任务：

时间点T1：AGV A成功申请到节点A1，开始沿着路径R1a行驶；AGV B成功申请到节点B1，开始沿着路径R2a行驶；
时间点T2：AGV A到达节点N1，成功申请到节点N1，释放节点A1；AGV B到达节点N2，成功申请到节点N2，释放节点B1；
时间点T3：AGV A开始执行子任务的第二步（去工位2放主板），需要申请路径R1b的下一个节点C；AGV A向资源管理器发送了申请节点C的请求；
时间点T4：几乎同时，AGV B开始执行子任务的第二步（去工位1放外壳），需要申请路径R2b的下一个节点C；AGV B向资源管理器发送了申请节点C的请求；
时间点T5：资源管理器先收到了AGV A的请求，将节点C分配给了AGV A（存在一条从C指向A的分配边）；AGV A收到分配成功的消息后，继续沿着路径R1b行驶，到达节点C；
时间点T6：资源管理器收到了AGV B的请求，但此时节点C已经被AGV A占用，因此AGV B必须等待（存在一条从B指向C的请求边）；
时间点T7：AGV A到达节点C后，需要申请路径R1b的下一个节点N2才能继续行驶到工位2；AGV A向资源管理器发送了申请节点N2的请求；
时间点T8：资源管理器收到了AGV A的请求，但此时节点N2已经被AGV B占用（AGV B正在等待节点C，不会释放节点N2），因此AGV A必须等待（存在一条从A指向N2的请求边）；

现在，我们来看一下系统的资源等待图：