Что такое visibility problem

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

🟢 Junior Level

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

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

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

Аппаратный уровень: каждое ядро CPU сохраняет изменения в своих локальных регистрах, Store Buffers и кэшах L1/L2, не сбрасывая их немедленно в общую оперативную память (RAM).
Программный уровень (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

Модификатор volatile: гарантирует, что чтение и запись всегда идут через барьер памяти напрямую в когерентный кэш процессора, а JIT не поднимает чтение в регистры.
Блок synchronized / ReentrantLock: при входе в блок кэш инвалидируется, при выходе — все измененные переменные сбрасываются в память (Monitor Lock Rule).
Классы java.util.concurrent.atomic.* (AtomicBoolean, AtomicInteger): инкапсулируют volatile-поля с операциями CAS.
Ключевое слово 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) ]

Store Buffer: Когда ядро 1 выполняет запись, оно не ждет, пока соседние ядра подтвердят инвалидацию своих кэшей. Оно помещает запись в асинхронный Store Buffer и сразу переходит к следующим инструкциям. Ядро 2 еще долгое время читает устаревшие данные.
Протокол MESI: Кэш-линии синхронизируются по протоколу MESI (Modified, Exclusive, Shared, Invalid). Барьеры памяти (StoreLoad / MFENCE), генерируемые для volatile, заставляют процессор полностью опустошить Store Buffer (drain) и принудительно дождаться обработки очереди инвалидации (Invalidation Queue).

Когда несколько независимых 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-компилятор переставляет инструкции для оптимизации и кэширует значения в регистрах процессора.

Память процессора читается строками по 64 байта (Cache Line). Если два потока на разных ядрах часто пишут в две разные volatile-переменные, случайно оказавшиеся в одной строке кэша, ядра непрерывно отбирают эту строку друг у друга через сигналы инвалидации протокола MESI, вызывая лавинообразное падение производительности.

Типичные ошибки и Red Flags

🚩 Зависимость от System.out.println для «синхронизации» потоков во время отладки.
🚩 Использование обычной не-volatile переменной в качестве флага остановки потока.
🚩 Предположение, что на одноядерной или локальной машине код с проблемой видимости упадет так же, как на многопроцессорном сервере (на локальном компьютере потоки делят один кэш, маскируя баг).
🚩 Путаница между проблемой видимости (Visibility) и проблемой атомарности (Atomicity).