Кратко и по сути — когда достаточно volatile, а когда нужны Atomic*/synchronized, с примерами нарушений и их симптомами.
Что делает volatile
- Гарантирует видимость: запись в volatile happens-before чтение того же volatile (эффект acquire-release).
- Гарантирует атомарность только для одиночного чтения/записи переменной (все примитивы начиная с Java $(5)$ — включая $\text{long}$/$\text{double}$).
- Не обеспечивает атомарности составных действий (read-modify-write) и не даёт мьютекса/взаимной исключающей блокировки.
Когда volatile достаточно
- Флаг остановки/сигнал между потоками: один писатель, много читателей. Пример: поток в цикле читает флаг и должен немедленно увидеть изменение.
- Публикация ссылки на полностью инициализированный immutable-объект (вместе с final-полями это ещё лучше).
- Double-checked locking для ленивой инициализации при условии, что ссылка помечена volatile.
Когда volatile НЕ достаточно — нужны Atomic*/synchronized/Lock
- Когда действие — составное (чтение + вычисление + запись), например инкремент: $\text{x++}$ — требуется атомарность (AtomicInteger или synchronized).
- Когда нужно поддерживать инвариант между несколькими переменными (обновления нескольких полей должны быть транзакционными) — нужен synchronized/Lock или атомарная структура (например, атомарный объект-держатель).
- Для операций с высококонкурентными счётчиками с большой пропускной способностью — лучше LongAdder/Striped counters.
Конкретные примеры нарушений и их симптомы
1) Невидимость изменения (visibility bug)
Код (без volatile):
```
class Worker {
boolean running = true;
void run() {
while (running) { /* работа */ }
}
void stop() { running = false; }
}
```
Симптом: поток в run() может никогда не заметить stop() и застрять в бесконечном цикле — программа «не останавливается».
2) Потерянные обновления (lost updates) при ++
Код:
```
volatile int counter = 0;
// два потока выполняют:
counter++;
```
Проблем: $\text{counter++}$ = read -> increment -> write; volatile гарантирует видимость, но не атомарность. Симптом: итоговое значение меньше ожидаемого (например, ожидали $N$ инкрементов, получили меньше).
3) Частично сконструированный объект / реордеринг (double-checked locking без volatile)
Код:
```
class Singleton {
static Singleton instance; // без volatile
static Singleton get() {
if (instance == null) {
synchronized(Singleton.class) {
if (instance == null) instance = new Singleton();
}
}
return instance;
}
}
```
Проблем: без volatile возможно реордеринг: ссылка присвоена до окончания конструктора — другой поток увидит не полностью инициализированный объект. Симптомы: NPE, поля со значениями по умолчанию, неконсистентное поведение.
4) Нарушение инварианта между полями
Код:
```
volatile int x, y;
void updateBoth() {
x = 1;
y = 2;
}
void read() {
// другой поток может увидеть x == 1 и y == 0 (старое), нарушая инвариант
}
```
Симптом: чтение наблюдает промежуточное состояние; логика, требующая согласованности полей, ломается.
Чем заменить volatile для защиты составных действий
- AtomicInteger/AtomicLong/AtomicReference: предлагают атомарные операции (getAndIncrement, compareAndSet и т.д.). Подходят для одно-переменных атомарных RMW (read-modify-write).
- LongAdder/Striped counters: для быстрых счетчиков в условиях высокой конкуренции.
- synchronized / ReentrantLock / StampedLock: для защиты инвариантов, критических секций, атомарного обновления нескольких переменных или сложной логики.
- Immutable objects + volatile reference (publish-once): для безопасной публикации состояния целиком.
Краткие правила на практике
- Если нужно только оповестить другие потоки о смене состояния (флаг) или безопасно опубликовать ссылку — volatile достаточно.
- Если нужно атомарно изменить переменную (инкремент, условное обновление) — используйте Atomic*/CAS.
- Если нужно атомарно изменить несколько переменных или поддерживать сложные инварианты — используйте synchronized/Lock.
Резюме (одно предложение): volatile = видимость и упорядоченность одиночных чтений/записей; для атомарных RMW — Atomic*, для инвариантов и сложной синхронизации — synchronized/Lock.