在 Java 中使用纯 lock() 方法是一种不好的做法吗？答案

【问题标题】：Is it a bad practice to use pure lock() method in Java?在 Java 中使用纯 lock() 方法是一种不好的做法吗？
【发布时间】：2021-05-28 06:57:38
【问题描述】：

根据documentation：

空锁()
获取锁。
如果锁不可用，则当前线程将被禁用以进行线程调度，并处于休眠状态，直到获得锁为止。

我几乎在所有地方都在使用定时 tryLock，处理所有预期的事情 - 如果 timout 结束，如果它被中断，等等。

但是今天，我想：使用纯 lock() 是不是很糟糕/不安全/危险？

显示它看起来如此可爱和优雅的示例 - 最后锁定并解锁。我用谷歌搜索，但没有找到关于这是一种不好的做法的答案。

【问题讨论】：

您从哪里得知使用 lock() 是一种不好的做法？
我只是在问这个问题。对我来说，使用定时锁看起来更安全——它可以防止线程被卡住。但是互联网上到处都是纯 lock() 调用的例子。所以，这种情况引起了这个问题。
当你的线程永远不会从lock()返回时，失败是在另一边永远不会释放锁（在99%的情况下）。即使在持有另一个锁的同时尝试获取一个锁而导致真正的死锁，使用超时只会对症状造成影响，因为您将用死锁换取无法执行操作。此处的任何超时值都是任意的，经过的时间并不能告诉您是否真正解决了活性问题，或者只是没有等待足够长的时间。
我认为没有其他可用的锁定方式......所以一直使用锁定。问题可能是它是一种非常低级的锁定方式，只实现一个简单的互斥锁......如果你想使用条件或信号量，你需要在此基础上进行组合以使它们可用。
没有必要假设每个锁操作都会导致死锁。如前所述，如果对方没有释放锁，你应该修复它。并且避免在已经持有锁的情况下尝试获取锁。一般来说，更喜欢修复错误而不是试图从错误中恢复，争取正确的应用程序逻辑而不是试图在低级别（无法解决的问题）解决问题。防御性编码是有限制的。你不应该在每个成员访问前加上if(object != null)，也不应该在每个部门前加上if(dividend != 0)，等等。

标签： java concurrency locking

【解决方案1】：

这取决于您如何在代码中使用它。如果您只是使用它，仅用于锁定和解锁，那么您不会使用它提供的任何功能。因此，您只能使用关键字 synchronized 回退到内部锁。但是，如果您使用定时锁定和可中断锁定设施，那么考虑到您的特定用例保证它可能是合理的。与显式锁相比，内在锁仍然具有显着优势。该符号是熟悉且紧凑的。通常，开发人员会忘记在显式锁上调用 unlock，这使得它更容易出错。

此外，如果您使用条件对象，您仍然可以使用其中任何一个。如果锁对象只有一个条件，我宁愿使用内在锁。当您需要为给定锁设置多个条件并且需要在不受同一锁上其他条件的任何干扰的情况下使用它时，显式锁会变得很方便。

总之，这完全取决于您如何使用它以及您的用例是否值得。

【讨论】：

【解决方案2】：

无论好坏，没有什么好说的。如果你需要处理关键块，你需要锁定它。

【讨论】：