多线程以改善了系统资源的利用率并且提高了系统的处理能力。但是，并发执行同时也带来了新的问题——死锁。所谓的死锁就是多个线程因竞争资源而造成的一种互相等待，如果没有外力作用，这些线程都将无法继续执行
死锁产生的原因 系统资源的竞争通常系统中拥有的不可剥夺资源，其数量不足以满足多个线程运行的需要，使得线程在 运行过程中，会因争夺资源而陷入僵局，如磁带机、打印机等。只有对不可剥夺资源的竞争 才可能产生死锁，对可剥夺资源的竞争是不会引起死锁的。
线程推进顺序非法线程在运行过程中，请求和释放资源的顺序不当，也同样会导致死锁。例如，并发线程 P1、P2分别保持了资源R1、R2，而线程P1申请资源R2，线程P2申请资源R1时，两者都 会因为所需资源被占用而阻塞。
信号量使用不当也会造成死锁。线程间彼此相互等待对方发来的消息，结果也会使得这 些线程间无法继续向前推进。例如，线程A等待线程B发的消息，线程B又在等待线程A 发的消息，可以看出线程A和B不是因为竞争同一资源，而是在等待对方的资源导致死锁。
死锁产生的必要条件产生死锁必须同时满足以下四个条件，只要其中任一条件不成立，死锁就不会发生。
互斥条件：线程要求对所分配的资源（如打印机）进行排他性控制，即在一段时间内某资源仅为一个线程所占有。此时若有其他线程请求该资源，则请求线程只能等待
不剥夺条件：线程所获得的资源在未使用完毕之前，不能被其他线程强行夺走，即只能 由获得该资源的线程自己来释放（只能是主动释放)
请求和保持条件：线程已经保持了至少一个资源，但又提出了新的资源请求，而该资源 已被其他线程占有，此时请求线程被阻塞，但对自己已获得的资源保持不放
循环等待条件：存在一种线程资源的循环等待链，链中每一个线程已获得的资源同时被 链中下一个线程所请求。即存在一个处于等待状态的线程集合{Pl, P2, ..., pn}，其中Pi等 待的资源被P(i+1)占有（i=0, 1, ..., n-1)，Pn等待的资源被P0占有
如何避免在有些情况下死锁是可以避免的。三种用于避免死锁的技术：
加锁顺序
加锁时限
死锁检测
加锁顺序当多个线程需要相同的一些锁，但是按照不同的顺序加锁，死锁就容易发生。
按照顺序加锁是一种有效的死锁预防机制。但是，这种方式需要事先知道所有可能会用到的锁，但总有些时候是无法预知的。
加锁时限当一个线程在尝试获取锁的过程中超过了这个时限则该线程应该放弃对该锁进行请求。
若一个线程没有在给定的时限内成功获得所有需要的锁，则会进行回退并释放所有已经获得的锁，然后等待一段随机的时间再重试。这段随机的等待时间让其它线程有机会尝试获取相同的这些锁，并且让该应用在没有获得锁的时候可以继续运行。
需要注意的是，由于存在锁的超时，所以我们不能认为这种场景就一定是出现了死锁。也可能是因为获得了锁的线程（导致其它线程超时）需要很长的时间去完成它的任务。
此外，如果有非常多的线程同一时间去竞争同一批资源，就算有超时和回退机制，还是可能会导致这些线程重复地尝试但却始终得不到锁。如果只有两个线程，并且重试的超时时间设定为0到500毫秒之间，这种现象可能不会发生，但是如果是10个或20个线程情况就不同了。因为这些线程等待相等的重试时间的概率就高的多（或者非常接近以至于会出现问题）。
死锁检测死锁检测是一个更好的死锁预防机制，它主要是针对那些不可能实现按序加锁并且锁超时也不可行的场景。
每当一个线程获得了锁，会在线程和锁相关的数据结构中（map、graph等等）将其记下。除此之外，每当有线程请求锁，也需要记录在这个数据结构中。
当一个线程请求锁失败时，这个线程可以遍历锁的关系图看看是否有死锁发生。
那么当检测出死锁时，这些线程该做些什么呢？
一个可行的做法是释放所有锁，回退，并且等待一段随机的时间后重试。这个和简单的加锁超时类似，不一样的是只有死锁已经发生了才回退，而不会是因为加锁的请求超时了。虽然有回退和等待，但是如果有大量的线程竞争同一批锁，它们还是会重复地死锁（编者注：原因同超时类似，不能从根本上减轻竞争）。
一个更好的方案是给这些线程设置优先级，让一个（或几个）线程回退，剩下的线程就像没发生死锁一样继续保持着它们需要的锁。如果赋予这些线程的优先级是固定不变的，同一批线程总是会拥有更高的优先级。为避免这个问题，可以在死锁发生的时候设置随机的优先级。
Linux公社的RSS地址：https://www.linuxidc.com/rssFeed.aspx