Код
class Counter {
int c = 0;
void inc() { c++; }
}
в многопоточном окружении небезопасен. Объясню, какие гонки возникают, как воспроизвести, и какие варианты исправления есть (synchronized, AtomicInteger, StampedLock, lock‑free и т.д.), с оценкой влияния на производительность и масштабируемость.

1) Почему проблема возникает

Операция c++ не атомарна: она состоит из чтения c, вычисления c+1 и записи результата обратно. Два потока могут одновременно прочитать одно и то же значение, оба прибавят 1 и оба запишут, в результате одно увеличение потеряно (lost update).Кроме того, без синхронизации возможны проблемы видимости: один поток мог поменять c, другой — этого не увидит сразу (кеши/реордеринг), что усугубляет поведение.

2) Как воспроизвести (простой тест)
Пример теста: N потоков, каждый делает M инкрементов, ожидаемое значение N*M. Часто получаем меньше.

Пример (псевдо‑код Java):
class UnsafeCounter { int c = 0; void inc() { c++; } int get() { return c; } }

void test() throws InterruptedException {
UnsafeCounter ctr = new UnsafeCounter();
int threads = 8, iters = 1_000_000;
Thread[] t = new Thread[threads];
for (int i=0;i<threads;i++) {
t[i] = new Thread(() -> {
for (int j=0;j<iters;j++) ctr.inc();
});
t[i].start();
}
for (Thread tt: t) tt.join();
System.out.println("expected=" + (long)threads*iters + " actual=" + ctr.get());
}

Обычно actual < expected (в зависимости от числа потоков/ядр).

3) Варианты исправления и оценка

A. synchronized
Реализация:
class SynchronizedCounter {
private int c = 0;
synchronized void inc() { c++; }
synchronized int get() { return c; }
}

Плюсы:

Простота, корректность (атомарность и видимость).Поддерживает сложные инварианты (несколько операций можно поместить в один критический раздел).

Минусы:

При большом числе потоков приводит к сериализации — пропускная способность падает.Производительность лучше для небольшого числа потоков; JVM оптимизации (biased lock, thin lock) снижают накладные расходы при низкой или умеренной конкуренции.Масштабируемость: плохая при высокой конкуренции.

Когда использовать:

Когда нужно гарантировать комплексную атомарность (несколько полей), простота важнее максимальной скорости, или нагрузка невысока.

B. AtomicInteger / AtomicLong
Реализация:
class AtomicCounter {
private final AtomicInteger c = new AtomicInteger();
void inc() { c.getAndIncrement(); } // или incrementAndGet()
int get() { return c.get(); }
}

Плюсы:

Lock‑free, использует CAS; быстрый для простых атомарных обновлений.Обычно значительно быстрее synchronized при умеренной и высокой конкуренции.Прост в использовании для простых счетчиков.

Минусы:

При очень высокой конкуренции CAS может часто падать и происходят повторы — ухудшение производительности.Подходит только для простых атомарных операций; сложные группы операций требуют более сложной синхронизации.Не даёт "звёздной" масштабируемости в экстремальной конкуренции (см. LongAdder).

Когда использовать:

Когда нужен простой, точный атомарный счётчик и ожидается средняя/высокая, но не экстремальная конкуренция.

C. LongAdder / LongAccumulator (Java 8+)
Реализация:
LongAdder adder = new LongAdder();
adder.increment();
long value = adder.sum();

Плюсы:

Спроектирован для высокой масштабируемости: использует множество «cell» (stripe) для уменьшения конфликтов CAS; инкременты локальны, чтение суммирует.Отличная производительность при большом числе потоков и частых инкрементах.

Минусы:

Стоимость считывания (sum()) выше, потому что надо суммировать все ячейки.Не всегда нужен строго точный «моментальный» snapshot (sum() даёт сумму, но может быть не атомарной относительно одновременных инкрементов — однако в практике даёт консистентное приближение).Не подходит, если вы обязаны иметь строгую атомарную операцию read‑and‑then‑act на том же значении.

Когда использовать:

Для высоконагруженных счётчиков (метрики, статистика), когда много инкрементов и редкие чтения — лучший выбор.

D. StampedLock
Пример для записи:
class StampedCounter {
private long c = 0;
private final StampedLock sl = new StampedLock();
void inc() {
long stamp = sl.writeLock();
try { c++; } finally { sl.unlockWrite(stamp); }
}
long get() {
long stamp = sl.tryOptimisticRead();
long val = c;
if (!sl.validate(stamp)) {
stamp = sl.readLock();
try { val = c; } finally { sl.unlockRead(stamp); }
}
return val;
}
}

Плюсы:

Поддерживает оптимистические чтения (для читательско‑преобладающих случаев), более производителен, чем ReentrantReadWriteLock.Может быть быстрее, чем synchronized для определённых шаблонов чтений/записей.

Минусы:

Для простой операции инкремента нужно захватывать writeLock — это эксклюзивная блокировка; в этом сценарии преимущества неочевидны по сравнению с synchronized/ReentrantLock.Не реентерабелен; сложнее в использовании.Для чисто интенсивных инкрементов Atomic/LongAdder обычно лучше.

Когда использовать:

Когда есть много читателей и немного писателей; оптимистическое чтение может дать выигрыши.

E. Lock‑free алгоритмы (CAS циклы и т.д.)

AtomicInteger.getAndIncrement() уже реализован как CAS‑основанная lock‑free операция.Для более сложных структур (связные списки, хеш-таблицы) есть lock‑free алгоритмы, использующие CAS, compareAndSet, atomic references, версионные метки, hazard pointers либо GC для управления памятью.
Плюсы:При правильной реализации — очень высокая производительность и отсутствие блокировок (нет deadlock).
Минусы:Сложность реализации, тонкие ошибки (ABA‑проблема, память/GC, корректность).При сильной конкуренции CAS‑повторы могут снижать эффективность.Не всегда практично для сложных состояний.

4) Дополнительные практические замечания

volatile не делает ++ атомарным. volatile нужен для видимости, но не решает проблему lost updates.ReentrantLock — альтернатива synchronized; даёт дополнительные возможности (tryLock, fairness), но по сути — эксклюзивная блокировка с похожими проблемами масштабируемости.False sharing: если много счётчиков или объекты расположены близко в памяти, разные потоки могут мешать друг другу из‑за кеш‑линий. Решение — паддинг/выравнивание (или использовать LongAdder, который распределяет ячейки).Выбор зависит от сценария: частые инкременты/редкие чтения → LongAdder; нужен точный атомарный счетчик с частыми чтениями → AtomicInteger/AtomicLong; сложные транзакции над несколькими полями → synchronized/ReentrantLock.

5) Рекомендации (практическое правило)

Для простой, корректной и быстрой реализации счётчика: используйте AtomicInteger/AtomicLong.Для экстремальной нагрузки с большим количеством параллельных инкрементов и редкими чтениями: LongAdder (лучше масштабируется).Для сложных инвариантов, когда нужно атомарно изменить несколько полей или выполнить серию операций: synchronized / ReentrantLock.StampedLock — хорош для ситуации «много читателей, мало писателей» с преимущественно чтениями; для простого инкремента обычно не лучший выбор.Lock‑free алгоритмы целесообразны, когда вы можете или хотите реализовать и проверить сложную неблокирующую структуру; в большинстве случаев примитивы из java.util.concurrent достаточно.

6) Краткое сравнение производительности/масштабируемости (качественно)

synchronized / ReentrantLock: простая корректность, низкая латентность при малой конкуренции; при высокой конкуренции — производительность сильно падает (серилизация).AtomicInteger: лучшее поведение при конкуренции, без блокировок, но CAS‑конфликты могут вызывать повторные попытки.LongAdder: наилучшая пропускная способность при очень высокой конкуренции для инкрементов; чтение дороже.StampedLock: выигрывает в сценариях с множеством читателей; для частых записей не лучше эксклюзивной блокировки.

Если нужно, могу:

Привести готовые тесты/бенчмарки (JMH) сравнения throughput для synchronized vs AtomicInteger vs LongAdder;Показать код‑паттерны (пример реализации с LongAdder и StampedLock);Объяснить ABA и другие тонкие проблемы lock‑free алгоритмов.