Проблема: выражение `count++` не атомарно — это последовательность действий «прочитать, увеличить, записать». В многопоточной среде возможна состояние гонки: два потока читают одно и то же значение и оба записывают одно и то же значение+1 → один инкремент теряется.
Примеры интерливингов:
- Поток A читает $v$.
- Поток B читает $v$.
- A пишет $v+1$.
- B пишет $v+1$.
Ожидалось $2$ инкремента, результат — только $1$. Если $n$ потоков должны увеличить счётчик по одному, ожидаемая сумма $=n$, но при гонках фактическая $<n$.
Методы синхронизации (кратко, с плюсами/минусами):
1) synchronized (монитор)
- Пример:
public synchronized void increment() { count++; }
- Плюсы: простая корректность (атомарность и видимость).
- Минусы: блокировка потоков при конкурентном доступе, контенция, возможна потеря параллелизма; стоимость переключения потоков при ожидании.
2) java.util.concurrent.locks.ReentrantLock
- Плюсы: явный контроль, tryLock, поддержка fairness.
- Минусы: чуть более дорогой объект, при высокой конкуренции всё равно сериализация.
3) AtomicInteger / AtomicLong (CAS)
- Пример:
private final AtomicInteger count = new AtomicInteger();
public void increment() { count.getAndIncrement(); }
- Плюсы: неблокирующая (lock-free) реализация на базе CAS; обычно быстрее при низкой/умеренной конкуренции.
- Минусы: при сильной конкуренции частые повторные CAS (спины), возможны высокие CPU-ретраи.
4) LongAdder / LongAccumulator
- Пример:
private final LongAdder count = new LongAdder();
public void increment() { count.increment(); }
- Плюсы: лучше масштабируется при высокой конкуренции за счёт шардинга внутренних ячеек; высокая пропускная способность для операций инкремента.
- Минусы: чтение значения (sum) менее атомарно/дороже; чуть больше памяти; при низкой конкуренции может быть избыточным.
5) volatile
- volatile обеспечивает видимость (чтение последней записи), но не обеспечивает атомарность `count++`. Нельзя использовать вместо синхронизации для инкремента.
6) Шардинг/striping
- Разделить счётчик на $k$ локальных счётчиков (по потоку/по CPU) и суммировать при чтении — уменьшает contention, полезно для сильно нагруженных счётчиков.
Влияние на производительность в многопроцессорной системе:
- Контенция за один атомарный ресурс/лок — основная проблема: при увеличении числа потоков $n$ время ожидания и число отказов CAS растут, пропускная способность может деградировать.
- Когерентность кэша (MESI): атомарные записи/блокировки приводят к «перемещению» линии кэша между ядрами — дорогостоящие задержки (cache-line bouncing).
- sync/locks паркуют потоки при высоком конфликте → контекстные переключения, высокая латентность.
- CAS может быть предпочтительнее при низкой или средней конкуренции; LongAdder/шардинг — при высокой конкуренции.
- False sharing: размещение соседних счётчиков в одной cache-line вызывает лишний трафик; выравнивание/паддинг может помочь.
Рекомендации:
- Для простых случаев с низкой конкуренцией: AtomicInteger/AtomicLong.
- Для высокой частоты инкрементов и большой конкуренции: LongAdder.
- Если нужен строгий атомарный снимок и консистентность чтения: synchronized/ReentrantLock или комбинация (например, Atomic + периодическая агрегация).
- Избегать volatile вместо синхронизации для `count++`.
- Профилируйте: измерьте contention, latency и throughput; при проблемах рассматривайте шардирование и устранение false sharing.
Коротко: `count++` без защиты ведёт к потерям инкрементов; выбирайте Atomic/Lock/LongAdder в зависимости от требуемой корректности и ожидаемой конкуренции — Atomic для низкой, LongAdder/шардинг для высокой.