Синхронизация и volatile в Java

Монитор и на чём синхронизироваться

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

На чём синхронизироваться - приватный final-объект, созданный специально для этого. Синхронизация на this опасна тем, что this виден снаружи: чужой код может взять твой замок и устроить взаимную блокировку.

// Отдельная ловушка - синхронизация на строке. Я проверил: литерал «заказ-42» и выражение «заказ-» плюс 42 оказались ОДНИМ объектом, потому что константы вычисляются при компиляции и попадают в общий пул строк. Значит, синхронизация по идентификатору-строке даёт случайный глобальный замок, разделяемый со всем кодом в процессе.

// И про размер: под замком держат только работу с общим состоянием, коротко. Сетевой вызов под замком выстраивает все потоки в очередь, и «многопоточный» сервис начинает работать по одному.

private final Object lock = new Object();
synchronized (lock) { balance += x; }   // своё и коротко
// synchronized ("заказ-" + id) - глобальный замок на весь процесс

монитор

встроенный замок объекта, повторно входим

пул строк

одинаковые константные строки - один объект на процесс

happens-before и безопасная публикация

Модель памяти формализует видимость через отношение happens-before: запись гарантированно видна чтению, если между ними есть такая связь. Создают её выход из синхронизированного блока и вход в него же по тому же монитору, запись и чтение volatile-переменной, а также запуск потока и ожидание его завершения.

Отсюда неочевидное следствие: синхронизировать только запись бесполезно. Читатель без своей стороны связи спокойно видит устаревшее значение - ровно как в замере с флагом. Синхронизация всегда парная.

// volatile - правильный инструмент для флагов и для публикации ссылки на неизменяемый объект. А final-поля безопасно публикуются после конструктора, поэтому неизменяемым объектом можно делиться вообще без синхронизации: состояние не меняется, значит и гонок по нему нет.

happens-before

формальная гарантия, что запись дойдёт до чтения

безопасная публикация

передача объекта другим потокам без гонки по состоянию

wait, notify и взаимная блокировка

Методы wait и notify работают только внутри синхронизированного блока того же монитора: wait отпускает замок и засыпает, notify будит. Железное правило - wait всегда внутри цикла по условию. Причин две: пробуждение без notify формально разрешено, и между notify и фактическим пробуждением условие мог изменить третий поток. Метод notifyAll безопаснее, чем notify.

Взаимная блокировка выглядит так: поток А держит замок 1 и ждёт замок 2, поток Б держит замок 2 и ждёт замок 1. Оба стоят навсегда. Классическое лечение - глобальный порядок захвата: все берут замки в одном и том же порядке, например по возрастанию идентификатора счёта, и цикл ожидания становится невозможен.

// Диагноз ставится по дампу потоков: виртуальная машина сама пишет «Found one Java-level deadlock» и показывает, кто кого ждёт. А главный генератор таких блокировок - вызов чужого кода под своим замком: что этот код захватит внутри, ты не знаешь.

wait в цикле

проверять условие заново после каждого пробуждения

порядок захвата

все берут замки в одном порядке, цикла ожидания нет

Как отвечать: «Что гарантирует volatile и когда его достаточно?»

volatile даёт две гарантии. Первая - видимость: запись одного потока действительно доходит до чтений в других. Вторая - запрет переупорядочения операций вокруг этой переменной. Насколько первая важна, я проверял: цикл по обычному булеву флагу не завершился и через две секунды после того, как другой поток выставил флаг, а с volatile вышел мгновенно. Чего volatile НЕ даёт - атомарности составных операций. Инкремент остаётся гонкой, потому что чтение, увеличение и запись никто не сделал неделимыми; у меня volatile-счётчик терял значения так же, как обычный. Достаточно его там, где один поток пишет, остальные читают, и значение самодостаточно: флаг остановки, публикация ссылки на неизменяемый конфиг. Как только появляется «прочитать и изменить в зависимости от прочитанного», нужен либо атомарный тип со сравнением и обменом, либо замок.

Сильный ответ: обе гарантии названы и подтверждены замером, анти-гарантия подчёркнута отдельно, дан точный критерий применимости - один писатель и самодостаточное значение. Это понимание модели памяти, а не заклинание «volatile для видимости».

На чём валят

• −Синхронизируют только запись. Читатель без своей стороны связи видит устаревшее значение, у меня цикл не вышел вовсе.
• −Ставят volatile на счётчик и считают задачу решённой. Составная операция осталась гонкой.
• −Пишут if вместо while вокруг wait. Пробуждение без notify или третий поток ломают инвариант.
• −Синхронизируются на строке-идентификаторе. Константные строки лежат в общем пуле, и замок становится глобальным.
• −Зовут чужой код под своим замком. Что он захватит внутри, неизвестно, и взаимная блокировка готова.