产生死锁的原因主要是：
发生死锁的四个必要条件：
如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。其次，进程运行推进顺序与速度不同，也可能产生死锁。
死锁预防：通过设置某些限制条件，去破坏死锁的四个条件中的一个或几个条件，来预防发生死锁。但由于所施加的限制条件往往太严格，因而导致系统资源利用率和系统吞吐量降低。
死锁避免：允许前三个必要条件，但通过明智的选择，确保永远不会到达死锁点，因此死锁避免比死锁预防允许更多的并发。
死锁检测：不须实现采取任何限制性措施，而是允许系统在运行过程发生死锁，但可通过系统设置的检测机构及时检测出死锁的发生，并精确地确定于死锁相关的进程和资源，然后采取适当的措施，从系统中将已发生的死锁清除掉。
死锁解除：与死锁检测相配套的一种措施。当检测到系统中已发生死锁，需将进程从死锁状态中解脱出来。常用方法：撤销或挂起一些进程，以便回收一些资源，再将这些资源分配给已处于阻塞状态的进程。死锁检测盒解除有可能使系统获得较好的资源利用率和吞吐量，但在实现上难度也最大。
在程序运行之前预防发生死锁：防死锁算法可确保至少一种必要条件（互斥，保留和等待，无抢占和循环等待）不成立。但是，大多数预防算法的资源利用率很低，因此导致吞吐量降低。
两种死锁避免算法：
如您所见，大多数预防算法的资源利用率很低，因此导致吞吐量降低。相反，我们可以尝试通过使用有关进程对资源使用的先验知识来避免死锁，这些知识包括可用资源，分配的资源，将来的请求以及将来的进程发布。
大多数避免死锁算法都需要每个进程预先告知可能需要的每种类型的最大资源数量。根据所有这些信息，我们可以决定进程是否应该等待资源，从而避免循环等待的机会。
避免死锁算法会尽量避免为进程分配资源，否则会导致系统处于不安全状态。 由于在某些情况下不会立即进行资源分配，因此避免死锁算法还存在资源利用率低的问题。
安全状态 定义：如果没有死锁发生，并且即使所有进程突然请求对资源的最大需求，也仍然存在某种调度次序能够使得每一个进程运行完毕，则称该状态是安全的。安全的流程顺序和资源分配可确保安全状态。
通常我们可以使用资源分配图来避免死锁。如果资源分配图中没有周期，则没有死锁。如果存在周期，则可能出现死锁。如果每种资源只有一个实例，则一个循环意味着出现死锁。资源分配图的顶点是资源和过程。资源分配图具有请求边缘和分配边缘。从进程到资源的边缘是请求边缘，从资源到进程的边缘是分配边缘。平滑的边缘表示将来可能会提出请求，并以虚线表示。基于平滑的边缘，我们可以查看是否有周期的机会，然后批准请求，以使系统再次处于安全状态。
考虑具有平滑边缘的图像，如下所示：
如果将R2分配给p2，并且如果P1请求R2，则将出现死锁。P1占据着R1等待着R2，P2占据着R2等待着R1。
如果一个资源有多个实例，则资源分配图不是很有用。在这种情况下，我们可以使用Banker算法。在此算法中，每个进程必须预先告知所需的每种类型的最大资源，并以每种类型的最大可用实例为准。只有在分配确保安全状态的情况下，才进行资源分配。否则流程需要等待。
Banker的算法可以分为两部分：•安全算法（如果系统是否处于安全状态）。资源请求算法假设分配，并查看系统是否处于安全状态。如果新状态不安全，则不会分配资源，并且数据结构将还原到其先前状态；在这种情况下，进程必须等待资源。
一个小城镇的银行家，他向一群客户分别承诺了一定的贷款额度，算法要做的是判断对请求的满足是否会进入不安全状态，如果是，就拒绝请求；否则予以分配。
上图 c 为不安全状态，因此算法会拒绝之前的请求，从而避免进入图 c 中的状态。
上图中有五个进程，四个资源。左边的图表示已经分配的资源，右边的图表示还需要分配的资源。最右边的 E、P 以及 A 分别表示：总资源、已分配资源以及可用资源，注意这三个为向量，而不是具体数值，例如 A=(1020)，表示 4 个资源分别还剩下 1/0/2/0。
检查一个状态是否安全的算法如下：
如果一个状态不是安全的，需要拒绝进入这个状态。
安全性算法是由银行家算法改进的其更通用。
安全性算法具体步骤描述，其中 i是进程，j是资源
(1) 设置两个向量： 在执行安全算法开始时，Work∶=Available; Finish［i］:= False;
(2) 从进程集合中找到一个能满足下述条件的进程： ① Finish［i］= False; ② Need［i,j］≤Work［j］；
若找到， 执行步骤(3)， 否则，执行步骤(4)。
(3) 当进程Pi获得资源后，可顺利执行，直至完成，并释放出分配给它的资源，故应执行：
Work［j］∶= Work［j］+ Allocation［i, j］;
Finish［i］∶= true; go to step 2;
(4) 如果所有进程的Finish［i］=true都满足， 则表示系统处于安全状态；否则，系统处于不安全状态。
图 a 的第二列 Has 表示已拥有的资源数，第三列 Max 表示总共需要的资源数，Free 表示还有可以使用的资源数。从图 a 开始出发，先让 B 拥有所需的所有资源（图 b，Has:2+2 因为A与C Max-Has>Free ），运行结束后释放 B，此时 Free 变为 5（图 c，B占用的资源释放）；接着以同样的方式运行 C 和 A，使得所有进程都能成功运行，因此可以称图 a 所示的状态时安全的。
安全状态的检测与死锁的检测类似，因为安全状态必须要求不能发生死锁。下面的银行家算法与死锁检测算法非常类似，可以结合着做参考对比。
不试图阻止死锁，而是当检测到死锁发生时，采取措施进行恢复。
把头埋在沙子里，假装根本没发生问题。
因为解决死锁问题的代价很高，因此鸵鸟策略这种不采取任务措施的方案会获得更高的性能。
当发生死锁时不会对用户造成多大影响，或发生死锁的概率很低，可以采用鸵鸟策略。
大多数操作系统，包括 Unix，Linux 和 Windows，处理死锁问题的办法仅仅是忽略它。
上图为资源分配图，其中方框表示资源，圆圈表示进程。资源指向进程表示该资源已经分配给该进程，进程指向资源表示进程请求获取该资源。
图 a 可以抽取出环，如图 b，它满足了环路等待条件，因此会发生死锁。
每种类型一个资源的死锁检测算法是通过检测有向图是否存在环来实现，从一个节点出发进行深度优先搜索，对访问过的节点进行标记，如果访问了已经标记的节点，就表示有向图存在环，也就是检测到死锁的发生。
上图中，有三个进程四个资源，每个数据代表的含义如下：
进程 P1 和 P2 所请求的资源都得不到满足，只有进程 P3 可以，让 P3 执行，之后释放 P3 拥有的资源，此时 A = (2 2 2 0)。P2 可以执行，执行后释放 P2 拥有的资源，A = (4 2 2 1) 。P1 也可以执行。所有进程都可以顺利执行，没有死锁。
算法总结如下：
每个进程最开始时都不被标记，执行过程有可能被标记。当算法结束时，任何没有被标记的进程都是死锁进程。
参考文献：CSDN-邪三一、Github-CyC2018
