本文目录
解决死锁的方法
一、解除死锁常常采用两种方法：1、资源剥夺法；2、撤消进程法。
二、处理死锁的思路如下：
预防死锁：破坏四个必要条件中的一个或多个来预防死锁。
避免死锁：在资源动态分配的过程中，用某种方式防止系统进入不安全的状态。
检测死锁：运行时产生死锁，及时发现思索，将程序解脱出来。
解除死锁：发生死锁后，撤销进程，回收资源，分配给正在阻塞状态的进程。
三、预防死锁的办法：
破坏请求和保持条件：
1、一次性的申请所有资源。之后不在申请资源，如果不满足资源条件则得不到资源分配。
2、只获得初期资源运行，之后将运行完的资源释放，请求新的资源。
破坏不可抢占条件：当一个进程获得某种不可抢占资源，提出新的资源申请，若不能满足，则释放所有资源，以后需要，再次重新申请。
破坏循环等待条件：对资源进行排号，按照序号递增的顺序请求资源。若进程获得序号高的资源想要获取序号低的资源，就需要先释放序号高的资源。
扩展资料
形成死锁的四个必要条件：
（1） 互斥条件：一个资源每次只能被一个进程使用。
（2） 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
（3） 不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。
（4） 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
如何解决Linux下信号产生的死锁
一次测试环境发生了server死锁，整个server的任务线程都被hang住。而死锁的代码就在我负责的程序日志部分中localtime_r函数调用处。
程序日记需要记录打印日志的时间，而localtime_r函数就是用于将系统时间转换为本地时间。同样功能的函数还有localtime。两个函数的区别是：localtime_r是thread-safe，其返回的结果存在由用户提供的buffer中；而localtime返回的结果是指向static变量，多线程环境可被其他线程修改。localtime_r实现中有一把锁，负责lock tzfile中的状态变量，而server就在这里发生死锁。
经过分析死锁是由于发kill信号，信号处理函数引起的。原线程打印程序日志获得localtime_r中需要的锁后，kill信号触发中断处理，正好分配给该线程处理中断。信号处理函数中再次打印日志，调用localtime_r的锁时发生死锁。
之前的信号处理方式为异步方式，同时信号处理函数中做了很多事情。之前大家一直关注线程安全，却从来没有注意过异步信号处理函数的安全性。这次最新版本由于还在开发中，大家调用了大量日志打印，增加了死锁的概率才将这个问题暴露出来。
##Signal Handling and Nonreentrant Functions
信号处理函数不推荐做太多工作，如果调用函数需要是reentrant。reentrant可重新进入的，可以理解为一次调用发生后，不会对该函数的再次调用发生任何影响。即reentrant函数中不可以有static或global变量，不可以分配释放内存，通常不可以使用修改用户提供的对象，修改errno等等。具体可以看同步信号处理
Java并发编程的线程死锁问题如何解决
上面两位大佬一个防范于未然，一个有解决死锁问题的查找方案，这就够了啊！！
死锁时为啥cpu很高，从内核角度分析一下
分哪种死锁，一般在请求资源的时候会遇到锁，在获取锁失败后之后进程会再次尝试获得锁，直到真正获取到锁。这个不断尝试的过程可能会变成请求的不断提交，因为死锁是无论如何无法获得锁的，所以会导致进程反复尝试，提交的请求过多，就会占用CPU很高的资源。
