Как исправить CountDownLatch с неатомарным счётчиком без AtomicInteger?

Как исправить использование CountDownLatch с неатомарным счётчиком?

• проблема: счётчик не является атомарным, поэтому возникают состояния гонки
• решение 1: использовать AtomicInteger вместо обычного счётчика (если это запрещено, вариант отпадает)
• решение 2: выполнять операции с обычным int под синхронизацией
• хранить счётчик и работать с ним под lock (synchronized)
• объединить все уменьшения и проверки в одном синхронизированном блоке
• CountDownLatch уже обеспечивает синхронизацию через вызовы await/countDown
• для собственной логики можно применить ReentrantLock вместе с condition
• в более сложных сценариях возможна замена на Semaphore или Phaser
• итог: если AtomicInteger использовать нельзя, необходимо строго синхронизировать доступ к счётчику, предотвращая гонки и неконсистентное состояние

Детально:

CountDownLatch internally handles synchronization for its own counter, однако при использовании отдельного внешнего неатомарного int-счётчика вместо countDown() и await() (например, собственного manual counter) многопоточное уменьшение без атомарности или синхронизации приводит к race condition — несколько потоков могут одновременно изменить значение, что вызовет ошибочное состояние или deadlock.

Корректный вариант — заменить счётчик на AtomicInteger либо заключить все операции над обычным int в synchronized блок (монитор). Так обеспечиваются атомарность и видимость изменений для разных потоков.

Пример исправления без AtomicInteger:

private final Object lock = new Object();
private int counter;

public void decrement() {
synchronized (lock) {
counter--;
if (counter == 0) {
lock.notifyAll();
}
}
}

public void await() throws InterruptedException {
synchronized (lock) {
while (counter > 0) {
lock.wait();
}
}
}

Такой вариант корректно работает с неатомарным счётчиком, но требует внимательного управления блокировкой, чтобы не допустить deadlock или пропуска сигналов.

Резюме: при отказе от AtomicInteger необходимо синхронизировать все операции со счётчиком, чтобы связка CountDownLatch и неатомарного счётчика оставалась корректной и потокобезопасной.

Подробный ответ

Основной ответ

Если в коде используется CountDownLatch и неатомарный счётчик, например обычный int, а применять AtomicInteger нельзя, доступ к счётчику нужно синхронизировать явно. Сам CountDownLatch потокобезопасен и правильно используется для ожидания завершения, однако операции инкремента и декремента следует защищать от условий гонки.

Наиболее простой и распространённый вариант — пометить методы, изменяющие счётчик, ключевым словом synchronized либо синхронизировать соответствующий участок кода. В результате одновременно изменять значение сможет только один поток, что исключает некорректные состояния.

Ключевые моменты

• CountDownLatch предназначен для ожидания заданного числа завершившихся событий, но атомарность внешних переменных он не обеспечивает.
• Если AtomicInteger недоступен, для последовательного доступа к счётчику потребуются блокировки, например synchronized.
• Применение volatile в этом случае не решает задачу эффективно: операция инкремента неатомарна и всё равно потребует блокировки.
• Можно выбрать и другие синхронизированные структуры, например Lock из java.util.concurrent.locks, однако для быстрого исправления без atomic наиболее прямым решением будет synchronized.

Практический контекст

В реальных проектах для защиты простых счётчиков часто используют synchronized(this) либо отдельный монитор метода, обновляющего счётчик, тогда как CountDownLatch продолжает отвечать за ожидание завершения потоков. Это простой и надёжный подход, в том числе для Java 8+.

Пример:

private int counter = 0;
private final Object lock = new Object();

public void increment() {
synchronized(lock) {
counter++;
}
}

При этом CountDownLatch продолжает использоваться без изменений для ожидания завершения.

В итоге обновление счётчика остаётся корректным и атомарным даже без применения AtomicInteger.