**

死锁

**

  1. 死锁：两个或两个以上的进程出现了永久性阻塞的情况。
    这里我们使用哲学家就餐问题使其简便能够理解
    一个桌子上面有五个哲学家和五把叉子，每个哲学家必须使用左叉子和右叉子才能进餐，桌子上只有五把叉子。
  2. 死锁产生的原因？
（1）资源不够：五个哲学家，需要十把叉子才能完全没有任何阻碍的进食，
	但现实只有五把叉子
	（2）在资源不足的情况下，进程推进顺序不当 。
  1. 死锁产生的四个必要条件

产生的原因

解决方案

互斥条件

打破互斥条件

占用并等待（请求与保持）

资源静态分配

非抢占

抢占

循环等待

资源定序

  1. 死锁解决方案
    ①静态方法----死锁预防
  • 打破互斥条件
哲学家的叉子不能够同时被使用。
  • 资源静态分配：使用信号量集操作 wait（S1,S2…）{}，使用所有的信号量，但是资源利用率低。
哲学家不能一个人吃饭就直接把五把叉子全部拿到手里。
  • 抢占
不可以抢别人在用的叉子吃饭啊
  • 资源定序 ：给资源编序，按顺序申请资源，这种情况一定不会出环，但是给程序员带来了很大的麻烦。不灵活。
桌子上有叉子就可以用，不一定就是要使用有编号的叉子

②动态方法----死锁避免（银行家算法banker）

DB2数据库select查看是否死锁 db2 查询死锁语句_死锁

进程对于资源的申请和释放是动态的过程，其他资源可以释放使其进入安全的状态。
存在死锁的风险。把风险避免，就不会出现死锁的可能

看起来是解决了这个问题对吧？但是：进程如果运行起来，进程数量和资源数量限定了。还没有执行就要知道需要哪些资源，数据从哪里来呢？

（3）死锁检测与恢复 – 资源请求分配图的化简

  • 检测是否有还资源，对资源分配图进行化简如果可以化简，说明还了资源；如果化简不了，说明没有还资源
如何检测呢？找即非孤立又非阻塞的进程。
 	如何恢复呢？收回资源：终止原语
 	死锁了就把所有哲学家的叉子收回！

直接终止进程又产生了问题，这个处理是否太极端了？只要收回一个叉子就可以使哲学家继续就餐。所以还可以下面这样：

T时刻没有死锁,T+1时刻有时刻，能否回到T时刻？
	参照虚拟机中的一个思维：快照。
	快照以后所有的时刻做的操作都能恢复到那一个时刻
	恢复到上一个没有死锁的就餐状态

但是这个方案也有不足之处便是：

限制：死锁检测，什么时候检测？
	有很多时机，一有进程申请释放资源的时候，就开始检测。
	检测时机有讲究，但是也可以周期，但是频率给多大?
	故需要找到事件与开销的均衡点

（4）鸵鸟算法—终极解决方案 √

死锁并不会出现那么高的概率。找不到一个非常优秀的解决方法
	
	对于目前个人来说，死锁造不成很大的伤害。
	
	所以我们————不解决！！！！！（是不是最开始就应该这么说呢？哈哈）

主要还是取决于个人选择是解决方案（3）还是（4）