ReentrantLock--为什么我们需要多次获取一个锁？

Answer 1

为什么我们需要多次获取锁？

很明显，你不需要。但应用程序“偶然”做到这一点并不罕见。例如：

  public void binaryOperation(Operand op1, Operand op2) {
      synchronized (op1) {
          synchronized (op2) {
               // do something that needs the locks
          }
      }
  }

  // now call passing the same object for both operands
  Operand op = ...
  binaryOperation(op, op); 

在本例中，op对象实际上将被锁定两次。如果原语锁不是可重入的，这可能会失败（或死锁）。

“导致当前线程等待，直到另一个线程调用此对象的notify()方法或notifyAll()方法，或者已经过了指定的时间。”

对于wait()和wait(timeout)，调用方可以检查它希望得到“通知”的条件是否实际满足。（请参见关于“虚假唤醒”的注释...和示例代码。）

wait（long timeout）比wait（）方法有什么优势？

但是在reentrantlock的情况下，在哪个对象上获取锁？

严格来说，是锁本身。锁的实际含义将取决于如何编写类。但这与原始互斥完全相同。

Java中的锁定并不能阻止某些行为不端的代码在不持有锁的情况下访问或更新某些共享状态。要由程序员来正确地做这件事。

在可重入锁定的情况下（即，线程试图在持有锁a的同时获取锁a的情况下），reentrantlock实现会注意到持有锁的线程就是获取锁的线程。一个计数器递增，这样实现就知道锁必须释放两次。

在这种情况下，如何使用ReentrantLock避免死锁？也许我们可以使用tryLock()，并为未能获得锁的线程提供一个替代操作。

这是一种方法。

然后设计逻辑以避免死锁；见上面的备选方案！

问题4。

但是为什么我们要多次获取lock呢？