1、线程加锁
其中 locker 可以是任意对象，进入 synchronized 修饰的代码块, 相当于加锁，退出 synchronized 修饰的代码块, 相当解锁。
如果一个线程，针对一个对象加上锁之后，其他线程也尝试对这个对象加锁，就会导致锁竞争进而引起阻塞（BLOCKED），这个阻塞会一直持续到上一个线程释放锁为止。
如果是两个线程分别针对不同的对象进行加锁，此时不会由锁竞争，也就不会阻塞。
出现锁竞争进而引起阻塞状态，这个阻塞会一直持续到下一个线程释放锁为止。
但是，设想一个场景，共有AB两个线程，此时A线程因为锁竞争进入阻塞状态，而如果此时B线程恰巧也正在阻塞状态，由于AB线程都进入了阻塞状态，此时进程无法运行，出现死锁问题。下面针对死锁问题的出现以及解决方法展开讨论。
2、死锁问题的三种经典场景
2.1、一个线程一把锁
public static void main(String[] args) { Object locker = new Object(); Thread t = new Thread(() -> { synchronized (locker) { //两次加锁，加的是同一把锁 synchronized (locker) { //两次加锁，加的是同一把锁 System.out.println("hello synchronized"); } } }); t.start(); }
需要注意的是，这里最直观的感觉是进行了两次加锁，会发生锁冲突。第一次针对locker加锁之后，在还没释放锁的时候又尝试对locker加锁，理论会出现锁冲突。
至于事实上是否会出现所冲突进而出现死锁，需要分情况讨论：
1、如果是不可重入锁，则就会出现锁竞争引起死锁。
2、如果是可重入锁，则不会出现锁竞争引起死锁，Java中的锁就是可重入锁，因此可以正常打印。
可以把这种情况理解成：【屋钥匙锁在了屋里】
2.2、两个线程两把锁
package thread; public class ThreadDemo22 { public static void main(String[] args) { Object A = new Object(); Object B = new Object(); Thread t1 = new Thread(() -> { synchronized (A) { // sleep一下, 给 t2 时间, 让 t2 也能拿到 B try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } // 尝试获取 B, 并没有释放 A synchronized (B) { System.out.println("t1 拿到了两把锁!"); } } }); Thread t2 = new Thread(() -> { synchronized (A) { // sleep一下, 给 t1 时间, 让 t1 能拿到 A try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } // 尝试获取 A, 并没有释放 B synchronized (B) { System.out.println("t2 拿到了两把锁!"); } } }); t1.start(); t2.start(); } }
package thread; public class ThreadDemo22 { public static void main(String[] args) { Object A = new Object(); Object B = new Object(); Thread t1 = new Thread(() -> { synchronized (A) { // sleep一下, 给 t2 时间, 让 t2 也能拿到 B try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } // 尝试获取 B, 并没有释放 A synchronized (B) { System.out.println("t1 拿到了两把锁!"); } } }); Thread t2 = new Thread(() -> { synchronized (A) { // sleep一下, 给 t1 时间, 让 t1 能拿到 A try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } // 尝试获取 A, 并没有释放 B synchronized (B) { System.out.println("t2 拿到了两把锁!"); } } }); t1.start(); t2.start(); } }
两个线程，两把锁。线程A获取到锁A，线程B获取到锁B，在没释放锁AB的前提下，线程A尝试获取锁B，线程B尝试获取锁A，就会出现死锁。
可以把这种情况理解成：【屋钥匙锁在了车里，车钥匙锁在了屋里】
2.3、N个线程M把锁（哲学家就餐问题）
首先假设一个场景，一张圆桌上坐着五个人，每个人面前都有一碗面条，桌子上一共有五根筷子（不是五双），而将五根筷子分别摆放在两人各自之间，如下图。
要想吃面条，需要拿起自己身旁的两根筷子（左右两根，只能拿身边的这两根）。假设此时A拿起了左右筷子吃面条，此时B就无法吃，因为A正在使用B的左筷子，B目前只能拿起一根右筷子，并且开始等待，等待A放下筷子，再拿起左筷子吃面条（此处的等待只有拿到另外一根筷子后才会停止，并且等待的同时不会放下已经拿起的筷子）。同理E也一样。
此处讨论的问题中N等于M。我们将线程比作人，筷子比作锁，此时B所处的状态可以比作锁竞争引起的阻塞状态。大家可以试着想想各种其他不同的情况，始终都能保证桌上5个人至少有一人正在吃面条，除了一种特殊的极端情况下：
极端情况下，会出现所有人同时都拿了同一侧的筷子（例如都拿了左筷子），导致所有人都不能拿起另一侧的筷子而都进入阻塞，等待着别人放下筷子后自己再拿起来。但是此时又因为没有一个人能吃的上面条，因此永远不会有人放下筷子，出现死锁。
这个问题也被人称之为：哲学家就餐问题。
3、解决死锁问题
要想解决死锁情况，就得先讨论产生死锁的原因：
死锁产生的四个必要条件（缺一不可）
由于是必要条件，只需要破坏其中一种条件，就可以让死锁解开。
- 互斥使用。一个线程拿到了这把锁，另一个线程也想获取，就需要阻塞等待，这是锁最基本的特性，不好破坏。
- 不可抢占。一个线程拿到了锁之后，只能主动解锁，不能让别的线程强行把锁抢走，这也是锁最基本的特性，不好破坏。
- 请求保持。一个线程拿到了锁A，在持有锁A的前提下，尝试获取锁B。这些场景下必须需要这样使用，也不好破坏。
- 循环等待/环路等待，是一种代码结构，是最容易破坏。
由上述分析可以得知，想要解决死锁问题，要从破坏循环等待/环路等待入手。
引入加锁顺序的规则就是很好破解循环等待的办法，即给每一个锁编号，规定只能按照锁的序号顺序拿起，就能打破循环等待。
举例说明：
依然是是上面的哲学家就餐问题，此时给筷子编号序号之后，要求只能按照顺序由小到大拿起，此时就算是所有人同时拿起筷子，C先拿1，B先拿2，A先拿3，E先拿4，此时D按照规定应该拿起1，但是此时C正拿着1，因此此时D还没有机会拿起5，就直接进入阻塞状态。此场景下E就能拿起5开始吃面，E放下筷子A就接着吃，依此类推，就将可能出现的死锁问题破解了。
