Что поток сделает с объектом, если не будет Volatile

Проблема видимости изменений и ключевое слово volatile

Когда один поток изменяет поле обычного (не-volatile) объекта, а другой поток пытается прочитать это значение, возникает проблема видимости изменений. Это один из аспектов модели памяти Java (Java Memory Model, JMM). Без volatile, synchronized или других средств синхронизации второй поток может никогда не увидеть обновлённое значение, либо увидеть его с непредсказуемой задержкой.

Что происходит без volatile?

Основная проблема — оптимизации на уровне процессора и компилятора:

1. Кэширование в регистрах и локальном кэше процессора: Каждый поток может работать со своей локальной копией переменной (например, в регистре или кэше L1/L2 процессора). Запись изменений в основную память (main memory) происходит не сразу, а когда это решит сделать процессор, в соответствии с политиками когерентности кэшей (MESI и др.). Без барьеров памяти, устанавливаемых volatile, другой поток может продолжать читать устаревшее значение из своей локальной кэш-линии.

2. Оптимизации компилятора (reordering): Компилятор JIT и процессор могут переупорядочивать инструкции для повышения производительности, если это не меняет семантику выполнения в пределах одного потока (правило as-if-serial). Однако для многопоточного выполнения такое переупорядочивание может привести к неожиданным результатам.

Пример: Бесконечный цикл видимости

Рассмотрим классический пример:

public class VisibilityProblem {
    // Без volatile - проблемный код
    private static boolean flag = false;

    public static void main(String[] args) {
        // Поток 1: Ждёт и меняет флаг
        new Thread(() -> {
            try {
                Thread.sleep(500); // Имитация работы
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            flag = true; // <-- Изменение
            System.out.println("Flag set to true");
        }).start();

        // Поток 2: Ожидает изменения флага
        new Thread(() -> {
            while (!flag) { // <-- Чтение. МОЖЕТ ЗАВИСНУТЬ!
                // Пустое ожидание
            }
            System.out.println("Flag is now true, loop exited.");
        }).start();
    }
}

В этом коде второй поток может никогда не выйти из цикла while, несмотря на то, что первый поток установил flag = true. Это происходит потому, что второй поток кэшировал начальное значение false (например, в регистре процессора) и не обязан перечитывать его из основной памяти на каждой итерации цикла.

Как volatile решает проблему?

Ключевое слово volatile модифицирует поведение переменной в модели памяти Java:

1. Гарантирует видимость: Когда поток записывает значение в volatile-переменную, это изменение немедленно становится видимым для всех остальных потоков. Запись проходит через барьер записи (write barrier), который сбрасывает значение из кэшей потока в основную память.
2. Запрещает переупорядочивание: Компилятор и процессор не могут переставить операции чтения/записи volatile-переменной относительно других операций памяти, согласно правилам happens-before. Это предотвращает тонкие ошибки, связанные с порядком операций.
3. Гарантирует атомарность для чтения/записи примитивов (кроме long/double): Чтение и запись volatile-переменной всегда происходят как единая неделимая операция (даже для long и double).

Исправленная версия:

    // Решение: добавление volatile
    private static volatile boolean flag = false;

Теперь, когда первый поток выполнит flag = true, второй поток гарантированно увидит это изменение и выйдет из цикла.

Альтернативы volatile

volatile — не единственный способ обеспечить видимость. Механизмы, которые также устанавливают барьеры памяти и создают отношение happens-before:

• Синхронизированные блоки/методы (synchronized): Выход из блока synchronized (отпускание монитора) happens-before последующий вход в тот же блок (захват монитора). Все изменения, сделанные в блоке, становятся видимыми для следующего потока, который захватит этот монитор.
• Классы из java.util.concurrent: Например, AtomicInteger, ConcurrentHashMap, CountDownLatch. Их внутренняя реализация использует комбинацию volatile и атомарных инструкций процессора (CAS - Compare-And-Swap).
• Финальные (final) поля: После корректного завершения конструктора объекта, значения его final-полей гарантированно видны всем потокам без дополнительной синхронизации.

Вывод

Без volatile (или другой синхронизации) поток может работать с устаревшей, некорректной копией данных, что приводит к гейзенам (heisenbugs) — ошибкам, которые сложно воспроизвести и отладить. Ключевое слово volatile является относительно лёгковесным инструментом для обеспечения видимости изменений одной переменной между потоками, но оно не обеспечивает атомарность составных операций (например, i++). Для атомарных операций необходимы synchronized или атомарные классы из java.util.concurrent.atomic.