Java wait () / join (): почему это не тупиковая ситуация?

Метод join () внутренне вызывает wait (), что приводит к снятию блокировки (объекта Thread).

Смотрите код join () ниже:

public final synchronized void join(long millis) 
    throws InterruptedException {
    ....
    if (millis == 0) {
       while (isAlive()) {
         wait(0);  //ends up releasing lock
       }
    }
    ....
}

Причина, по которой ваш код видит это и не видит в целом:. Причина, по которой ваш код видит это, а не наблюдается в целом, заключается в том, что метод join () waits () в Thread object и, следовательно, снимает блокировку с самого объекта Thread, и поскольку ваш метод run () также синхронизируется с тем же объектом Thread, вы видите этот неожиданный сценарий.

Реализация Thread.join использует ожидание, которое снимает блокировку, поэтому не мешает другому потоку получить блокировку.

Вот пошаговое описание того, что происходит в этом примере:

Запуск потока MyThread в основном методе приводит к тому, что новый поток выполняет метод запуска MyThread. Основной поток спит целую секунду, давая новому потоку достаточно времени для запуска и получения блокировки на объекте MyThread.

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

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

Уведомление происходит, когда основной поток снимает блокировку. Поскольку новый поток находился в режиме ожидания, установленном для блокировки, в то время, когда основной поток вызвал уведомление, новый поток получает уведомление и просыпается. Он может получить блокировку, выйти из метода ожидания и завершить выполнение метода выполнения, наконец сняв блокировку.

Завершение нового потока приводит к тому, что все потоки, ожидающие его блокировки, получают уведомление. Это пробуждает основной поток, он может получить блокировку и проверить, что новый поток мертв, затем он выйдет из метода соединения и завершит выполнение.

/**
 * Waits at most <code>millis</code> milliseconds for this thread to 
 * die. A timeout of <code>0</code> means to wait forever. 
 *
 * @param      millis   the time to wait in milliseconds.
 * @exception  InterruptedException if any thread has interrupted
 *             the current thread.  The <i>interrupted status</i> of the
 *             current thread is cleared when this exception is thrown.
 */
public final synchronized void join(long millis) 
throws InterruptedException {
long base = System.currentTimeMillis();
long now = 0;

if (millis < 0) {
        throw new IllegalArgumentException("timeout value is negative");
}

if (millis == 0) {
    while (isAlive()) {
    wait(0);
    }
} else {
    while (isAlive()) {
    long delay = millis - now;
    if (delay <= 0) {
        break;
    }
    wait(delay);
    now = System.currentTimeMillis() - base;
    }
}
}

В дополнение к другим ответам: я не вижу упоминания о join() снятии каких-либо блокировок в документации по API, поэтому такое поведение фактически зависит от реализации.

Узнай из этого:

• не создавайте подклассы Thread, вместо этого используйте реализацию Runnable, переданную вашему объекту потока.
• не синхронизировать / ждать / уведомлять об объектах, которые вам не "принадлежат", например где вы не знаете, кто еще может синхронизировать / ждать / уведомлять об этом.