为什么不是一个等待响应中断的对象锁的线程？我做了一些搜索和阅读 interuppting blocked thread。 我理解像java中的参数，只有方法可以被迫抛出异常，并且同步的块不能被强制抛出异常等。但是这种等待锁定行为似乎是一个明显的死锁原因，所以为什么不能使语言规范使同步块抛出中断异常并让开发人员处理它？有没有强大的原因语言规范明智的不这样做？答案也表明中断不仅仅是停止/取消线程。如果那是为什么Lock.lockInterruptibly（）稍后介绍？为什么不是一个线程正在等待响应中断的对象锁？
关键字的整个关键点应该很简单（或者至少与多线程一样简单）。这在Oracle的Java tutorial on Lock objects明确陈述：
同步代码依赖于一种简单的可重入锁。这种锁很容易使用，但有很多限制。
java.util.concurrent.locks包支持更复杂的加锁成语。
其中一个限制是缺乏中断等待线程的能力。
基本上，设计原则是，如果你只是需要最简单的互斥方式，是好的;如果您需要的东西超过最低限度，则需要使用其他更复杂的工具之一。
......因为这一切，你应该设计你的代码，以便任何线程永远不会持有一个“同步”锁，而不是更新几个字段。 –
我同意答案。我不会对这种行为感到困惑。 我不明白的是：这种“永久尝试锁定”行为似乎导致了轻松的僵局，没有恢复。我不能等待超时和中断。如果它是一个明显的死锁源，那么语言设计人员会想出办法。我能想到的一个解决方案是中断（假设中断是停止线程的最佳方式）。我想了解是否有强有力的理由说明为什么早期没有通过语言设计解决这个问题。或者可能是我的假设是错误的。 – Thiru
嗯，它只能一次访问多个锁，首先是死锁。语言设计者确实想到了一个办法：上述更复杂的构造。在很多情况下，你只需要一个简单的方法来自动设置某些字段，或者类似的简单方法，在这种情况下，拥有一个简单的构造就足以满足你的需要，而不是更多。 – yshavit
你能发布相关的代码吗？ – Ali