Кратко: Java Memory Model (JMM) задаёт отношение happens‑before (hb), которое определяет гарантии видимости и допустимые перестановки операций между потоками. Если действие A happens‑before действие B (обозначим $A{\to }_{hb}B$), то все побочные эффекты A гарантированно видимы B, и реорганизатор/процессор не может вынести A за пределы этого отношения так, чтобы B видел устаревшее состояние.
Ключевые правила happens‑before (важнейшие)
- Program order rule: действия в одном потоке упорядочены по программному порядку: для любого A перед B в том же потоке $A{\to }_{hb}B$.
- Monitor (synchronized) rule: unlock(m) в одном потоке ${\to }_{hb}$ последующему lock(m) в другом потоке (для того же монитора).
- Volatile rule: запись в volatile-переменную v ${\to }_{hb}$ последующего чтения v (в другом потоке).
- Thread start/join: вызов t.start() ${\to }_{hb}$ первых действий в новом потоке; все действия в потоке ${\to }_{hb}$ успешному возврату из t.join().
- Transitivity: если $A{\to }_{hb}B$ и $B{\to }_{hb}C$ то $A{\to }_{hb}C$.
volatile
- Что делает: чтение/запись volatile создают hb-ребро: запись v ${\to }_{hb}$ последующее чтение v.
- Семантика: запись volatile действует как release (не позволяет переместить предыдущие записи после неё), чтение как acquire (не позволяет переместить последующие чтения/записи перед ним). Это обеспечивает видимость изменений других переменных, выполненных до записи volatile.
- Ограничения: volatile не даёт взаимного исключения — оно не делает несколько операций атомарными (если нужна атомарность сложной операции, нужен синхронизатор). Для примера:
- T1: $\text{write}(x=1);\text{write}(v=1);$ (v — volatile)
- T2: $\text{read}(v);\text{read}(x);$
По правилам: $\text{write}(x){\to }_{hb}\text{write}(v)$, $\text{write}(v){\to }_{hb}\text{read}(v)$, $\text{read}(v){\to }_{hb}\text{read}(x)$ ⇒ $\text{write}(x){\to }_{hb}\text{read}(x)$, значит T2 гарантированно увидит $x=1$.
synchronized
- Что делает: вход в synchronized (lock) — acquire; выход (unlock) — release. Unlock одного потока happens‑before последующего lock того же монитора в другом потоке.
- Семантика: обеспечивает и видимость (все изменения до unlock видимы после lock), и взаимное исключение (в один момент только один поток держит монитор).
- Пример: T1: lock(m); x=1; unlock(m); T2: lock(m); r=x; unlock(m); — по hb гарантировано, что T2 увидит x=1.
Видимость, упорядочение и оптимизации
- Если между операциями нет пути happens‑before — это data race; поведение чтения/записи в presence of data race не имеет гарантий JMM (может увидеть старые/неожиданные значения).
- JMM позволяет компилятору и CPU переставлять/кэшировать операции, если такие перестановки не нарушают hb. Volatile и synchronized вводят границы, которые блокируют соответствующие перестановки.
- Volatile дешевле, чем synchronized для простых сигналов/флагов, но не заменяет защиту сложных инвариантов.
Короткие практические рекомендации
- Используйте synchronized (или другие блокировки) для защиты инвариантов и атомарности составных действий.
- Используйте volatile для флагов/одноэлементной видимости или для реализации простых publish/subscribe сигналов.
- Для сложной атомарной логики используйте java.util.concurrent (Atomic*, Locks и др.), которые опираются на JMM и CAS.
Это основные моменты: happens‑before даёт формальные гарантии видимости и запрет на перестановки; volatile обеспечивает acquire/release-видимость для одной переменной; synchronized обеспечивает acquire/release плюс взаимное исключение.