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

Question

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

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

在执行 lock 方法之后但在进入 try-finally block 之前，是否有可能以某种方式终止正在执行的线程？这将导致锁被占用但从未释放。 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

Is there some line in Java/JVM specification that gives us any assurance that if the code is written using that idiom there is no chance of leaving locked-forever lock?

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

现在我们来谈谈非结构化锁。这些是您必须通过调用该锁的直接方法来注意锁定和解锁的锁。在这里，您可以获得创建复杂有趣结构(如锁链等)的许多优势。同样，您的问题的答案是否定的，实际上绝对有可能在该方法中抛出异常，并且也绝对有可能在此处获得实时或死锁。所有这一切都是可能的，因为非结构化锁定是绝对编程的 java 概念。 JVM 对非结构化锁一无所知。 Java 中的锁是一个接口(interface) (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 并发计算通常主要是关于正确性。

现在关于这个问题:

is there any chance that executing thread can be somehow terminated after executing lock method but before entering try-finally block?

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