跳到主要内容

19、Java并发编程:嵌套管程锁死

嵌套管程锁死是如何发生的

嵌套管程锁死的问题类似于死锁。 嵌套管程锁死是这样发生的:

Thread 1 synchronizes on A
Thread 1 synchronizes on B (while synchronized on A)
Thread 1 decides to wait for a signal from another thread before continuing
Thread 1 calls B.wait() thereby releasing the lock on B, but not A.

Thread 2 needs to lock both A and B (in that sequence)
        to send Thread 1 the signal.
Thread 2 cannot lock A, since Thread 1 still holds the lock on A.
Thread 2 remain blocked indefinately waiting for Thread1
        to release the lock on A

Thread 1 remain blocked indefinately waiting for the signal from
        Thread 2, thereby
        never releasing the lock on A, that must be released to make
        it possible for Thread 2 to send the signal to Thread 1, etc.

这听起来像是一种理论上的情况,但是请看下面Lock的直接实现:

//带有嵌套管程锁死的lock实现

public class Lock{
   
     
  protected MonitorObject monitorObject = new MonitorObject();
  protected boolean isLocked = false;

  public void lock() throws InterruptedException{
   
     
    synchronized(this){
   
     
      while(isLocked){
   
     
        synchronized(this.monitorObject){
   
     
            this.monitorObject.wait();
        }
      }
      isLocked = true;
    }
  }

  public void unlock(){
   
     
    synchronized(this){
   
     
      this.isLocked = false;
      synchronized(this.monitorObject){
   
     
        this.monitorObject.notify();
      }
    }
  }
}

请注意lock()方法首先在“ this”上同步,然后在monitorObject成员变量上同步。 如果isLocked为false,则没有问题。 该线程不调用monitorObject.wait()。 但是,如果isLocked为true,则调用lock()的线程将停在monitorObject.wait()调用中。

这样做的问题在于,调用monitorObject.wait()仅释放了monitorObject成员上的同步管程,而不释放与“ this”关联的同步管程。 换句话说,刚刚停在等待状态的线程仍持有“ this”上的同步锁。

当首个将Lock锁定的线程尝试调用unlock()对其进行解锁时,将在尝试进入unlock()方法中的synchronized(this)代码块时被阻塞。 它将一直保持阻塞状态,直到在lock()中等待的线程离开了synchronized(this)为止。 但是,在lock()方法中等待的线程不会离开该块,直到isLocked 设置为false,并执行monitorObject.notify(),而这正是unlock()要做的。

简而言之,等待lock()的线程需要成功执行一次unlock(),以使其退出lock()和其中的同步块。 但是,在lock()中等待的线程离开外部同步块之前,没有任何线程可以实际执行unlock()。

结果是,任何调用lock()或unlock()的线程都将永远阻塞。 这称为嵌套管程锁死。

一个更现实的例子

你可能会说,你永远不会照上面的方式实现一个锁。 因为你不会在内部管程对象上调用wait()和notify(),而是在this上调用。很可能是这样。 但是在某些情况下,可能会出现上述设计。 例如,如果要在Lock中实现公平性。 这样做时,你希望每个线程在各自的队列对象上调用wait(),以便可以一次通知一个线程。

看一下这种公平锁的简单实现:

//Fair Lock implementation with nested monitor lockout problem

public class FairLock {
   
     
  private boolean           isLocked       = false;
  private Thread            lockingThread  = null;
  private List<QueueObject> waitingThreads =
            new ArrayList<QueueObject>();

  public void lock() throws InterruptedException{
   
     
    QueueObject queueObject = new QueueObject();

    synchronized(this){
   
     
      waitingThreads.add(queueObject);

      while(isLocked || waitingThreads.get(0) != queueObject){
   
     

        synchronized(queueObject){
   
     
          try{
   
     
            queueObject.wait();
          }catch(InterruptedException e){
   
     
            waitingThreads.remove(queueObject);
            throw e;
          }
        }
      }
      waitingThreads.remove(queueObject);
      isLocked = true;
      lockingThread = Thread.currentThread();
    }
  }

  public synchronized void unlock(){
   
     
    if(this.lockingThread != Thread.currentThread()){
   
     
      throw new IllegalMonitorStateException(
        "Calling thread has not locked this lock");
    }
    isLocked      = false;
    lockingThread = null;
    if(waitingThreads.size() > 0){
   
     
      QueueObject queueObject = waitingThreads.get(0);
      synchronized(queueObject){
   
     
        queueObject.notify();
      }
    }
  }
}
public class QueueObject {
   
     }

乍看起来,此实现看起来不错,但请注意lock()方法调用了queueObject.wait(),该调用在两个同步块内部。 一个在“ this”上同步,另一个嵌套在其中,在queueObject局部变量上同步。 当线程调用queueObject.wait()时,它释放QueueObject实例上的锁,但不释放与“ this”关联的锁。

还要注意,unlock()方法声明为synchronized,它相当于synchronized(this)块。 这意味着,如果线程在lock()中等待,则与“ this”关联的管程对象将被该等待的线程锁定。 所有调用unlock()的线程将无限期地阻塞,等待正在等待的线程释放对“ this”的锁定。 但这永远不会发生,因为只有在线程成功将信号发送到等待的线程时才会发生,而发送信号只能通过执行unlock()方法。

因此,上面的FairLock实现可能导致嵌套管程锁死。在《饥饿和公平性》篇中讲解了如何更好的实现公平锁。

嵌套管程锁死 vs 死锁

嵌套管程锁死和死锁的结果几乎相同:所涉及的线程最终被阻塞,永远等待对方。

但这两种情况并不等价。 如关于死锁篇中所述,当两个线程以不同顺序获得锁时,就会发生死锁。 线程1锁定A,等待B。线程2锁定B,然后等待A。如防死锁篇所述,可以通过始终以相同顺序锁定锁(锁定顺序)来避免死锁。 但是,嵌套管程锁死正是由两个线程以相同顺序进行锁定而发生。 线程1锁定A和B,然后释放B并等待来自线程2的信号。线程2同时需要A和B才能向线程1发送信号。 结果就是,一个线程正在等待信号,另一个线程正在等待释放锁。

区别总结如下:

  • 在死锁中,两个线程等待彼此释放锁。
  • 嵌套管程锁死中,线程1持有锁A,然后等待
    来自线程2的信号。线程2需要锁A来发送
    信号给线程1。