Question

我想知道是否给出了像

这样的代码

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

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

我的问题的灵感来自C＃相关问题Can Monitor.Enter throw an exception?的答案，该问题引用了MSDN上的两篇帖子

https://blogs.msdn.microsoft.com/ericlippert/2007/08/17/subtleties-of-c-il-codegen/
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中有结构化和非结构化的锁。结构化锁是一种锁，其中锁定的代码封装在某个结构（块）内，并在此结构（块）的末尾自动释放。有与synchronized块同步的方法。在java中，只有在使用synchronized块的情况下，才会直接在字节码中获得monitorenter（https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.monitorenter）指令。因此，如果monitorenter指令失败，那么这将是致命错误，这将导致jvm停止。使用syncrhonized方法，编译字节码中没有monitorenter和monitorexit指令，但syncrhonized块中的代码被标记为jvm为synchronized，jvm将自己完成该工作。所以在这种情况下，如果smth会出错，那么这将是一个致命的jvm错误。所以这里你的问题的答案是否定的，因为同步块或方法被编译为本机jvm指令，它们的崩溃将导致整个jvm崩溃。

现在让我们谈谈未经编织的锁。这些是锁定，您必须通过调用该锁定的直接方法来处理锁定和解锁。在这里，您可以创建复杂有趣的结构（如链锁定等）。再一次，你的问题的答案是否定的，实际上绝对有可能在该方法中抛出异常，并且绝对有可能在这里获得实时或死锁。所有这一切都是可能的，因为非结构化锁定绝对是程序化的Java概念。 JVM对非结构化锁定一无所知。锁定在java中是一个接口（https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/Lock.html），你可以使用OOB非结构锁，如Reentrant lock，Reentrant RW locks等，或编写你的自定义实现。但是在现实生活中如果你使用例如折返锁，那么几乎没有机会在那里得到例外。即使是静态分析器也会告诉你，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几乎不知道这一点。

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

现在关于这个问题：

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

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

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

1 个答案: