扫码获取 VIP 码
添加管理员微信获取 VIP 码
死锁（Deadlock）是指两个或两个以上的并发进程在执行过程中，因争夺共享资源而造成的一种相互等待的现象——每个进程都在等待其他进程释放其所需要的资源，而这些资源恰好被正在等待的进程所持有，导致所有相关进程都无法继续向前推进。在操作系统的并发控制理论中，死锁是与进程同步、互斥同等重要的核心概念，也是软考系统架构设计师和软件设计师考试中的高频考点。
死锁的定义可以从两个层面来理解。从现象层面看，死锁表现为一组进程中的每一个都在无限期地等待同组中另一个进程释放资源，形成闭环的等待链条。从资源分配层面看，死锁是操作系统资源分配策略不当所导致的一种永久性阻塞状态——如果没有外部干预（如操作系统强制撤销某个进程或剥夺其资源），这组进程将永远无法自行解除阻塞状态。在现实世界的交通系统中也有生动的类比：四辆汽车同时到达一个十字路口的四个方向，每辆车都在等待其他车辆先通过，结果谁也动不了，这就是典型的死锁场景。
理解死锁的关键在于把握它的四个必要条件，这四个条件是死锁发生的充要条件——只有四个条件同时满足时，死锁才可能发生。第一个条件是互斥条件，即资源在任意时刻只能被一个进程使用，其他请求该资源的进程必须等待。第二个条件是请求和保持条件，即进程已经保持了至少一个资源，同时又在请求新的资源，而该资源已被其他进程占用，此时该进程进入阻塞等待状态但不释放已持有的资源。第三个条件是不可抢占条件，即进程已获得的资源在使用完毕之前不能被强行剥夺，只能由进程自身主动释放，操作系统无权强制收回。第四个条件是循环等待条件，即存在一组进程形成闭合的等待链，P0等待P1释放资源，P1等待P2释放资源，以此类推，Pn又等待P0释放资源，每个进程都在等待下一个进程所持有的资源。这四个条件分别对应了死锁形成的四个环节，打破其中任意一个条件就可以预防死锁的发生——这也正是死锁预防策略的理论基础。
死锁预防是一种静态的死锁处理策略，它的核心思想是在系统设计阶段就采取措施，确保死锁的四个必要条件中至少有一个永远无法成立，从而在源头上消除死锁发生的可能性。死锁预防不需要在运行时做动态判断，实现开销相对较低，但代价是降低了系统的资源利用率和并发度。
破坏互斥条件的思路是让资源可以被多个进程同时共享使用。然而这一条件在大多数情况下是不可破坏的，因为很多资源的本质属性决定了它们必须被互斥访问——打印机在同一时刻只能执行一个打印任务，文件的写操作不能与读操作并发执行，数据库记录的更新需要加排他锁。2024年下半年系统架构设计师真题第1题正是考察这个知识点：题目列出四个选项分别对应破坏循环等待、不可抢占、互斥和请求保持四种条件，要求选出"不能作为预防死锁措施"的一项。正确答案是破坏互斥条件。这道题考察的不仅是死锁四个条件的记忆，更是对"互斥是由资源本身性质决定的"这一深层原理的理解。互斥条件能否被破坏，不取决于操作系统设计者的意愿，而取决于资源类型的物理和逻辑属性——对于不可共享的资源，互斥是无法被消除的。
破坏请求和保持条件的策略是要求进程在开始执行之前一次性申请它所需要的全部资源，这种策略也被称为"全部分配"策略。如果所有资源都可以获得，进程开始执行并持有所有所需资源直至运行结束；如果有任何资源暂时无法获得，进程不持有任何资源，进入等待状态直到全部资源同时可用。这种策略的优点是实现简单，且一旦进程开始运行就不会因资源请求而阻塞。缺点体现在两个方面：一是资源利用率低——进程可能在运行初期就占用了直到运行末期才需要的资源，导致这些资源长期闲置而其他进程无法使用；二是许多进程无法在运行前预知它们将需要的全部资源，例如交互式程序在不同用户输入下可能需要不同的资源组合。
破坏不可抢占条件的思路是允许操作系统强行从进程中剥夺资源。当一个进程请求的资源暂时不可用时，操作系统可以检查该进程已持有的资源中哪些可以安全地被剥夺，然后将这些资源分配给等待它们的其他进程。这种策略适用于状态可以保存和恢复的资源类型，如CPU寄存器和内存页面——当操作系统将CPU从一个进程切换到另一个进程时，本质就是在不可抢占的CPU资源上实现了"可抢占"的调度。但对于打印机、磁带机这类资源，如果中途剥夺会导致输出结果混乱，因此不可抢占条件同样不是对所有资源类型都能被破坏的。
破坏循环等待条件的策略是对所有资源类型进行线性排序，要求每个进程只能按照递增的顺序申请资源。例如，将系统中所有资源类型编号为R1、R2、R3直到Rn，规定进程必须先申请编号较小的资源再申请编号较大的资源，禁止先申请大编号资源再回头申请小编号资源。在数学上可以证明，所有进程都遵守资源申请递增序时，不可能存在循环等待环。反证法如下：假设存在循环等待，则环中存在进程Pa持有Ri等待Rj，同时存在进程Pb持有Rj等待Ri。由于Pa按递增序申请，必有i小于j；由于Pb也按递增序申请，必有j小于i。i小于j且j小于i不可能同时成立，故假设不成立。这种策略在数据库管理系统中有广泛应用，层次锁协议就是按照数据库、表、页、行的层次顺序获取锁，从而在协议层面消除了循环等待的可能性。
死锁避免是一种动态的死锁处理策略，它不像死锁预防那样彻底禁止可能导致死锁的条件，而是在系统运行过程中，每当有进程申请资源时，操作系统先进行一次安全性检查——模拟假设分配该资源后系统是否会进入不安全状态。如果分配后系统仍然处于安全状态则批准分配，如果可能进入不安全状态则拒绝分配让进程等待。
银行家算法是实现死锁避免的经典算法，由Dijkstra于1965年提出。算法名称来源于它的设计逻辑与银行贷款审批的类比——银行家只批准在放贷后仍有足够资金应对所有客户最大提款需求的贷款申请，操作系统只批准在分配后系统仍能找到让所有进程顺利完成的完成序列的资源申请。
银行家算法的核心数据结构包括四个向量和矩阵。可用资源向量Available记录系统当前各类资源的空闲数量，它是一个长度为m的一维数组（m为资源类型数）。最大需求矩阵Max记录每个进程对各类资源的最大需求量，它是一个n行m列的二维数组（n为进程数）。已分配矩阵Allocation记录每个进程当前已分配到的各类资源数量，同样是n行m列。需求矩阵Need等于Max减去Allocation的对应项，记录每个进程还需要的各类资源数量。
银行家算法的安全检查过程如下。第一步，设置两个临时变量：Work向量初始化为当前Available，Finish向量初始化为全false。第二步，在Finish为false的进程中查找一个进程Pi，其Need向量的所有分量都小于等于Work向量的对应分量。如果找到这样的进程，将其Finish设为true，并将Allocation向量的对应行加到Work向量上（模拟该进程完成后释放资源）。第三步，重复第二步直到所有进程的Finish都为true（安全状态）或无法再找到符合条件的进程（不安全状态）。在安全检查通过后，操作系统才会正式进行资源分配并更新Available、Allocation和Need三个数据结构。
值得注意的是，不安全状态不等于死锁状态。不安全状态意味着存在某种资源分配序列可能导致死锁，但实际运行中如果运气好（调度顺序恰好避开了死锁路径），系统可能永远不会进入死锁。银行家算法通过拒绝将系统带入不安全状态的资源分配请求来确保死锁不会发生，这是一种保守但安全的策略。
银行家算法也有明显的局限性。一是要求每个进程预先声明
本篇完！