对可重入锁优于同步块的质疑

Question

我正在阅读Java中重入锁和同步块之间的比较。我正在浏览互联网上的各种资源。我在同步块上使用Reentrant锁发现的一个缺点是，在上一个中，您必须显式使用try final block来调用final telock在final块中获取的锁上调用解锁方法，因为您的关键代码部分可能会引发异常，并且可能会造成大麻烦， 如果线程没有释放锁，而在后一个中，JVM本身负责在发生异常时释放锁。

我不太相信这个缺点，因为使用try last没什么大不了的block.As我们已经在ex（流关闭等）中使用了很长时间。有人能告诉我重入锁在同步块上的其他一些缺点吗？

Answer 1

对于低或最小的争用，synchronized几乎总是更快，因为它允许JVM执行一些优化，例如偏置锁定，锁定省略等。以下是它的工作原理的更多详细信息：

让我们假设某个监视器由线程A持有，线程B请求这个监视器。在这种情况下，监视器将把它的状态更改为膨胀。简而言之，这意味着所有试图获取这个监视器的线程都将在操作系统级别等待设置，这是相当昂贵的。

现在，如果线程A在线程B请求之前释放了监视器，那么所谓的< code>rebias操作将由廉价的(在现代CPU上)< code >比较和交换操作来执行。

现在让我们来看看< code>ReentrantLock。每个线程调用< code>lock()或< code > lock interruptible()方法都会导致通过< code>CAS操作进行锁定尝试。

结论:在低争用情况下，最好使用< code >html" target="_blank">同步。在高度争用的情况下，最好使用< code>ReentrantLock。对于介于两者之间的所有情况，很难说清楚，请考虑执行基准测试以找出哪个解决方案更快。

Answer 2

对于不同的用例，ReentrantLock是不同的工具。虽然您可以使用这两种方法来解决大多数同步问题(这就是它们的用途)，但是它们有不同的优缺点。

Synchronized最简单:你写synchronized，仅此而已。对于现代的JVM来说，这是相当快的速度，但是它的缺点是，无论实际上是否需要，所有试图进入同步块的线程都会被挂起。如果您过于频繁地使用synchronized，这会极大地降低多线程的速度，最糟糕的情况是单线程的执行速度会更快。

由于线程问题仅在有人正在写入而其他人正在读取/写入相同的数据部分时发生，因此程序经常会遇到问题，即它们理论上可以在没有同步的情况下运行，因为大多数线程只是读取，但是偶尔会有一个写入，它强制执行同步块。这就是锁的用途：您可以更好地控制实际同步的时间。

除了构造函数中的一个公平参数之外，基本的ReentantLock允许您决定何时释放锁，并且您可以在多个点上执行，这样就可以在最适合您的时候执行。它的其他变体，如ReentantReadWriteLock，允许您进行许多不同步的读取，除非有写入。缺点是这在Java代码中得到了解决，这使得它明显比“本机”同步块慢。也就是说：只有在您知道使用此锁的优化增益大于损失的情况下，您才应该使用它。

在正常情况下，只有当你实际监控它时，你才能分辨速度的差异，通过运行分析器以复杂的方式检查前后的速度。