Краткий ответ

Поток полностью освобождает монитор объекта на время ожидания. Перед возвратом из wait() он обязан снова захватить этот монитор; поэтому после уведомления поток не продолжает выполнение немедленно.

Исторический контекст

Механизм wait/notify появился как часть объектных мониторов Java для координации потоков через условие, а не для активного опроса состояния. Он решает проблему, при которой поток должен уступить монитор и процессор до тех пор, пока другой поток не изменит состояние, имеющее значение для продолжения работы.

Постановка проблемы

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

Неверно считать notify() передачей управления или гарантией выполнения ожидающего потока. Уведомлённый поток сначала должен конкурировать за монитор с другими потоками и только после повторного захвата сможет продолжить работу.

Подробное решение

Object.wait() разрешён только потоку, который владеет монитором данного объекта. Вызов освобождает весь монитор, включая все уровни повторного входа этого потока, после чего поток переходит в состояние ожидания.

Когда другой поток вызывает notify() или notifyAll() на том же объекте, ожидающий поток становится кандидатом на продолжение, но монитор ему не передаётся напрямую. После выхода уведомляющего потока из синхронизированной секции ожидающий поток снова конкурирует за монитор и возвращается из wait() только после успешного захвата.

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

final Object lock = new Object();
boolean ready = false;

synchronized (lock) {
    while (!ready) {
        lock.wait();
    }
    // Условие подтверждено после повторного захвата монитора
}

При прерывании поток также должен восстановить владение монитором перед тем, как wait() завершится исключением InterruptedException; состояние прерывания при этом очищается самим исключением. Если важно сохранить сигнал для вышестоящего кода, его обычно восстанавливают вызовом Thread.currentThread().interrupt().

Существенное ограничение — wait() связан с конкретным объектом-монитором и требует ручного поддержания условия. Для более сложных протоколов часто предпочтительнее BlockingQueue, CountDownLatch, Condition или другие средства java.util.concurrent, поскольку они явно выражают назначение синхронизации и уменьшают риск ошибок.

Ситуация из практики

В производителе и потребителе производитель после добавления элемента уведомляет ожидающего потребителя. Вариант с постоянной проверкой очереди тратит процессор и требует аккуратной настройки задержек, а вариант с wait/notify эффективнее, но требует общего монитора, цикла проверки условия и корректной обработки прерываний.

Практичнее использовать BlockingQueue: её put() и take() уже объединяют хранение данных, ожидание условия и необходимые гарантии видимости. Это снижает объём собственного кода; компромисс состоит в том, что поведение приходится подстраивать под семантику готовой очереди, а не полностью контролировать протокол ожидания.

Что кандидаты часто упускают

Допустимо ли заменить while вокруг wait() на if?

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

Освобождает ли wait() только один уровень повторного входа в монитор?

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

Чем отличается notify() от notifyAll() с точки зрения продолжения работы?

notify() переводит в состояние готовности один произвольно выбранный ожидающий поток, а notifyAll() — все ожидающие потоки. Ни один из них не гарантирует немедленное выполнение или успешное прохождение условия: каждый разбуженный поток должен заново получить монитор и повторно проверить условие. notifyAll() обычно безопаснее при нескольких разных условиях на одном мониторе, но может вызвать лишние пробуждения и конкуренцию за монитор.