**
死锁
**
- 死锁：两个或两个以上的进程出现了永久性阻塞的情况。
这里我们使用哲学家就餐问题使其简便能够理解
一个桌子上面有五个哲学家和五把叉子，每个哲学家必须使用左叉子和右叉子才能进餐，桌子上只有五把叉子。 - 死锁产生的原因？
（1）资源不够：五个哲学家，需要十把叉子才能完全没有任何阻碍的进食，
但现实只有五把叉子
（2）在资源不足的情况下，进程推进顺序不当 。
- 死锁产生的四个必要条件
| 产生的原因 | 解决方案 |
|---|---|
| 互斥条件 | 打破互斥条件 |
| 占用并等待（请求与保持） | 资源静态分配 |
| 非抢占 | 抢占 |
| 循环等待 | 资源定序 |
-
死锁解决方案
①静态方法----死锁预防
-
打破互斥条件：互斥条件由资源本身决定，而大部分资源是互斥的。哲学家的叉子不能够同时被使用。 -
资源静态分配：使用信号量集操作 wait（S1,S2…）{}，使用所有的信号量，但是资源利用率低。
哲学家不能一个人吃饭就直接把五把叉子全部拿到手里。 -
抢占：很多资源在使用的时候不可以被抢占，如打印机。不可以抢别人在用的叉子吃饭啊 -
资源定序 ：给资源编序，按顺序申请资源，这种情况一定不会出环，但是给程序员带来了很大的麻烦。不灵活。
桌子上有叉子就可以用，不一定就是要使用有编号的叉子
②动态方法----死锁避免（银行家算法banker）
进程对于资源的申请和释放是动态的过程，其他资源可以释放使其进入安全的状态。
存在死锁的风险。把风险避免，就不会出现死锁的可能
看起来是解决了这个问题对吧？但是：进程如果运行起来，进程数量和资源数量限定了。还没有执行就要知道需要哪些资源，数据从哪里来呢？
（3）死锁检测与恢复 – 资源请求分配图的化简
扫描二维码关注公众号，回复：
5750662 查看本文章
-
检测是否有还资源，对资源分配图进行化简如果可以化简，说明还了资源；如果化简不了，说明没有还资源
如何检测呢？找即非孤立又非阻塞的进程。 如何恢复呢？收回资源：终止原语 死锁了就把所有哲学家的叉子收回！
直接终止进程又产生了问题，这个处理是否太极端了？只要收回一个叉子就可以使哲学家继续就餐。所以还可以下面这样：
T时刻没有死锁,T+1时刻有时刻，能否回到T时刻？
参照虚拟机中的一个思维：快照。
快照以后所有的时刻做的操作都能恢复到那一个时刻
恢复到上一个没有死锁的就餐状态
但是这个方案也有不足之处便是：
限制：死锁检测，什么时候检测？
有很多时机，一有进程申请释放资源的时候，就开始检测。
检测时机有讲究，但是也可以周期，但是频率给多大?
故需要找到事件与开销的均衡点
（4）鸵鸟算法—终极解决方案 √
死锁并不会出现那么高的概率。找不到一个非常优秀的解决方法
对于目前个人来说，死锁造不成很大的伤害。
所以我们————不解决！！！！！（是不是最开始就应该这么说呢？哈哈）
主要还是取决于个人选择是解决方案（3）还是（4）