Тупик при вызове двух синхронизированных методов

Во-первых, напомните, что ключевое слово synchronized, применяемое к классу aa, подразумевает блокировку всего объекта, к которому принадлежит этот метод. Теперь давайте набросим еще одну пару объектов, запускающих тупик:

class DLlistener implements ProgressListener {

  private Downloader d;

  public DLlistener(Downloader d){
      this.d = d;
      // here we innocently register ourself to the downloader: this method is synchronized
      d.addListener(this);
  }

  public void onProgress(int n){
    // this method is invoked from a synchronized call in Downloader
    // all we have to do to create a dead lock is to call another synchronized method of that same object from a different thread *while holding the lock*
    DLthread thread = new DLThread(d);
    thread.start();
    thread.join();
  }
}

// this is the other thread which will produce the deadlock
class DLThread extends Thread {
   Downloader locked;
  DLThread(Downloader d){
    locked = d;
  }
  public void run(){
    // here we create a new listener, which will register itself and generate the dead lock
    DLlistener listener(locked);
    // ...
  }
}

Один из способов избежать мертвой блокировки - отложить работу, выполняемую в addListener счет наличия внутренних очередей слушателей, ожидающих добавления/удаления, и периодически Downloader самостоятельно. Это, в конечном счете, зависит от внутренней работы Downloader.run.

Вероятно, проблема в этом коде:

for (ProgressListener listener: listeners)
            listener.onProgress(n);

Когда один поток, который содержит блокировку, вызывает внешний метод, подобный этому (onProgress), тогда вы не можете гарантировать, что реализация этого метода не будет пытаться получить другую блокировку, которая может храниться в разных потоках. Это может вызвать тупик.

Вот классический пример, который показывает, какие трудно отлаживаемые проблемы пытается избежать автор.

UseDownloader класс UseDownloader вызывается downloadSomething.

По мере продвижения загрузки onProgress метод onProgress. Поскольку это вызвано из синхронизированного блока, мотив Downloader заблокирован. В нашем методе onProgress нам нужно заблокировать наш собственный ресурс, в этом случае lock. Поэтому, когда мы пытаемся синхронизироваться при lock мы держим монитор Downloader.

Если другой поток решил, что загрузка должна быть отменена, она вызовет setCanceled. Эти первые тесты done так, чтобы они синхронизировались на мониторе lock а затем removeListener. Но removeListener требует блокировки Downloader.

Такой тупик трудно найти, потому что это происходит не очень часто.

  public static final int END_DOWNLOAD = 100;

  class UseDownloader implements ProgressListener {
    Downloader d;
    Object lock = new Object();
    boolean done = false;

    public UseDownloader(Downloader d) {
      this.d = d;
    }
    public void onProgress(int n) {
      synchronized(lock) {
        if (!done) {
          // show some progress
        }
      }
    }

    public void downloadSomething() {
      d.addListener(this);
      d.start();
    }

    public boolean setCanceled() {
      synchronized(lock) {
        if (!done) {
          done = true;
          d.removeListener(this);
        }
      }
    }
  }

Следующий пример приводит к тупиковой ситуации, потому что MyProgressListener пытается приобрести блокировку Downloader, пока она уже приобретена.

class MyProgressListener extends ProgressListener {
    private Downloader myDownloader;

    public MyProgressListener(Downloader downloader) {
        myDownloader = downloader;
    }

    public void onProgress(int n) {
        // starts and waits for a thread that accesses myDownloader
    }
}

Downloader downloader = new Downloader(...);
downloader.addListener(new MyListener(downloader));
downloader.run();