Кратко по сути: при двух потоках, которые выполняют некординированное увеличение счётчика типа `count++`, возможна потеря обновления — ожидалось $‘2‘$ после двух инкрементов, фактически получено $‘1‘$. Причина — операция неатомарна (чтение, +1, запись).
1) Как обнаружить
- Репродуцировать стресс-тестом: запустить многопоточно множество инкрементов и сверить итог с ожидаемым (например, ожидание $‘N‘$, результат < $‘N‘$).
- Увеличить шанс коллизий: синхронный барьер (`CyclicBarrier`) чтобы потоки выполняли инкремент одновременно.
- Инструменты: jcstress (OpenJDK Concurrency Stress), SpotBugs/ErrorProne (статический анализ), профайлеры/дампы (`jstack`, VisualVM, Java Flight Recorder) для поиска неожиданных блокировок/параллелизма.
- Логирование/телеметрия: фиксировать несоответствия между ожидаемыми и фактическими значениями при повторных запусках.
2) Способы устранения (с краткими примерами)
- Синхронизация (простая и понятная, подходит для простых сценариев и когда нужен атомарный блок):
```java
class Counter {
private int count = 0;
synchronized void increment() { count++; }
synchronized int get() { return count; }
}
```
Плюс: простота, корректность; Минус: блокировка, ограниченная пропускная способность при высокой конкуренции.
- ReentrantLock (явная блокировка, можно с таймаутами/условиями):
```java
ReentrantLock lock = new ReentrantLock();
lock.lock();
try { count++; } finally { lock.unlock(); }
```
- Атомарные операции (без блокировок, лучше при низкой/средней конкуренции):
```java
AtomicInteger count = new AtomicInteger(0);
count.incrementAndGet(); // атомарно
```
Можно использовать `compareAndSet` или `updateAndGet` для сложной логики.
- Высокопроизводительные счётчики для сильной конкуренции:
```java
LongAdder counter = new LongAdder();
counter.increment();
long total = counter.sum();
```
`LongAdder` выгоден при большом числе потоков, т.к. распределяет обновления по ячейкам.
- Важное замечание: `volatile` не делает `count++` атомарным — он гарантирует видимость, но не атомарность.
- CAS-цикл (если нужна сложная логика без блоков):
```java
AtomicInteger a = new AtomicInteger(0);
int prev, next;
do {
prev = a.get();
next = /* вычисление от prev */;
} while (!a.compareAndSet(prev, next));
```
3) Дизайн без общего состояния (рекомендуется, когда возможно)
- Thread confinement: каждый поток хранит свой локальный счётчик (`ThreadLocal` или поля потока), агрегация по завершении:
```java
ThreadLocal tl = ThreadLocal.withInitial(() -> 0);
tl.set(tl.get() + 1);
```
- Локальная агрегация + периодическое флашение в общий агрегатор (уменьшает частоту синхронизаций).
- Модель акторов / очереди сообщений: все изменения проходят через однопоточный обработчик (например, `ExecutorService` с 1 потоком) — гарантирует последовательность без ручных блокировок.
- Функциональный/иммутабельный дизайн: избегать изменяемого общего состояния вообще.
4) Как выбирать
- Низкая конкуренция, простые счётчики: `AtomicInteger` / `AtomicLong`.
- Высокая конкуренция и только инкременты/суммы: `LongAdder`.
- Сложные атомарные операции на нескольких полях или транзакции: `synchronized` / `ReentrantLock`.
- Если возможно — перепроектировать на безобщесостоянийную модель (конфайнмент, акторы).
Резюме: обнаруживайте через стресс-тесты и инструменты (jcstress, профайлеры), исправляйте либо синхронизацией/блокировками, либо неблокирующими атомарными примитивами (`Atomic*`, `LongAdder`), либо устраняя общее состояние архитектурно.