Мониторы в Java: как устроена синхронизация потоков под капотом

Что происходит при вызове wait():

1. Поток освобождает монитор и переходит в состояние WAITING (или TIMED_WAITING для wait(long)).
2. Поток добавляется в _WaitSet монитора.
3. Другой поток, захвативший монитор, может вызвать notify() или notifyAll(), чтобы разбудить ожидающие потоки.
4. Пробуждённый поток не сразу получает монитор — он конкурирует за него с другими потоками, как будто только что вызвал synchronized.

⚠️ Внимание: Вызов notify() пробуждает произвольный поток из _WaitSet. Если в очереди ожидают потоки с разной логикой (например, производители и потребители), используйте notifyAll(), иначе рискуете получить lost notification — ситуацию, когда уведомление теряется, и поток засыпает навсегда.

5. Проблемы классических мониторов и альтернативы

Несмотря на удобство, мониторы в Java имеют несколько критичных недостатков:

• 🔄 Отсутствие разделения на чтение/запись: монитор не различает операции чтения и модификации, что приводит к избыточной блокировке в сценариях с частым чтением.
• ⏳ Невозможность тайм-аута при захвате: synchronized не поддерживает tryLock() с тайм-аутом, что усложняет обработку deadlock’ов.
• 🎯 Нет поддержки прерываний: заблокированный на synchronized поток нельзя прервать через Thread.interrupt().
• 📊 Проблемы с производительностью: при высокой конкуренции мониторы могут стать узким местом из-за coarse-grained locking.

Альтернативы:

• 🔓 ReentrantLock: поддерживает tryLock(), прерывания и разделение на чтение/запись (ReentrantReadWriteLock).
• 🧵 StampedLock: оптимизирован для сценариев с частым чтением и редкой записью.
• ⚡ VarHandle + volatile: для низкоуровневой синхронизации без блокировок.

Нужна возможность прерывания заблокированного потока|Требуется тайм-аут при захвате блокировки|Нужно разделение на чтение/запись|Необходима справедливая очередь (fair lock)-->

6. Примеры кода: правильное и неправильное использование

Антипаттерн: двойная проверка без volatile (классическая ошибка double-checked locking):

public class Singleton {
private static Singleton instance;

public static Singleton getInstance() {
if (instance == null) {          // 1-я проверка (без синхронизации)
synchronized (Singleton.class) {
if (instance == null) {  // 2-я проверка (внутри синхронизации)
instance = new Singleton();
}
}
}
return instance;
}
}

Проблема: без volatile другой поток может увидеть частично инициализированный объект из-за реордеринга инструкций. Исправление:

private static volatile Singleton instance;

Правильный паттерн: использование wait/notify для производитель-потребитель:

public class Queue {
private final List<Object> items = new ArrayList<>();

public synchronized void put(Object item) throws InterruptedException {
while (items.size() >= MAX_SIZE) {
wait();  // освобождаем монитор и ждём
}
items.add(item);
notifyAll();  // будим все потоки (на случай, если ждут потребители)
}

public synchronized Object take() throws InterruptedException {
while (items.isEmpty()) {
wait();
}
Object item = items.remove(0);
notifyAll();  // будим все потоки (на случай, если ждут производители)
return item;
}
}

⚠️ Внимание: Всегда используйте while, а не if в циклах с wait()! Поток может проснуться спонтанно (спурьезное пробуждение, spurious wakeup) без вызова notify(). Без повторной проверки условия это приведёт к ошибкам.

7. Мониторы и современные многопоточные фреймворки

В эпоху reactive programming и virtual threads (Project Loom) классические мониторы теряют актуальность. Например:

• 🌐 Vert.x/Netty: используют event loop и неблокирующий I/O, где synchronized неприменим.
• ⚡ Project Loom: виртуальные потоки делают блокировки менее болезненными, но synchronized по-прежнему может приводить к pinning (привязке виртуального потока к носителю).
• 📦 Akka: акторы заменяют разделяемую память сообщениями, устраняя необходимость в мониторах.

Тем не менее, мониторы остаются фундаментальной частью JVM, и их понимание критично для:

• 🔍 Отладки легаси-кода.
• 🛠️ Оптимизации «горячих» секций с высокой конкуренцией.
• 📚 Чтения исходников JDK (например, ArrayBlockingQueue внутри использует ReentrantLock, но логика аналогична мониторам).

FAQ: Частые вопросы о мониторах в Java