可能性例外的尝试，终于

我不知道是否像可能性例外的尝试，终于

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

给出的代码有任何机会，执行的线程可以执行lock方法之后，但在进入try-finally块之前以某种方式结束？这会导致一个锁，但从未释放。 Java/JVM规范中是否有一些行可以保证，如果代码是使用该惯用语编写的，那么就没有机会离开永远锁定的锁？

我的问题是，答案为C＃相关问题Can Monitor.Enter throw an exception?上MSDN

有关问题，这样的代码

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

引用两个帖子的启发

th在C＃的情况下，基于由JIT生成的机器代码，执行永远不会达到try-finally的可能性很小。

我知道这可能被看作是一个人为的问题/挑剔，但我的好奇心好转了我。

来源

2017-10-09 Andna

也许与为什么[Thread.stop（）已弃用]（https://stackoverflow.com/questions/16504140/thread-stop-deprecated）相关。从来没有听说过类似Java中链接的noop这样的问题，但当然这也会依赖于JVM。 – Kayaman

相关：https：//stackoverflow.com/questions/31058681/java-locking-structure-best-pattern – assylias

出于所有实际的目的，您可以假设抛出异常并且锁未锁定，否则您将输入try块。显然，这不包括突然的JVM崩溃等，在这种情况下锁发生了什么并不重要... – assylias

有没有用Java/JVM规范一些行，让我们的任何保证，如果代码是使用成语写没有机会离开锁定永远锁？

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

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

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

现在关于这个问题：

是有任何机会，执行的线程可以在某种程度上执行锁方法之后，但在进入的try-finally块前终止？

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

来源

2017-10-11 17:50:56

这是一个非常彻底和务实的答案。 – theMayer

可能性例外的尝试，终于

回答

相关问题