Коротко: проблема в том, что операция `++` не атомарна — это чтение, изменение, запись — при параллельном выполнении двух потоков ($2$) возможна потеря инкремента (гонка). Ниже — минимум три способа исправить, примеры и обсуждение производительности и альтернатив (акторы/неизменяемость).
1) synchronized
- Суть: поместить инкремент в критическую секцию JVM.
- Пример:
```java
public class Counter {
private int count = 0;
public synchronized void increment() {
count++;
}
public synchronized int get() { return count; }
}
```
- Плюсы: простота, корректность, встроенная поддержка мониторинга и wait/notify.
- Минусы: блокировка потоков (блокирующая), при высокой конкуренции — контекст‑свичи, снижение пропускной способности. JVM оптимизирует `synchronized` (biased locking, escoped locks), поэтому для низкой/умеренной конкуренции производительность часто хорошая.
2) AtomicInteger (CAS, без блокировки)
- Суть: использовать атомарные примитивы с CAS (compare-and-set).
- Пример:
```java
import java.util.concurrent.atomic.AtomicInteger;
public class Counter {
private final AtomicInteger count = new AtomicInteger(0);
public void increment() { count.incrementAndGet(); }
public int get() { return count.get(); }
}
```
- Плюсы: неблокирующая, низкие задержки при небольшой/умеренной конкуренции, простая семантика для отдельных примитивных операций.
- Минусы: при сильной конкуренции CAS может часто терпеть неудачу и повторяться; для высокочастотных инкрементов лучше `LongAdder`.
3) ReentrantLock (явные локи)
- Суть: явный lock/unlock, дополнительные возможности (tryLock, lockInterruptibly, Condition).
- Пример:
```java
import java.util.concurrent.locks.ReentrantLock;
public class Counter {
private int count = 0;
private final ReentrantLock lock = new ReentrantLock();
public void increment() {
lock.lock();
try {
count++;
} finally {
lock.unlock();
}
}
public int get() {
lock.lock();
try { return count; } finally { lock.unlock(); }
}
}
```
- Плюсы: гибкость (таймауты, прерываемость, условия), контроль над справедливостью.
- Минусы: блокирующий; немного более тяжёлый синтаксис; при неверном использовании — deadlock.
Дополнительно (полезно при интенсивных счетчиках)
- LongAdder / LongAccumulator: для очень частых инкрементов лучше масштабируется (шардирование счётчика), позволяет высокую пропускную способность при сильной конкуренции:
```java
import java.util.concurrent.atomic.LongAdder;
LongAdder counter = new LongAdder();
counter.increment();
long value = counter.sum();
```
Почему не `volatile`? `volatile int count` гарантирует видимость, но не делает `++` атомарным — гонка останется.
Производительность — кратко
- При низкой конкуренции: `synchronized` и `AtomicInteger` часто сопоставимы; JVM оптимизирует synchronized.
- При умеренной конкуренции: `AtomicInteger` обычно быстрее из‑за отсутствия блокирования.
- При высокой конкуренции (много потоков инкрементируют): CAS может страдать от многочисленных повторов — `LongAdder` часто даёт лучшую пропускную способность. `ReentrantLock` с высокой конкуренцией приводит к блокировкам и переключениям контекста; с fairness=true — ещё больше накладных расходов.
- Блокирующие механизмы увеличивают задержку, могут вызвать контекст‑свичи и стоянку потоков; неблокирующие (CAS) уменьшают задержки, но сложнее для составных операций.
Когда предпочесть модели без общих мутабельных состояний (акторы, функциональная неизменяемость)
- Масштабируемость и отказоустойчивость: распределённые системы, где состояние локализовано в акторе и передаётся сообщениями (акторы — Akka, Orleans, Erlang) упрощают согласованность и отказоустойчивость.
- Параллелизм без блокировок: функциональная неизменяемость облегчает reasoning и тестирование, позволяет безопасно шарить данные между потоками без синхронизации.
- Сложная логика/составные операции: если требуется согласованная последовательность изменений нескольких сущностей, акторная модель или транзакционная модель проще, чем пытаться согласовать множество локов.
- Реактивные/асинхронные системы: акторы и message-passing лучше для IO‑ориентированных систем с большим количеством тасков и меньшей синхронизацией.
- Минусы: накладные расходы на сообщения/серилизацию, задержки доставки, иной стиль проектирования. Не всегда нужно: для простых счётчиков чаще достаточно Atomic/LongAdder.
Рекомендации практические
- Простой счётчик в многопоточном приложении: использовать `AtomicInteger` или `LongAdder` (для высокой частоты).
- Когда есть сложная критическая секция/несколько полей, изменение которых должно быть атомарным: `synchronized` или `ReentrantLock`.
- Для масштабируемых распределённых систем или сложной бизнес‑логики с высокой частотой параллельных операций: рассмотреть акторы/неизменяемые структуры.
Если нужно — могу показать конкретные бенчмарки или примеры перехода на LongAdder или акторную модель.