Кратко о модели памяти Java (JMM) и почему volatile не заменяет synchronized; пример, когда volatile достаточен.
1) Основные идеи JMM (сжато)
- Каждый поток имеет «локальную память» (кеш регистров/кэши), основная общая память — heap.
- Видимость и порядок операций определяются отношением happens-before; если действие A happens-before B, то все эффекты A видимы в B.
- Синхронизирующие действия, создающие happens-before: вход/выход из монитора (synchronized), запись/чтение volatile, старт/join потоков, запись final-поля при правильной публикации.
- synchronized обеспечивает и взаимное исключение, и memory-fence: выход из synchronized публикует все изменения, вход их читает.
2) Что делает volatile
- volatile обеспечивает видимость и частичные правила упорядочивания: запись в volatile создаёт release-политику, последующее чтение того же volatile — acquire; запись $W_v$ happens-before чтению $R_v$: $W_v\to R_v$.
- Запись/чтение отдельной volatile-переменной атомарны (для типов кроме long/double в старых JVM; сейчас volatile long/double тоже атомарны).
- volatile запрещает определённые виды переупорядочивания относительно этих операций.
3) Почему volatile НЕ заменяет synchronized в общем случае
- volatile не даёт атомарности для составных операций. Например, операция инкремента — это последовательность: чтение, изменение, запись; сама по себе $x++$ не атомарна. Использование volatile не делает её атомарной: два потока могут одновременно прочитать, оба увеличить и обе записи потеряют одно увеличение. Формально: $x++$ = R, compute, W — между R и W нет синхронизации.
- volatile не обеспечивает взаимного исключения и не защищает согласованность инвариантов, которые затрагивают несколько полей. Если изменение требует атомарного обновления нескольких переменных или проверки-с-установкой (check-then-act), нужен synchronized или атомарные структуры (Atomic*).
- synchronized даёт как взаимное исключение, так и полную memory-fence при выходе/входе монитора; это важно, когда нужно гарантировать, что несколько связанных полей видны одновременно.
4) Примеры
a) Когда volatile НЕ достаточен (гонка на инкремент):
```java
class Counter {
volatile int count;
void inc() {
count++; // небезопасно: read-modify-write не атомарно
}
}
```
Здесь возможно потеря инкрементов. Правильные варианты: использовать synchronized или AtomicInteger:
```java
synchronized void inc() { count++; }
// или
AtomicInteger count = new AtomicInteger();
count.incrementAndGet();
```
b) Когда volatile вполне достаточен (флаг остановки, safe publication immutable объекта)
- Флаг остановки:
```java
class Worker implements Runnable {
private volatile boolean running = true;
public void run() {
while (running) {
// работа
}
}
public void stop() { running = false; } // гарантированная видимость другому потоку
}
```
Здесь достаточно volatile: одно поле, простая запись/чтение, не нужны атомарные операции или инварианты.
- Публикация полностью инициализированного immutable-объекта:
```java
class Config { final int a; Config(int a){ this.a = a; } }
volatile Config cfg;
void update() { cfg = new Config(42); } // запись в volatile публикует 42
void use() {
Config c = cfg;
if (c != null) {
// гарантированно увидим корректное поле c.a
}
}
```
Запись в volatile гарантирует, что все действия до записи (конструирование объекта) happen-before чтению volatile в другом потоке, поэтому immutable-объект безопасно публикуется.
5) Вывод (в два предложения)
- Используйте volatile для простых случаев видимости одного поля (флаги, safe publication immutable объектов).
- Для составных операций, поддержания инвариантов нескольких полей или необходимости взаимного исключения — используйте synchronized/Locks или атомарные примитивы.