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

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

Поэтому notify() не является передачей управления и не гарантирует ни немедленное продолжение, ни выбор конкретного ожидающего потока.

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

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

Методы wait(), notify() и notifyAll() появились как низкоуровневый механизм координации потоков. Современный код часто использует более специализированные средства java.util.concurrent, но понимание поведения монитора необходимо для корректной работы с ними и для разбора старого кода.

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

Предположим, поток ждёт, пока некоторое условие станет истинным. Другой поток меняет состояние и вызывает notify(), продолжая выполнять работу внутри того же synchronized-участка.

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

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

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

Уведомлённый поток всё ещё не может продолжить выполнение тела после wait(), пока монитор занят. Поток-уведомитель сохраняет монитор до выхода из синхронизированного участка; только после этого начинается обычная конкуренция за монитор.

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

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

final Object monitor = new Object();

Thread waiter = new Thread(() -> {
    synchronized (monitor) {
        try {
            monitor.wait();
            System.out.println("waiter продолжил работу");
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
});

Thread notifier = new Thread(() -> {
    synchronized (monitor) {
        monitor.notify();
        System.out.println("notifier всё ещё владеет монитором");
    }
});

waiter.start();
notifier.start();

Сообщение от notifier в этом примере будет напечатано до продолжения waiter, потому что уведомитель ещё находится внутри синхронизированного участка. Для сложных условий предпочтительнее использовать BlockingQueue, CountDownLatch, Condition или другие высокоуровневые средства, поскольку они явно выражают протокол взаимодействия и уменьшают риск ошибок.

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

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

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

Вариант с notifyAll() проще доказать корректным: все ожидающие заново проверят свои условия, а подходящий поток продолжит работу. Недостаток — эффект «стада»: множество потоков просыпается, конкурирует за монитор и почти все снова засыпают.

Для производственной очереди выбранным решением обычно будет BlockingQueue: она уже содержит корректную блокировку, ожидание условия и публикацию данных между потоками. Это снижает объём ручной синхронизации и устраняет необходимость самостоятельно поддерживать протокол wait/notify.

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

1. Вопрос: Может ли notify() вызвать исключение, если вызывающий поток не владеет монитором?

Ответ: Да. Вызов notify() вне соответствующего synchronized-участка приводит к IllegalMonitorStateException. То же правило действует для wait() и notifyAll(): поток должен владеть монитором объекта, на котором вызывается метод.

2. Вопрос: Нужно ли вызывать notify() после освобождения монитора, чтобы разбуженный поток смог продолжить работу?

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

3. Вопрос: Почему нельзя считать факт возврата из wait() доказательством истинности ожидаемого условия?

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