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

Що таке visibility problem

Причина криється у дворівневій природі оптимізацій:

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

🟢 Junior Level

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

Visibility Problem (Проблема видимості) — це фундаментальна проблема багатопоточності, за якої зміна змінної одним потоком не видна іншому потоку, що виконується на сусідньому процесорному ядрі.

Причина криється у дворівневій природі оптимізацій:

  1. Апаратний рівень: кожне ядро CPU зберігає зміни у своїх локальних регістрах, Store Buffers та кешах L1/L2, не скидаючи їх негайно в загальну оперативну пам’ять (RAM).
  2. Програмний рівень (JIT): JIT-компілятор кешує значення змінної в регістрі процесора (Loop Invariant Hoisting), вважаючи, що раз поточний потік її не змінює, перечитувати її з пам’яті немає сенсу.

Наочний приклад нескінченного циклу на Java 21

public class VisibilityProblemDemo {

    // ❌ БЕЗ volatile: потік reader зависне назавжди!
    private static boolean stopRequested = false;

    public static void main(String[] args) throws InterruptedException {
        Thread reader = new Thread(() -> {
            int count = 0;
            while (!stopRequested) {
                count++; // JIT оптимізує це в: if (!stopRequested) while(true) count++;
            }
            System.out.println("Потік завершено, count = " + count);
        });

        reader.start();
        Thread.sleep(100);

        // Головний потік змінює прапорець:
        stopRequested = true;
        System.out.println("Головний потік виставив stopRequested = true");

        reader.join(2000);
        if (reader.isAlive()) {
            System.err.println("ПОТІК ЗАВИС! Відбулася втрата видимості (Visibility Problem).");
            System.exit(1);
        }
    }
}

🟡 Middle Level

4 способи вирішення проблеми видимості в Java

  1. Модифікатор volatile: гарантує, що читання та запис завжди проходять через бар’єр пам’яті безпосередньо в когерентний кеш процесора, а JIT не піднімає читання в регістри.
  2. Блок synchronized / ReentrantLock: при вході в блок кеш інвалідується, при виході — всі змінені змінні скидаються в пам’ять (Monitor Lock Rule).
  3. Класи java.util.concurrent.atomic.* (AtomicBoolean, AtomicInteger): інкапсулюють volatile-поля з операціями CAS.
  4. Ключове слово final: поля, ініціалізовані в конструкторі, отримують гарантію Final Field Freeze після завершення конструктора.

JIT-Оптимізація: Loop Invariant Hoisting

Чому потік зависає в циклі while (!stopRequested)? Серверний JIT-компілятор (C2) виконує агресивну оптимізацію:

Вихідний Java-код:
while (!stopRequested) {
    // тіло циклу не змінює stopRequested
}

Після оптимізації C2 (Hoisting):
if (!stopRequested) {
    while (true) {
        // Читання stopRequested винесено з циклу в регістр!
        // Зміни з оперативної пам'яті ніколи більше не будуть прочитані!
    }
}

Небезпечний фокус налагодження: Якщо додати всередину циклу System.out.println(...), потік може раптово перестати зависати. Всередині println використовується synchronized(this) для блокування потоку виведення, що неявно змушує JVM скинути локальні регістри ядра! Але покладатися на це в production категорично заборонено.

🔴 Senior Level

Апаратна архітектура: Store Buffers, Invalidation Queues та MESI

На рівні сучасного багатоядерного CPU затримки пам’яті визначають усе:

  • Регістри ядра: 1 такт CPU (~0.3 нс).
  • Кеш L1: 4–5 тактів (~1 нс).
  • Оперативна пам’ять (RAM): 200–300 тактів (~50–100 нс).
[ Core 1 ] ──► [ Store Buffer ] ──► [ L1/L2 Cache (M) ]
                                             │  (Invalidate Message)
                                             ▼
[ Core 2 ] ◄── [ Invalidate Queue ] ◄── [ L1/L2 Cache (I) ]
  1. Store Buffer: Коли ядро 1 виконує запис, воно не чекає, поки сусідні ядра підтвердять інвалідацію своїх кешів. Воно поміщає запис в асинхронний Store Buffer і відразу переходить до наступних інструкцій. Ядро 2 ще довгий час читає застарілі дані.
  2. Протокол MESI: Рядки кешу синхронізуються за протоколом MESI (Modified, Exclusive, Shared, Invalid). Бар’єри пам’яті (StoreLoad / MFENCE), які генеруються для volatile, змушують процесор повністю спустошити Store Buffer (drain) і примусово дочекатися обробки черги інвалідації (Invalidation Queue).

Апаратний дефект: False Sharing (Хибне розділення)

Коли кілька незалежних volatile-змінних розташовуються поруч у купі, вони потрапляють в один 64-байтний рядок кешу (Cache Line):

public class FalseSharingDemo {
    public volatile long count1 = 0; // 8 байтів
    public volatile long count2 = 0; // 8 байтів (лежать в одному 64-байтному рядку!)
}
  • Якщо Ядро 1 безперервно оновлює count1, а Ядро 2 оновлює count2, вони інвалідують рядок кешу одне в одного (Cache Bouncing).
  • Швидкість виконання падає у 50–100 разів.

Senior Рішення: Використання анотації @jdk.internal.vm.annotation.Contended (або ручного padding 128 байтами пустишок), яка змушує JVM виділити окремий ізольований рядок кешу під поле.

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

30-секундна відповідь

«Visibility Problem — це розсинхронізація стану змінної між потоками через багаторівневе кешування CPU (Store Buffers, L1/L2 кеші) та JIT-оптимізації (такі як винесення читання з циклу — Loop Invariant Hoisting). Без спеціальних бар’єрів пам’яті потік може нескінченно читати старе значення змінної з регістра свого ядра. Проблема вирішується використанням volatile, блоків synchronized, атоміків (AtomicInteger) або final-полів. При налагодженні додавання println може маскувати проблему через приховану синхронізацію всередині потоків введення-виведення.»

Зведена таблиця гарантій видимості

Інструмент Забезпечує видимість? Забезпечує атомарність? Алокації пам’яті
Звичайне поле (int x) ❌ Ні ❌ Ні Нуль
volatile int x 🟢 Так ❌ Ні (x++ зламається) Нуль
synchronized(lock) 🟢 Так 🟢 Так Захоплення монітора
AtomicInteger 🟢 Так 🟢 Так (CAS) Об’єкт обгортки
final int x 🟢 Так (після конструктора) 🟢 Імутабельно Нуль

Топ-4 каверзних запитання на інтерв’ю

1. Як JIT-оптимізація Loop Invariant Hoisting перетворює звичайний цикл на нескінченний?

  • JIT-компілятор бачить, що всередині тіла циклу змінна прапорця не змінюється. Вважаючи, що код виконується в ізольованому контексті, компілятор виносить читання змінної з тіла циклу нагору, зберігаючи результат у регістрі процесора: if (!flag) while(true). У результаті зміни, записані іншими потоками в пам’ять, більше ніколи не зчитуються.

2. Чому додавання System.out.println() або Thread.sleep() всередину завислого циклу змушує його завершитися?

  • Всередині методу System.out.println використовується синхронізація (synchronized(this) на PrintStream). А метод Thread.sleep() змушує потік тимчасово поступитися ядром операційній системі. В обох випадках відбувається перемикання контексту або бар’єр монітора, що змушує процесор і JVM скинути регістрові оптимізації та перечитати змінні з пам’яті. Це класична помилка «flaky tests».

3. У чому різниця між апаратною та програмною причиною проблеми видимості?

  • Апаратна причина: ядра процесора не пишуть безпосередньо в повільну RAM, а використовують Store Buffers та роздільні кеші L1/L2 з відкладеною інвалідацією за протоколом MESI.
  • Програмна причина: JIT-компілятор переставляє інструкції для оптимізації та кешує значення в регістрах процесора.

4. Що таке False Sharing і як воно пов’язане з volatile-змінними?

  • Пам’ять процесора зчитується рядками по 64 байти (Cache Line). Якщо два потоки на різних ядрах часто пишуть у дві різні volatile-змінні, які випадково опинилися в одному рядку кешу, ядра безперервно відбирають цей рядок одне в одного через сигнали інвалідації протоколу MESI, викликаючи лавиноподібне падіння продуктивності.

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

  • 🚩 Залежність від System.out.println для «синхронізації» потоків під час налагодження.
  • 🚩 Використання звичайної non-volatile змінної як прапорця зупинки потоку.
  • 🚩 Припущення, що на одноядерній або локальній машині код із проблемою видимості впаде так само, як на багатопроцесорному сервері (на локальному комп’ютері потоки ділять один кеш, маскуючи баг).
  • 🚩 Плутанина між проблемою видимості (Visibility) та проблемою атомарності (Atomicity).

Пов’язані теми