在 Java 中有两种锁，一种是内置锁 synchronized，一种是显示锁 Lock，其中 Lock 锁是可中断锁，而 synchronized 则为不可中断锁。
所谓的中断锁指的是锁在执行时可被中断，也就是在执行时可以接收 interrupt 的通知，从而中断锁执行。
PS：默认情况下 Lock 也是不可中断锁，但是可以通过特殊的“手段”，可以让其变为可中断锁，接下来我们一起来看。
为什么需要可中断锁？
不可中断锁的问题是，当出现“异常”时，只能一直阻塞等待，别无其他办法，比如下面这个程序。下面的这个程序中有两个线程，其中线程 1 先获取到锁资源执行相应代码，而线程 2 在 0.5s 之后开始尝试获取锁资源，但线程 1 执行时忘记释放锁了，这就造成线程 2 一直阻塞等待的情况，实现代码如下：
import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; publicclass InterruptiblyExample { public static void main(String[] args) { Lock lock = new ReentrantLock(); // 创建线程 1 Thread t1 = new Thread(new Runnable() { @Override public void run() { lock.lock(); System.out.println("线程 1：获取到锁."); // 线程 1 未释放锁 } }); t1.start(); // 创建线程 2 Thread t2 = new Thread(new Runnable() { @Override public void run() { // 先休眠 0.5s，让线程 1 先执行 try { Thread.sleep(500); } catch (InterruptedException e) { e.printStackTrace(); } // 获取锁 System.out.println("线程 2:等待获取锁."); lock.lock(); try { System.out.println("线程 2：获取锁成功."); } finally { lock.unlock(); } } }); t2.start(); } }
以上代码执行的结果如下：
从上述结果可以看出，此时线程 2 在等待获取锁的操作，然而经历了 N 久之后...再次查看结果，依然是熟悉的画面：
线程 2 还在阻塞等待获取线程 1 释放锁资源，此时的线程 2 除了等之外，并无其他方法。
并且，当我们熟练地拿出了 JConsole，试图得到一个死锁的具体信息时，却得到了这样的结果：
并没有检测到任何死锁信息，从上图我们可以看出，当只有一个锁资源的时候，系统并不会把这种情况判定为死锁，当然也没有阻塞等待的具体信息喽，此时只剩下线程 2 孤单地等待着它的“锁儿”。
