产生死锁的原因：（1）竞争系统资源 （2）进程的推进顺序不当
产生死锁的必要条件：
互斥条件：进程要求对所分配的资源进行排它性控制，即在一段时间内某资源仅为一进程所占用。
请求和保持条件：当进程因请求资源而阻塞时，对已获得的资源保持不放。
不剥夺条件：进程已获得的资源在未使用完之前，不能剥夺，只能在使用完时由自己释放。
环路等待条件：在发生死锁时，必然存在一个进程--资源的环形链。
解决死锁
加锁顺序（线程按照一定的顺序加锁）
加锁时限（线程尝试获取锁的时候加上一定的时限，超过时限则放弃对该锁的请求，并释放自己占有的锁）
死锁检测
java中多线程产生死锁的原因以及解决意见
1. java中导致死锁的原因
多个线程同时被阻塞，它们中的一个或者全部都在等待某个资源被释放，而该资源又被其他线程锁定，从而导致每一个线程都得等其它线程释放其锁定的资源，造成了所有线程都无法正常结束。这是从网上其他文档看到的死锁产生的四个必要条件：
- 1、互斥使用，即当资源被一个线程使用(占有)时，别的线程不能使用
- 2、不可抢占，资源请求者不能强制从资源占有者手中夺取资源，资源只能由资源占有者主动释放。
- 3、请求和保持，即当资源请求者在请求其他的资源的同时保持对原有资源的占有。
- 4、循环等待，即存在一个等待队列：P1占有P2的资源，P2占有P3的资源，P3占有P1的资源。这样就形成了一个等待环路。
当上述四个条件都成立的时候，便形成死锁。当然，死锁的情况下如果打破上述任何一个条件，便可让死锁消失。下面用java代码来模拟一下死锁的产生。
模拟两个资源：
public class ThreadResource
{
public static Object resource1 = new Object();
public static Object resource2 = new Object();
}
模拟线程1占用资源1并申请获得资源2的锁：
public class Thread1 implements Runnable
{
@Override
public void run()
{
try
{
System.out.println("Thread1 is running");
synchronized (ThreadResource.resource1)
{
System.out.println("Thread1 lock resource1");
Thread.sleep(2000);//休眠2s等待线程2锁定资源2
synchronized (ThreadResource.resource2)
{
System.out.println("Thread1 lock resource2");
}
System.out.println("Thread1 release resource2");
}
System.out.println("Thread1 release resource1");
}
catch (Exception e)
{
System.out.println(e.getMessage());
}
System.out.println("Thread1 is stop");
}
}
模拟线程2占用资源2并申请获得资源1的锁：
public class Thread2 implements Runnable
{
@Override
public void run()
{
try
{
System.out.println("Thread2 is running");
synchronized (ThreadResource.resource2)
{
System.out.println("Thread2 lock resource2");
Thread.sleep(2000);//休眠2s等待线程1锁定资源1
synchronized (ThreadResource.resource1)
{
System.out.println("Thread2 lock resource1");
}
System.out.println("Thread2 release resource1");
}
System.out.println("Thread2 release resource2");
}
catch (Exception e)
{
System.out.println(e.getMessage());
}
System.out.println("Thread2 is stop");
}
}
同时运行俩个线程：
public class ThreadTest
{
public static void main(String[] args)
{
new Thread(new Thread1()).start();
new Thread(new Thread2()).start();
}
}
最后输出结果是：
Thread1 is running
Thread2 is running
Thread1 lock resource1
Thread2 lock resource2
并且程序一直无法结束。这就是由于线程1占用了资源1，此时线程2已经占用资源2,。这个时候线程1想要使用资源2，线程2想要使用资源1,。两个线程都无法让步，导致程序死锁。
2. java避免死锁的解决意见
由上面的例子可以看出当线程在同步某个对象里，再去锁定另外一个对象的话，就和容易发生死锁的情况。最好是线程每次只锁定一个对象并且在锁定该对象的过程中不再去锁定其他的对象，这样就不会导致死锁了。比如将以上的线程改成下面这种写法就可以避免死锁：
public void run()
{
try
{
System.out.println("Thread1 is running");
synchronized (ThreadResource.resource1)
{
System.out.println("Thread1 lock resource1");
Thread.sleep(2000);//休眠2s等待线程2锁定资源2
}
System.out.println("Thread1 release resource1");
synchronized (ThreadResource.resource2)
{
System.out.println("Thread1 lock resource2");
}
System.out.println("Thread1 release resource2");
}
catch (Exception e)
{
System.out.println(e.getMessage());
}
System.out.println("Thread1 is stop");
}
但是有的时候业务需要同时去锁定两个对象，比如转账业务：A给B转账，需要同时锁定A、B两个账户。如果A、B相互同时转账的话就会出现死锁的情况。这时可以定义一个规则：锁定账户先后的规则。根据账户的某一个属性（比如id或者hasCode），判断锁定的先后。即每一次转账业务都是先锁定A再锁定B（或者先锁定B在锁定A），这样也不会导致死锁的发生。比如按照上面的例子，需要同时锁定两个资源，可以根据资源的hashcode值大小来判断先后锁定顺序。可以这样改造线程：
public class Thread3 implements Runnable
{
@Override
public void run()
{
try
{
System.out.println("Thread is running");
if ( ThreadResource.resource1.hashCode() > ThreadResource.resource2.hashCode() )
{
//先锁定resource1
synchronized (ThreadResource.resource1)
{
System.out.println("Thread lock resource1");
Thread.sleep(2000);
synchronized (ThreadResource.resource2)
{
System.out.println("Thread lock resource2");
}
System.out.println("Thread release resource2");
}
System.out.println("Thread release resource1");
}
else
{
//先锁定resource2
synchronized (ThreadResource.resource2)
{
System.out.println("Thread lock resource2");
Thread.sleep(2000);
synchronized (ThreadResource.resource1)
{
System.out.println("Thread lock resource1");
}
System.out.println("Thread release resource1");
}
System.out.println("Thread release resource2");
}
}
catch (Exception e)
{
System.out.println(e.getMessage());
}
System.out.println("Thread1 is stop");
}
}
总结：死锁常见于，线程在锁定对象还没释放时，又需要锁定另一个对象，并且此时该对象可能被另一个线程锁定。这种时候很容易导致死锁。因此在开发时需要慎重使用锁，尤其是需要注意尽量不要在锁里又加锁。
注意：本文仅代表个人理解和看法哟！和本人所在公司和团体无任何关系！
三、如何避免死锁
在有些情况下死锁是可以避免的。三种用于避免死锁的技术：
加锁顺序（线程按照一定的顺序加锁）
加锁时限（线程尝试获取锁的时候加上一定的时限，超过时限则放弃对该锁的请求，并释放自己占有的锁）
死锁检测
加锁顺序
当多个线程需要相同的一些锁，但是按照不同的顺序加锁，死锁就很容易发生。
如果能确保所有的线程都是按照相同的顺序获得锁，那么死锁就不会发生。看下面这个例子：
Thread 1:
lock A
lock B
Thread 2:
wait for A
lock C (when A locked)
Thread 3:
wait for A
wait for B
wait for C
如果一个线程（比如线程3）需要一些锁，那么它必须按照确定的顺序获取锁。它只有获得了从顺序上排在前面的锁之后，才能获取后面的锁。
例如，线程2和线程3只有在获取了锁A之后才能尝试获取锁C(译者注：获取锁A是获取锁C的必要条件)。因为线程1已经拥有了锁A，所以线程2和3需要一直等到锁A被释放。然后在它们尝试对B或C加锁之前，必须成功地对A加了锁。
按照顺序加锁是一种有效的死锁预防机制。但是，这种方式需要你事先知道所有可能会用到的锁(译者注：并对这些锁做适当的排序)，但总有些时候是无法预知的。
加锁时限
另外一个可以避免死锁的方法是在尝试获取锁的时候加一个超时时间，这也就意味着在尝试获取锁的过程中若超过了这个时限该线程则放弃对该锁请求。若一个线程没有在给定的时限内成功获得所有需要的锁，则会进行回退并释放所有已经获得的锁，然后等待一段随机的时间再重试。这段随机的等待时间让其它线程有机会尝试获取相同的这些锁，并且让该应用在没有获得锁的时候可以继续运行(译者注：加锁超时后可以先继续运行干点其它事情，再回头来重复之前加锁的逻辑)。
以下是一个例子，展示了两个线程以不同的顺序尝试获取相同的两个锁，在发生超时后回退并重试的场景：
Thread 1 locks A
Thread 2 locks B
Thread 1 attempts to lock B but is blocked
Thread 2 attempts to lock A but is blocked
Thread 1's lock attempt on B times out
Thread 1 backs up and releases A as well
Thread 1 waits randomly (e.g. 257 millis) before retrying.
Thread 2's lock attempt on A times out
Thread 2 backs up and releases B as well
Thread 2 waits randomly (e.g. 43 millis) before retrying.
在上面的例子中，线程2比线程1早200毫秒进行重试加锁，因此它可以先成功地获取到两个锁。这时，线程1尝试获取锁A并且处于等待状态。当线程2结束时，线程1也可以顺利的获得这两个锁（除非线程2或者其它线程在线程1成功获得两个锁之前又获得其中的一些锁）。
需要注意的是，由于存在锁的超时，所以我们不能认为这种场景就一定是出现了死锁。也可能是因为获得了锁的线程（导致其它线程超时）需要很长的时间去完成它的任务。
此外，如果有非常多的线程同一时间去竞争同一批资源，就算有超时和回退机制，还是可能会导致这些线程重复地尝试但却始终得不到锁。如果只有两个线程，并且重试的超时时间设定为0到500毫秒之间，这种现象可能不会发生，但是如果是10个或20个线程情况就不同了。因为这些线程等待相等的重试时间的概率就高的多（或者非常接近以至于会出现问题）。
(译者注：超时和重试机制是为了避免在同一时间出现的竞争，但是当线程很多时，其中两个或多个线程的超时时间一样或者接近的可能性就会很大，因此就算出现竞争而导致超时后，由于超时时间一样，它们又会同时开始重试，导致新一轮的竞争，带来了新的问题。)
这种机制存在一个问题，在Java中不能对synchronized同步块设置超时时间。你需要创建一个自定义锁，或使用Java5中java.util.concurrent包下的工具。写一个自定义锁类不复杂，但超出了本文的内容。后续的Java并发系列会涵盖自定义锁的内容。
死锁检测
死锁检测是一个更好的死锁预防机制，它主要是针对那些不可能实现按序加锁并且锁超时也不可行的场景。
每当一个线程获得了锁，会在线程和锁相关的数据结构中（map、graph等等）将其记下。除此之外，每当有线程请求锁，也需要记录在这个数据结构中。
当一个线程请求锁失败时，这个线程可以遍历锁的关系图看看是否有死锁发生。例如，线程A请求锁7，但是锁7这个时候被线程B持有，这时线程A就可以检查一下线程B是否已经请求了线程A当前所持有的锁。如果线程B确实有这样的请求，那么就是发生了死锁（线程A拥有锁1，请求锁7；线程B拥有锁7，请求锁1）。
当然，死锁一般要比两个线程互相持有对方的锁这种情况要复杂的多。线程A等待线程B，线程B等待线程C，线程C等待线程D，线程D又在等待线程A。线程A为了检测死锁，它需要递进地检测所有被B请求的锁。从线程B所请求的锁开始，线程A找到了线程C，然后又找到了线程D，发现线程D请求的锁被线程A自己持有着。这是它就知道发生了死锁。
下面是一幅关于四个线程（A,B,C和D）之间锁占有和请求的关系图。像这样的数据结构就可以被用来检测死锁。
那么当检测出死锁时，这些线程该做些什么呢？
一个可行的做法是释放所有锁，回退，并且等待一段随机的时间后重试。这个和简单的加锁超时类似，不一样的是只有死锁已经发生了才回退，而不会是因为加锁的请求超时了。虽然有回退和等待，但是如果有大量的线程竞争同一批锁，它们还是会重复地死锁（编者注：原因同超时类似，不能从根本上减轻竞争）。
一个更好的方案是给这些线程设置优先级，让一个（或几个）线程回退，剩下的线程就像没发生死锁一样继续保持着它们需要的锁。如果赋予这些线程的优先级是固定不变的，同一批线程总是会拥有更高的优先级。为避免这个问题，可以在死锁发生的时候设置随机的优先级。
---------------------
作者：jayxu无捷之径
来源：CSDN
原文：https://blog.csdn.net/ls5718/article/details/51896159
版权声明：本文为博主原创文章，转载请附上博文链接！