Коротко — причина: гонка (race condition). Операция (x++) неатомарна: это чтение значения, вычисление (+1) и запись обратно; при параллельных потоках эти шаги перекрываются и часть приращений теряется.

Почему происходит:

(x++) = прочитать (x) → вычислить (x+1) → записать в (x). При одновременном исполнении два потока могут прочитать одно и то же значение и оба записать одно и то же (x+1), итог меньше ожидаемого.

Четыре способа исправления (с кратким плюсом/минусом и примером):

1) synchronized

Простой и корректный способ.Минус: при высокой конкуренции — блокировка и потеря пропускной способности.Пример:
class C { int x = (0); synchronized void inc() { x++; } int get(){ return x; } }

2) AtomicInteger / AtomicLong (CAS)

Атомарное приращение без явной блокировки: use getAndIncrement()/incrementAndGet().Хорош при умеренной конкуренции.Пример:
class C { java.util.concurrent.atomic.AtomicInteger x = new java.util.concurrent.atomic.AtomicInteger((0)); void inc(){ x.getAndIncrement(); } int get(){ return x.get(); } }

3) LongAdder (или LongAccumulator)

Оптимизирован для высокой конкуренции: множество счетчиков с фьюжном при чтении.Лучше масштабируется, но чтение (sum) чуть дороже и не всегда точное в промежуточный момент.Пример:
class C { java.util.concurrent.atomic.LongAdder x = new java.util.concurrent.atomic.LongAdder(); void inc(){ x.increment(); } long get(){ return x.sum(); } }

4) Использование потокобезопасной очереди + single consumer

Все потоки помещают события/запросы в BlockingQueue; один поток-консьюмер выполняет инкремент. Устраняет конкуренцию на счётчике.Подходит, если логически можно сериализовать операции.Пример:
BlockingQueue q = new LinkedBlockingQueue<>();
// producer: q.put(() -> counter++);
// single consumer: while(...) q.take().run();

Тесты и методики локализации:

1) Репродукция гонки (stress test)

Запустить много потоков (N), каждый выполнить (M) инкрементов; ожидание: итог = (N \times M).Пример теста:
создаём (N) потоков, каждый выполняет цикл for i in (1..M) { c.inc(); } ;ждём join всех потоков;assert c.get() == (N \times M).Увеличивайте (N) и (M) (например, десятки/сотни потоков и миллионы итераций) чтобы повысить вероятность проявления гонки.

2) Поддержание воспроизводимости

Используйте подкручиваемые задержки (Thread.yield(), случайные sleep) внутри inc() для увеличения окна гонки (только в тестах).Запускайте многократно (например, 1000 прогонов) — гонки часто проявляются не всегда.

3) Инструменты для детектирования/диагностики

jcstress (OpenJDK) — фреймворк для детального стресс-тестирования низкоуровневой конкуренции.Java Flight Recorder (JFR) / Java Mission Control — посмотреть блокировки, задержки, contention.VisualVM / async-profiler — для профилирования потоков и контеншенов.jstack — снимать дампы потоков, смотреть, кто где висит.SpotBugs / Error Prone — статический анализ на паттерны небезопасного доступа.Сторонние race-detectors: существуют инструменты/агенты, но для Java основной путь — jcstress + профайлеры; для нативного кода — ThreadSanitizer (не для чистого JVM).Логирование с идентификаторами потоков и счётчиками (в тестах) помогает увидеть, где теряются приращения.

4) Методика локализации

Сначала воспроизведите баг стабильным стресс-тестом.Подмените реализацию на AtomicInteger/LongAdder/synchronized — если с ними всё ок, значит проблема действительно в атомарности.Используйте jcstress для выявления слабых сценариев.Снимите несколько jstack в момент выполнения, посмотрите состояние потоков (waiting/blocked).Профилируйте latency/contended monitors (JFR/async-profiler) — увидите горячие точки блокировок или высокая контеншен-статистика.

Рекомендации

Для простого счётчика при небольшой конкуренции — AtomicInteger.При высокой частоте инкрементов — LongAdder.Если операция более сложная (несколько полей) — synchronized или ReentrantLock.Если можно сериализовать операции — очередь с single consumer часто даёт лучший throughput и простую семантику.

Если нужно — могу прислать пример полного стресс-теста (код) и варианты исправлений.