翻译：GentlemanTsao, 2020-05-30

嵌套管程锁死是如何发生的

嵌套管程锁死的问题类似于死锁。 嵌套管程锁死是这样发生的：

Thread 1 synchronizes on A
Thread 1 synchronizes on B (while synchronized on A)
Thread 1 decides to wait for a signal from another thread before continuing
Thread 1 calls B.wait() thereby releasing the lock on B, but not A.Thread 2 needs to lock both A and B (in that sequence)to send Thread 1 the signal.
Thread 2 cannot lock A, since Thread 1 still holds the lock on A.
Thread 2 remain blocked indefinately waiting for Thread1to release the lock on AThread 1 remain blocked indefinately waiting for the signal fromThread 2, therebynever releasing the lock on A, that must be released to makeit possible for Thread 2 to send the signal to Thread 1, etc.

这听起来像是一种理论上的情况，但是请看下面Lock的直接实现：

//带有嵌套管程锁死的lock实现public class Lock{protected MonitorObject monitorObject = new MonitorObject();protected boolean isLocked = false;public void lock() throws InterruptedException{synchronized(this){while(isLocked){synchronized(this.monitorObject){this.monitorObject.wait();}}isLocked = true;}}public void unlock(){synchronized(this){this.isLocked = false;synchronized(this.monitorObject){this.monitorObject.notify();}}}
}

请注意lock（）方法首先在“ this”上同步，然后在monitorObject成员变量上同步。 如果isLocked为false，则没有问题。 该线程不调用monitorObject.wait（）。 但是，如果isLocked为true，则调用lock（）的线程将停在monitorObject.wait（）调用中。

这样做的问题在于，调用monitorObject.wait（）仅释放了monitorObject成员上的同步管程，而不释放与“ this”关联的同步管程。 换句话说，刚刚停在等待状态的线程仍持有“ this”上的同步锁。

当首个将Lock锁定的线程尝试调用unlock（）对其进行解锁时，将在尝试进入unlock（）方法中的synchronized(this)代码块时被阻塞。 它将一直保持阻塞状态，直到在lock（）中等待的线程离开了synchronized（this）为止。 但是，在lock（）方法中等待的线程不会离开该块，直到isLocked 设置为false，并执行monitorObject.notify（），而这正是unlock（）要做的。

简而言之，等待lock（）的线程需要成功执行一次unlock（），以使其退出lock（）和其中的同步块。 但是，在lock()中等待的线程离开外部同步块之前，没有任何线程可以实际执行unlock（）。

结果是，任何调用lock（）或unlock（）的线程都将永远阻塞。 这称为嵌套管程锁死。

一个更现实的例子

你可能会说，你永远不会照上面的方式实现一个锁。 因为你不会在内部管程对象上调用wait（）和notify（），而是在this上调用。很可能是这样。 但是在某些情况下，可能会出现上述设计。 例如，如果要在Lock中实现公平性。 这样做时，你希望每个线程在各自的队列对象上调用wait（），以便可以一次通知一个线程。

未完待续。。。