🧵 Розділ 9 · Питання #11

В чому перевага Atomic класів перед synchronized

Головна перевага Atomic класів перед synchronized полягає у використанні неблокуючого (lock-free) підходу на базі апаратних інструкцій процесора CAS (Compare-And-Swap) замість в...

🧵 Багатопоточність 📄 Вихідний Markdown

🟢 Junior Level

Коротка відповідь для співбесіди (30 секунд)

Головна перевага Atomic класів перед synchronized полягає у використанні неблокуючого (lock-free) підходу на базі апаратних інструкцій процесора CAS (Compare-And-Swap) замість великовагового песимістичного блокування:

  1. Продуктивність без конкуренції та при помірному навантаженні: Atomic-операції виконуються за одиниці наносекунд (~3–10 ns), оскільки не вимагають захоплення монітора, викликів ядра ОС і перемикання контексту потоків (Context Switch, що забирає ~1000–5000 ns).
  2. Відсутність взаємних блокувань (Deadlock-Free): окремі операції над Atomic-змінними в принципі не можуть спричинити взаємне блокування (Deadlock), оскільки потоки не утримують ексклюзивні замки.
  3. Стійкість до збоїв потоків: якщо потік, що виконує операцію з Atomic, зависне, буде витіснений планувальником ОС або впаде з помилкою, решта потоків продовжать безперешкодно працювати (гарантія системного прогресу Lock-Free).

Порівняльна таблиця: Atomic проти synchronized

Характеристика AtomicInteger / AtomicLong synchronized
Модель конкуренції Оптимістична (Lock-Free / CAS) Песимістична (Блокуюча)
Стан конкуруючого потоку RUNNABLE (продовжує обчислення) BLOCKED (паркується планувальником ОС)
Перемикання контексту ОС ❌ Відсутнє (робота в user-space) ⚠️ Присутнє при ескалації до Fat Lock
Ризик Deadlock ❌ Неможливий для поодиноких операцій ⚠️ Можливий при неправильному порядку захоплення
Атомарність кількох полів ❌ Ні (лише одне поле або посилання) ✅ Так (будь-яка складна транзакція)
Енергоспоживання при сильній конкуренції ⚠️ Високе (спалює 100% CPU у spin-loop) ✅ Низьке (сплячі потоки не витрачають такти CPU)

Приклади на Java 21

import java.util.concurrent.atomic.AtomicInteger;

public class AtomicVsSyncDemo {

    // 1. Підхід з Atomic: Lock-free лічильник
    public static class LockFreeCounter {
        private final AtomicInteger count = new AtomicInteger(0);

        public void increment() {
            count.incrementAndGet(); // Атомарна процесорна інструкція (lock xadd)
        }

        public int get() {
            return count.get();
        }
    }

    // 2. Підхід із synchronized: песимістичне блокування
    public static class SynchronizedCounter {
        private int count = 0;

        public synchronized void increment() {
            count++; // Захоплення монітора, критична секція, вихід
        }

        public synchronized int get() {
            return count;
        }
    }
}

🟡 Middle Level

Архітектурний виграш: User-Space проти Kernel-Space

При захопленні монітора synchronized в умовах конкуренції віртуальна машина JVM змушена ескалувати монітор до великовагового (Heavyweight Lock / Fat Lock):

                       Великоваговий synchronized:
[ User Space: Потік ] -> [ Системний виклик futex/mutex ] -> [ Kernel Space: ОС ]
                                                                   │
    [ Context Switch: Збереження регістрів CPU, скидання TLB ] <───┘
                                    │
                                    v
                       Затримка: ~1000 - 5000 ns
  1. Потік переводиться в режим ядра (перехід кілець захисту Ring 3 $\to$ Ring 0).
  2. Операційна система зберігає стан регістрів процесора, витісняє потік з черги виконання та паркує його у стан WAITING/BLOCKED.
  3. Скидається процесорний буфер асоціативної трансляції адрес (TLB — Translation Lookaside Buffer), що призводить до промахів кешу інструкцій і даних.

Atomic-класи працюють виключно в просторі користувача (User-Space):

  • Виклик incrementAndGet() компілюється JIT C2 у пряму машинну інструкцію lock xadd [memory], eax.
  • Потік ніколи не переходить у режим ядра і не паркується операційною системою. Затримка становить лише ~3–10 ns.

Гарантії системного прогресу: Lock-Free vs Blocking

У паралельних обчисленнях математично доведено рівні гарантій прогресу:

+--------------------------------------------------------------------------+
| Lock-Free (Atomic класи)                                                 |
| У будь-який момент часу хоча б один потік системи гарантовано            |
| здійснює корисний прогрес, навіть якщо інші потоки призупинені.          |
+--------------------------------------------------------------------------+
                                     vs
+--------------------------------------------------------------------------+
| Blocking (synchronized)                                                  |
| Якщо потік-власник блокування засинає (GC STW-пауза, Page Fault,         |
| витіснення планувальником OS), ВСІ інші потоки повністю паралізовані.    |
+--------------------------------------------------------------------------+

Проблема Priority Inversion (Інверсія пріоритетів):

У системах із synchronized потік із низьким пріоритетом може захопити монітор, після чого бути витісненим потоком із середнім пріоритетом. У результаті високопріоритетний потік, що очікує на цей же монітор, зависає на невизначений термін. Atomic-класи принципово не схильні до класичної інверсії пріоритетів.

Обмеження: Коли Atomic поступається synchronized

Використовувати Atomic-класи всюди — антипатерн. Існують три ключові сценарії, де synchronized кращий:

1. Складені транзакції над кількома змінними

Atomic-клас може атомарно змінити лише своє власне значення. Він не може узгоджено оновити дві незалежні змінні:

// ПОМИЛКА: між кроком 1 і кроком 2 стан неузгоджений!
accountA.addAndGet(-100);
accountB.addAndGet(100);

// synchronized вирішує це завдання тривіально:
synchronized (transferLock) {
    balanceA -= 100;
    balanceB += 100;
}

2. Тривалі операції в критичній секції

Якщо всередині критичної секції потрібно виконати парсинг JSON, звернення до диска або складний розрахунок, оптимістичний CAS-цикл призведе до нескінченних повторів:

// КАТАСТРОФА ДЛЯ CPU: при 10 потоках складні обчислення будуть
// виконуватися марно десятки разів при кожному невдалому CAS!
atomicRef.updateAndGet(state -> calculateHeavyAnalytics(state));

🔴 Senior Level

Апаратний рівень: Cache Bouncing та Bus Saturation

При зростанні кількості активно записуючих потоків до 16, 32 або 64 ядер настають фундаментальні фізичні обмеження архітектури x86/ARM:

                      Точка деградації Atomic (Cache Thrashing)
Потік 1 (Ядро 0) ───┐
Потік 2 (Ядро 1) ───┼──> [ LOCK CMPXCHG ] ──> Шторм сигналів Invalidate по шині UPI
Потік 3 (Ядро 2) ───┘                                     │
                                                          v
                                     [ 100% завантаження шини когерентності ]
                                     [ Потоки крутять 100% CPU без прогресу ]
  1. Кожна операція з префіксом LOCK викликає широкомовний сигнал інвалідації кеш-лінії у всіх сусідніх ядрах процесора за протоколом MESI.
  2. Кеш-лінія безперервно переміщується між ядрами (Cache Bouncing / Cache Ping-Pong).
  3. Відбувається насичення пропускної спроможності міжпроцесорної шини (Interconnect Bus Saturation).
  4. Парадокс високого навантаження: при 64+ конкуруючих потоках на запис звичайний synchronized починає випереджати AtomicLong за пропускною здатністю, оскільки synchronized паркує очікуючі потоки в ОС, звільняючи шину пам’яті та кеші CPU для корисної роботи одного потоку.

Вирішення проблеми конкуренції: Еволюція до LongAdder

Для усунення апаратних колізій шини в Java 8 було додано клас LongAdder:

                       Архітектура LongAdder (Striped64)
Потоки 1, 2   ──>  [ Cell 0 (value) ] (Кеш-лінія 0, 64 байти)
Потоки 3, 4   ──>  [ Cell 1 (value) ] (Кеш-лінія 1, 64 байти) ──> sum() підсумовує
Потоки 5, 6   ──>  [ Cell 2 (value) ] (Кеш-лінія 2, 64 байти)     всі комірки
  • Замість однієї спільної змінної LongAdder використовує внутрішній масив комірок Cell[].
  • Потоки динамічно розподіляються по різних комірках на основі свого хешу (Thread.currentThread().threadLocalRandomProbe).
  • Комірки Cell захищені внутрішньою анотацією @jdk.internal.vm.annotation.Contended, що додає 128 байтів порожнього простору навколо поля для повного виключення False Sharing.

Аналіз профілювання: Сліпа пляма Thread Dump

Критичний нюанс експлуатації в Production:

  • Якщо зависає synchronized: у дампі потоків (jstack) легко локалізувати проблему: ```text “pool-thread-1” #12 prio=5 tid=… waiting for monitor entry java.lang.Thread.State: BLOCKED (on object monitor)
    • waiting to lock <0x000000076a123456> ``` Одразу видно заблокований ресурс і потік-власник.
  • Якщо деградує Atomic (CAS Contention): потоки крутяться у спін-циклі та мають стан: 
    "pool-thread-1" #12 prio=5 tid=... runnable
   java.lang.Thread.State: RUNNABLE
   at java.util.concurrent.atomic.AtomicInteger.incrementAndGet(AtomicInteger.java:234)

    Потоки формально знаходяться в статусі RUNNABLE, утилізація процесора сервером підскакує до 100%, але корисна робота не виконується. Діагностувати таку проблему можна лише через профілювальники CPU (Async-Profiler, JFR) за гарячим слідом методів Unsafe.getAndAddInt або VarHandle.compareAndSet.

🎯 Шпаргалка для інтерв’ю

1. 30-секундний есенс (Elevator Pitch)

Atomic-класи надають неблокуючу (lock-free) альтернативу synchronized для атомарних операцій над окремими змінними та посиланнями. Їхня головна перевага — робота повністю у просторі користувача (User-Space) на рівні апаратних інструкцій процесора (lock xadd, lock cmpxchg), що виключає дорогі системні виклики ядра ОС і перемикання контексту потоків. Вони виключають виникнення Deadlock для поодиноких операцій. Проте при екстремальній конкуренції сотень потоків на запис скалярні Atomic-класи деградують через інвалідацію кеш-ліній процесора, поступаючись шардованому LongAdder або блокуванням.

2. 4 каверзних питання з глибокими відповідями

Питання 1: Чому в thread dump при зависанні застосунку на Atomic-класах потоки виглядають як абсолютно здорові RUNNABLE?

Відповідь: З точки зору планувальника операційної системи та віртуальної машини JVM потік, що виконує CAS-цикл (while (!compareAndSet(...))), безперервно виконує інструкції процесора. Він не викликає системних блокувань (futex), не переходить у режим очікування і не передає керування планувальнику ОС. Тому його стан у дампі відображається як RUNNABLE. Це небезпечна «сліпа пляма» традиційного моніторингу: процесор завантажений на 100%, потоки «працюють», але система фактично перебуває в стані Live-Lock, нескінченно повторюючи невдалі спроби CAS.

Питання 2: Що станеться із системою, якщо потік аварійно завершиться (наприклад, через OOM або Kill) посеред операції Atomic проти середини блоку synchronized?

Відповідь:

  • В Atomic-класах будь-яка операція неподільна на рівні інструкції процесора. Потік або встиг виконати атомарну інструкцію, або ні. Всередині JVM немає незавершеного проміжного стану, тому інші потоки не будуть заблоковані та продовжать нормальну роботу.
  • У synchronized байткод захищений таблицею винятків, і при штатному вильоті Throwable монітор буде звільнено. Однак якщо потік зависне в нескінченному циклі, піде в нескінченний I/O або потік буде аварійно зупинено на рівні нативного коду ОС, монітор залишиться назавжди захопленим, і всі інші потоки зависнуть у черзі BLOCKED назавжди.

Питання 3: У якому конкретно сценарії synchronized перевершить AtomicLong за продуктивністю та енергоефективністю на сервері з 64+ ядрами?

Відповідь: При масовій конкуренції на запис сотень паралельних потоків за єдину змінну (High Contention Write Storm). В AtomicLong усі 64 ядра будуть безперервно виконувати LOCK CMPXCHG, забиваючи міжпроцесорну шину інвалідаційними пакетами (Cache Bouncing) та споживаючи 100% потужності CPU. У той самий час synchronized після кількох адаптивних обертів спінінгу примусово переведе 63 потоки у стан BLOCKED, припаркувавши їх у ядрі ОС. Сплячі потоки не звертаються до шини пам’яті та не палять процесор, дозволяючи єдиному потоку-власнику швидко виконати інкремент без опору.

Питання 4: Чи можна побудувати транзакцію переказу грошей між двома рахунками без блокувань, використовуючи лише AtomicInteger?

Відповідь: Використовуючи два незалежні AtomicInteger — не можна. Операції над двома різними комірками пам’яті неможливо об’єднати в єдиний атомарний крок на рівні процесора. Між списанням з рахунку $A$ і зарахуванням на рахунок $B$ сторонній потік зможе прочитати проміжний неузгоджений стан (гроші зникли із системи).
Єдиний спосіб реалізувати це lock-free — об’єднати баланси обох рахунків у єдиний незмінний об’єкт даних (наприклад, record AccountsState(int balA, int balB)) і атомарно оновлювати посилання на нього через єдиний AtomicReference<AccountsState> методом updateAndGet().

3. Типові помилки та Red Flags

❌ “Atomic-класи завжди працюють швидше, ніж synchronized.”
Правильно: При низькій та помірній конкуренції Atomic істотно швидший. Але при сильній конкуренції на запис (десятки потоків) настає деградація через постійні промахи CAS. Для лічильників під високим навантаженням слід використовувати LongAdder.

❌ “Використання кількох Atomic змінних забезпечує потокобезпечність методу: if (flag.get()) { count.incrementAndGet(); }.”
Правильно: Це помилка «Check-Then-Act». Кожна операція атомарна окремо, але їхня взаємна послідовність не атомарна. Стан прапорця може змінитися одразу після перевірки.

❌ “AtomicInteger рятує від будь-яких Deadlock у коді застосунку.”
Правильно: Поодинокі виклики Atomic дійсно не можуть викликати Deadlock. Проте складні неблокуючі алгоритми на базі кількох CAS-циклів при помилках у логіці можуть увійти в Live-Lock, який з точки зору системи аналогічний нескінченному зависанню.

4. Пов’язані питання