进程-死锁的概念/死锁产生的必要条件/死锁的处理策略/死锁的避免

进程也存在死锁，线程也存在死锁
饥饿：1分钟之内进程A执行了59秒，进程B执行了1秒，进程B处于饥饿状态，获得执行的资源太少了
死锁的产生原因:
（竞争资源）一般是因为A和B都占有了锁，都要求对方先释放，于是陷入了死锁中。
（进程推进顺序非法）你写的程序有bug

死锁有产生的必要条件，一般破坏一个就不会出现死锁了，和多线程死锁一样，但是怎么破坏和分析死锁的原因起始比较复杂，因为你debug的时候是无法出现的，这个需要非常强对锁的认知和逻辑的推理能力~~~（在多线程上面踩过N多坑的我到现在都没有完全理解，我真菜，哭泣ing）

资源剥夺举例：走的一个小巷子里面，遇到了一个【烫了爆炸头的非主流】，他不让你，你也不让他，你俩都走不过去了。 然后你让开了（资源剥夺了，不占有了），让非主流先过去（非主流获得了资源进行了操作，之后释放了资源），完了之后你再过去（你占有了锁进行操作）

撤销进程举例：和上面感觉差不多，但是会变为，你不从小巷子走了，直接撤了，非主流先走

进程回退举例：你和非主流遇到的地方是在小巷子遇到的，那么你回退到后面的岔路口（回退到避免死锁的地方），让非主流先过去，你退了之后非主流跑完了，你再跑。
或者（记录信息）：记录你现在走的哪里了，把你挂起来，原地起飞，让非主流先过去，然后你再下来，你再过去

接着吹，如何处理死锁问题：

上面其实在说死锁的概念的时候，已经说了，破坏它产生的必要条件就行了，所以我们一个个看下该怎么破坏

将排他锁去掉，将所有的请求放的队列里面，按顺序执行，这样就避免了对资源的抢占，只需要一个个去等的跑就行了
问题也是很明显的
1.如果我下订单的话，肯定还是要对我的剩余金额做处理的，你要么加乐观锁，要么加悲观锁，所以是否加消息队列还是根据业务场景来区分的，不能无脑改为队列的形式
2.队列肯定是有界和无界的，有界的话还是需要等待，无界的话会产生OOM

A持有一把锁，B持有一把锁，A要B的，B要A的
A和B由于一直请求的资源无法满足，A这个时候主动释放了资源，或者系统强制让A释放资源，让B先占有资源，然后B执行完了A从新执行
问题：
1.资源的浪费，A执行了一部分了，然后退回去，从新执行
2.要写很多代码来保证这个逻辑的准确性，维护起来也很困难

系统在运行的时候，先申请一部分资源，比如A和B进程，都要使用木棍去敲那个不让路的非主流，木棍只有一个，他们只能抢到了木棍才可以去敲，那么我存了5根木棍，A和B就可以人手一根去殴打非主流了。还可以让C,D,E也加入
问题：
1.资源浪费：如果只有A和B看非主流不顺眼要去敲，那么另外3根木棍是不是浪费了
2.进程饥饿：ABCDE都去敲了，F这个时候也要敲，一直等啊等，等不到
阶段性请求和释放资源：装备现在有【小飞棍】1根，【滋水枪】1把，A拿着【小飞棍】对着非主流喊道，小飞棍来喽~~~，biubiubiu，痛殴完之后释放，B拿着【滋水枪】对着非主流biubiubiu，痛殴完之后释放，接着A拿【滋水枪】biubiubiu，B拿着【小飞棍】，"小飞棍来喽~~~biubiubiu"。

你写的有BUG，抢占资源的时候要么加锁要么排序执行，你不加锁也不排序，导致出问题了，破坏循环等待（把你BUG修了加锁或者排序抢占资源）即可
为了效率高，我们有时候会让A从黄色-橘色-紫色-蓝色执行，让B从紫色-蓝色-黄色-橘色执行，都是一个循环执行结束，但是如果A执行到紫色，B还在紫色那里挂的原地修仙呢，一动不动，就出现了问题，死锁了。
问题：
1.定死了只能黄色-橘色-紫色-蓝色执行，扩展性不高
2.如果我要黄色-蓝色-紫色这样执行，是不可以的，限制了用户编程，我使用的顺序与系统要求的顺序不同
3.从1和2我们可以得知还有一个问题，性能不高

这个是操作系统提供的，提供给程序员避免死锁的安全性算法，python和java一般都用不到，c和c++估计会用到，我也直接略了