锁定锁定之后但在 try-finally 之前出现异常的可能性

Question

我想知道给定的代码是否像

lock.lock();
try {
    count++;
} finally {
    lock.unlock();
}

在执行lock 方法之后但在进入try-finally 块之前，是否有可能以某种方式终止正在执行的线程？这将导致一个被占用但从未被释放的锁。 Java/JVM 规范中是否有某些行可以保证如果使用该习惯用法编写代码，则不会留下永远锁定的锁定？

我的问题受到 C# 相关问题Can Monitor.Enter throw an exception? 的回答的启发，该问题引用了 MSDN 上的两个帖子

1. https://blogs.msdn.microsoft.com/ericlippert/2007/08/17/subtleties-of-c-il-codegen/
2. https://blogs.msdn.microsoft.com/ericlippert/2009/03/06/locks-and-exceptions-do-not-mix/

关于类似代码的问题

Monitor.Enter(...)
try
{
    ...
}
finally
{
    Monitor.Exit(..)
}

在 C# 的情况下，根据 JIT 生成的机器代码，执行永远不会到达 try-finally 的可能性很小。

我知道这可能被视为一个人为的问题/吹毛求疵，但我的好奇心越来越好。

Answer 1

Java/JVM 规范中是否有某些行可以为我们提供任何 保证如果代码是使用该成语编写的，则没有 离开锁定永远锁定的机会？

首先我想注意到在java中有结构化和非结构化的锁。结构化锁是一种锁，其中锁定的代码被封装在某个结构（块）内，并在该结构（块）的末尾自动释放。同步方法与同步块一样多。在 java 中，只有在使用同步块的情况下，您才会直接在字节码中获得 monitorenter (https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.monitorenter) 指令。因此，如果 monitorenter 指令失败，那么这将是一个致命错误，将导致 jvm 停止。使用 syncrhonized 方法，编译字节码中没有直接的 monitorenter 和 monitorexit 指令，但是 syncrhonized 块中的代码为 jvm 标记为已同步，并且 jvm 将自行完成该工作。所以在这种情况下，如果 smth 会出错，那么这将是一个致命的 jvm 错误。所以在这里你的问题的答案是否定的，因为同步块或方法被编译为本地 jvm 指令，它们的崩溃将导致整个 jvm 崩溃。

现在让我们谈谈非结构化锁。这些是您必须通过调用该锁的直接方法来处理锁定和解锁的锁。在这里，您可以获得许多创建复杂有趣结构（如链锁等）的优势。同样，您的问题的答案是否定的，实际上绝对有可能在该方法中引发异常，并且绝对有可能在这里获得活锁或死锁。所有这一切都是可能的，因为非结构化锁定绝对是编程的 java 概念。 JVM 对非结构化锁一无所知。 Java 中的锁是一个接口 (https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/Lock.html)，您可以使用 OOB 非结构化锁，如可重入锁、可重入 RW 锁等，或者编写您的自定义实现。但是在现实生活中，如果您使用例如可重入锁，那么几乎没有机会在那里获得异常。甚至静态分析器也会告诉您，RLock 中没有可能引发异常的点（检查为未检查）。但是可能会出现错误（https://docs.oracle.com/javase/7/docs/api/java/lang/Error.html）。我们再次遇到致命的 JVM 故障，之后您将不需要任何锁。而不是字节码的 monitorenter RLock 和几乎所有其他 OOB java 锁都使用 AbstractQueuedSynchronizer (https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/AbstractQueuedSynchronizer.html)。所以你可以确定它是完全程序化的，而 JVM 对此几乎一无所知。

现在从架构的角度来看。如果在某些实现中，您在 lock 方法中遇到了意外的异常，并且在该锁仍然可用于进一步使用之后，那么在那里获得一个永远存在的锁而不是一个内部状态损坏的锁可能会更好。使用它不再安全，并且没有人保证正确的进一步锁定，因为您至少有一个不正确行为的先例。锁定中的任何意外异常都应被视为需要深入调查的问题，因为它的最初原因是在进一步使用之前。长寿命锁会阻止它被其他线程使用，更重要的是，系统会保持它的正确状态。那么当然有一天 smb 会 m 并发计算通常主要是关于正确性。

现在关于这个问题：

是否有可能以某种方式终止正在执行的线程 在执行锁定方法之后但在进入 try-finally 块之前？

答案当然是肯定的。你甚至可以挂起持有锁的线程或者只是调用 sleep 以便其他线程无法获取它。这就是锁定算法的工作原理，我们对此无能为力。这将被归类为错误。实际上，无锁 2+ 线程算法在这种情况下并不容易受到攻击。并发编程不是一件简单的事情。在它的设计过程中你应该考虑很多事情，即使在那之后你也不会避免失败。