摘自编程语言语用学，作者:Scott
While maintaining exclusion on outer monitor(s) when waiting in an inner one may lead to deadlock with a signaling thread, releasing those outer monitors may lead to similar (if a bit more subtle) deadlocks. When a waiting thread awakens it must reacquire exclusion on both inner and outer monitors. The innermost monitor is of course available, because the matching signal happened there, but there is in general no way to ensure that unrelated threads will not be busy in the outer monitor(s). Moreover one of those threads may need access to the inner monitor in order to complete its work and release the outer monitor(s). If we insist that the awakened thread be the first to run in the inner monitor after the signal, then deadlock will result. One way to avoid this problem is to arrange for mutual exclusion across all the monitors of a program. This solution severely limits concurrency in multiprocessor implementations, but may be acceptable on a uniprocessor.
我用粗体突出显示的两种情况是如何导致僵局的？
- 在内部监视器中等待时保持外部监视器的排除
- 释放那些外部监视器
我很难理解文本，尤其是第二种情况。 如果您能以更清晰的方式解释它们，我们将不胜感激。
谢谢。
最佳答案
在内部监视器中等待时维护外部监视器的排除当进程等待内部监视器时，它可以在其维护的所有外部监视器上保留排除。当另一个进程想要访问外部监视器之一，但自己可以访问内部监视器时，这可能会导致死锁，从而产生死锁。
释放这些外部监视器:想象一个线程正在等待内部监视器并释放其外部监视器，以确保其他一些监视器在进程等待时可以访问它们。现在，当线程唤醒时(=内部监视器可以再次访问它)，它需要获取在等待时释放的外部监视器。这就出现了这个问题:“但通常没有办法确保不相关的线程不会在外部监视器中忙碌”
关于java - 如何理解嵌套监视器导致死锁？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45962208/