要想知道死锁出现的原因和解决方法，首先得知道什么是死锁，死锁是两个或两个以上的运算单元（进程、线程或协程），互相持有对方所需的资源，导致它们都无法向前推进，从而导致永久阻塞的问题。从字面意义上去理解并不太好理解，用实际情况来讨论可以更好的理解。

public synchronized void print(){
    synchronized (this){
        System.out.println("hahha");
    }
}

当代码执行到这个方法，会对该方法进行加锁，避免其他的线程加入进来干扰代码的运行，但是当代码执行到代码块里面时，发现这里又需要加锁，而且加的还是同一个锁（当synchronized对普通方法进行加锁时，相当于对this进行加锁，当对静态方法进行加锁时，相当于对类对象进行加锁），那么就会发生冲突，产生锁竞争。因为该this已被加锁，要想执行下去，就必须对this进行解锁，而要进行解锁，就得代码继续执行下去，这就导致代码逻辑产生矛盾，使得它们各自都无法向前推进，从而导致永久堵塞，这就产生了死锁，也是死锁的一种体现形式，这种死锁一眼就能看出，而方法的调用而导致出现的死锁就让人防不胜防。

public synchronized void func1(){
    func2();
}
public void func2(){
    synchronized (this){};
}

或许现在可以一眼就能发现死锁，但是当调用的方法更多时，还能保证不会出现死锁吗？不过这种情况是不科学的，因为此时进行两次加锁的是同一个线程，为什么说它是不科学的呢？就像你有了一把钥匙，这把钥匙打开了大门，但此时里面还有一扇挂着相同的锁的大门，你就不能用这把钥匙打开下一扇大门了吗？当然可以，因此，当第二次尝试加锁时，该线程已经有了这个锁的权限了，这个时候不应该加锁失败，也不应该阻塞等待。为了应对这种情况，Java也就产生了两种锁，一种是可重入锁，一种是不可重入锁。不可重入锁就是锁不会被保存，当它被某个线程给加了锁后，只要它处于加锁状态时，当它再次收到加锁的请求后，就会拒绝当前加锁，即使是该加锁的请求是对它已经加锁了的线程。而可重入锁则是会保存当前锁，当它被某个线程给加了锁后，当它再次收到加锁的请求，则会对比当前要进行加锁操作的线程和已经加了锁的线程是否一样，这样就可以灵活判断了，如果相同就不进行加锁且直接执行，如果不相同，那就得堵塞了，而synchronized就是可重入锁，因此上述代码不会出现这种情况。如果出现这种情况的话，什么时候进行解锁呢？

public void func2(){
    synchronized (this){
        synchronized (this){
            synchronized (this){
                ……;
            }
        }
    };
}

这很容易想到，当然是要出了最外面的synchronized才能进行解锁，不过我们虽然知道要到最外面的synchronized才解锁，但是jvm怎么知道什么时候才到了最外面的synchronized呢？其实很简单，增加一个计数器就行，只需要在每次进行加锁操作时，让计数器进行加一，每一个出锁操作就让计数器减一，这不就很好的解决了吗？到这死锁的一种典型情况就结束了，那就是一个线程一把锁，但是该锁是不可重入锁，并且一个线程对该锁进行了多次加锁，导致死锁的出现。

        现在就来谈谈死锁的第二种情况：两个线程两把锁，但是这两个线程同时获取对方的锁，这也将导致死锁的发生。

public void func3(){
    synchronized (locker1){
        synchronized (locker2){
            ;
        }
    }
}
public void func4(){
    synchronized (locker2){
        synchronized (locker1){
            ;
        }
    }
}

因为两个线程同时分别调用这两个方法，导致这两把锁同时被加锁，当它们又要再次获取另一把锁时，就会因为该锁被占用而导致线程进入阻塞状态，直到要获取的锁被释放，而因为这两个线程要想进行下去，就必须获取锁，要想获取锁就要进行下去，就如钥匙放在家里，要想进去家里，就得拿钥匙，要想拿钥匙，就得进家里，因而导致死锁的出现。

        而死锁的出现还有第三种情况，那就是N个线程M把锁，比如将一堆人围成一圈吃饭，在每个人的间隔中放一根筷子，而想要吃饭就必须要那两根，并且他们中的人什么时候开始吃饭都是不确定的，而当他们开始吃饭时，拿到筷子，除非吃完否则绝不放下，哪怕只拿到一根，而没拿到的就只能等待有筷子的时候。倘如有些人拿到了两根筷子，那么势必有人只有一根筷子甚至没有筷子，这就造成堵塞，将一跟筷子看成是一把锁，只有获得两把锁的线程才能顺利进行下去，那么那些只有一把锁甚至没有锁的线程就会堵塞，倘如有两个线程出现死锁出现的第二种情况，就会产生死锁，这就是N个线程M把锁出现死锁的情况。

        根据死锁出现的三种情况，可以发现其中有着共同之处，可以认为是死锁出现的必要原因。

1）互斥使用：当一个线程获取到一把锁后，其他线程在该线程释放该锁时，是不能获取该锁。

2）不可抢占：锁只能被所有者主动释放，而不能被其他线程给强行释放并直接加锁。

3）请求和保持：当线程获取一把锁后，在获取另一把锁时，会保持对第一把锁的的获取状态。

4）循环等待：t1想要获取locker2，就要等待t2释放locker2， t2想要获取locker1就要等待t1释放locker1，因此它们就得循环等待。

要想出现死锁，上述原因缺一不可。既然知道了死锁出现的原因，那么只需要破坏其中一个原因就可以避免死锁的出现了。因为原因1和原因2是锁的特性，无法修改，那么只能对原因3和4下手了，原因3和原因4取决与代码的结构。不过有时原因3会影响到需求，因此大部分时候对原因4进行改动。比如对所有的锁进行编号，并且规定必须得先对小的加锁，才能对大的加锁，只要代码严格按照该方法进行加锁，那么就可以规避循环等待。

private void func5(){
    synchronized (locker1){
        synchronized (locker3){
            synchronized (locker5){
                ;
            }
        }
    }
}

private void func6(){
    synchronized (locker2){
        synchronized (locker3){
            synchronized (locker4){
                ;
            }
        }
    }
}

到此死锁就此结束。