Перейти на PRO

Какой будет результат инкремента (`i++`) общей переменной типа `int` из нескольких потоков без синхронизации?

Тип вопроса: Java Core Вероятность: 10% Категория: Java Разработчик

Ответ

Результат будет непредсказуемым и меньше ожидаемого итогового значения. Операция i++ не является атомарной. Она состоит из трех шагов: 1) чтение значения, 2) увеличение, 3) запись нового значения. Потоки могут перекрывать эти шаги, приводя к состоянию гонки (race condition) и потере обновлений.

Демонстрация проблемы:

public class UnsafeCounter {
    private int count = 0;
    public void increment() { count++; } // НЕБЕЗОПАСНО!
    public int getCount() { return count; }
}

// Запуск двух потоков, каждый инкрементирует счетчик 100_000 раз
// Итоговое значение, скорее всего, будет меньше 200_000.

Правильные решения:

  1. Использование AtomicInteger (наиболее предпочтительно для счетчиков):

    private AtomicInteger atomicCount = new AtomicInteger(0);
public void safeIncrement() {
    atomicCount.incrementAndGet(); // Атомарная операция
}

  2. Синхронизированный метод или блок:

    private int syncCount = 0;
public synchronized void safeIncrement() { syncCount++; }
// Или
private final Object lock = new Object();
public void safeIncrement() {
    synchronized (lock) { syncCount++; }
}

  3. Использование volatile НЕ решает проблему инкремента, так как ++ — это операция «чтение-изменение-запись». volatile гарантирует только видимость изменений, но не атомарность составных операций.

Ответ 18+ 🔞

А, слушай, смотри, вот этот твой i++ — это же классика, блядь! Прям учебник по тому, как на ровном месте выстрелить себе в ногу, ёпта!

Ты думаешь: "Ну что такого? Плюсик поставил, увеличил число, че тут может пойти не так?" А вот нихуя! Эта операция — она не атомарная, понимаешь? То есть внутри она разваливается на три отдельных шага, как говно в унитазе: сначала прочитать значение, потом его увеличить, потом записать обратно. И пока один поток это своё говно размазывает, второй уже лезет в ту же яму, и они начинают друг другу на голову насрать! Это и есть состояние гонки, блядь, race condition, когда все бегут, а в итоге нихуя не прибегают.

Вот смотри, накидал тебе пример, как это выглядит:

public class UnsafeCounter {
    private int count = 0;
    public void increment() { count++; } // НЕБЕЗОПАСНО, ёпта!
    public int getCount() { return count; }
}

// Запускаешь два потока, каждый тупо долбит счетчик по сто тысяч раз.
// И что в итоге? А в итоге — нихуя! Ну то есть не двести тысяч, а какое-то левое число, обычно меньше. Обновления теряются, как носки в стиралке, блядь!

Ну и че делать-то, спрашиваешь? А делать вот что, бошка думай!

Правильные решения, чтобы не облажаться:

  1. AtomicInteger — это твой бро, блядь! Самый отжатый вариант для счетчиков.

    private AtomicInteger atomicCount = new AtomicInteger(0);
public void safeIncrement() {
    atomicCount.incrementAndGet(); // Вот это — атомарная операция, чётко, ясно, без подлянки.
}

  2. Старая добрая синхронизация. Можно на весь метод повесить synchronized, можно на отдельный объект-замок.

    private int syncCount = 0;
public synchronized void safeIncrement() { syncCount++; } // Всё, теперь очередь, сука!
// Или так, чтоб поизящнее:
private final Object lock = new Object();
public void safeIncrement() {
    synchronized (lock) { syncCount++; } // Тоже работает, как швейцарские часы.
}

  3. И главное, запомни раз и нахуй: volatile тут НЕ катит! Это частая ошибка, ёпта! volatile гарантирует, что все потоки увидят свежее значение, но он нихуя не делает операцию ++ атомарной! Потоки всё так же будут читать, увеличивать и записывать вразнобой. Так что не ведись на эту удочку, это как пытаться остановить поезд бумажкой — бесполезно, блядь.

Вот так-то, дружок. Многопоточность — она хитрая жопа, тут надо головой думать, а не просто плюсики тыкать.

© ХакСобесов, 2026
support@hacksobesov.com