До Java 5 модель памяти Java (JMM) страдала от слабых гарантий видимости памяти, что делало многие популярные идиомы конкурентного программирования небезопасными. Шаблон Double-Checked Locking появился в конце 1990-х как предполагаемая оптимизация производительности для ленивой инициализации, но содержал фатальный дефект, связанный с переупорядочиванием инструкций. JSR-133 в 2004 году переопределил семантику ключевого слова volatile, чтобы обеспечить порядок памяти acquire-release, специально для решения таких проблем видимости без накладных расходов полной синхронизации.
Без volatile виртуальная машина Java (JVM) и архитектуры процессоров допускают переупорядочивание инструкций, так что присвоение ссылки переменной может произойти до завершения выполнения конструктора. Это создает окно, в котором другой поток может увидеть ненулевую ссылку на объект, поля которого содержат значения по умолчанию или неинициализированные значения, что приводит к непредсказуемому поведению или NullPointerException. Опасность конкурентности особенно коварна, потому что проявляется только при определенных временных условиях и моделях памяти аппаратного обеспечения, что делает ее трудно воспроизводимой во время тестирования.
Объявление поля экземпляра как volatile вставляет барьер памяти, который устанавливает отношение happens-before между записью в конструкторе и любыми последующими чтениями другими потоками. Это предотвращает переупорядочивание компилятором и процессором записи в volatile поле с предшествующими записями в конструкторе, обеспечивая, что объект полностью сконструирован до того, как его ссылка станет видимой. Шаблон позволяет потокам проверять ссылку без блокировки после инициализации, обеспечивая как безопасность потоков, так и высокую производительность.
public class ConnectionPool { private static volatile ConnectionPool instance; private ConnectionPool() { // Тяжелая инициализация } public static ConnectionPool getInstance() { if (instance == null) { synchronized (ConnectionPool.class) { if (instance == null) { instance = new ConnectionPool(); } } } return instance; } }
Микросервис с высокой пропускной способностью, обрабатывающий платежи, требовал синглтона ConnectionPool для управления JDBC соединениями с кластером PostgreSQL. В периоды пиковых нагрузок тысячи потоков одновременно вызывали getInstance(), когда сервис только начинал работать, что требовало стратегии инициализации, безопасной для потоков, минимизирующей конкуренцию за блокировки. Последовательность инициализации включала установление TCP сокетов, выделение прямых байтовых буферов и выполнение запросов на проверку схемы, что делало жадную инициализацию чрезмерно дорогой для сценариев автоматического масштабирования.
Жадная инициализация включала создание пула в статическом инициализаторе. Этот подход гарантировал безопасность потоков за счет механики загрузки класса и полностью исключал необходимость synchronized блоков. Однако установление соединений требовало три секунды TCP рукопожатий и обмена учетными данными, что нарушало соглашение об уровне сервиса по временам холодного старта во время событий автоматического масштабирования.
Синхронизированный метод обернул метод getInstance() с помощью ключевого слова synchronized. Хотя это исправило состояние гонки, сериализуя весь доступ, это привело к значительному ухудшению производительности под нагрузкой. Профилирование показало, что после инициализации потоки тратят ненужные циклы на получение монитора, несмотря на неизменность полностью сконструированного пула, добавляя примерно 18 миллисекунд задержки на вызов.
Двойная проверка блокировки с volatile была выбрана как оптимальный подход. Это решение использовало несинхронизированный быстрый путь для проверки на null, за которым следовал synchronized блок для критической секции с повторной проверкой на null внутри, чтобы предотвратить множественные инстанциации. Модификатор volatile гарантировал, что полностью инициализированное состояние пула было немедленно видно всем ядрам CPU по завершении публикации, что уравновешивало ленивую инициализацию с нулевыми накладными расходами на блокировки после старта.
Выбранное решение обеспечило успешную ленивую инициализацию без блокировок, позволяя сервису обрабатывать 50 000 запросов в секунду с подмиллисекундными временами отклика после начального создания пула. Реализация устранила состояния гонки во время старта, обеспечивая при этом доступ без блокировок во время работы в стационарном состоянии, предотвращая наблюдаемые случаи NullPointerException, которые ранее возникали при высококонкурентных сценариях. Мониторинг подтвердил, что JVM правильно обрабатывала видимость памяти на всех 64 ядрах без явной синхронизации после того, как синглтон был установлен.
Почему шаблон двойной проверки блокировки требует двух различных проверок на null, а не одной синхронизированной проверки?
Первая проверка осуществляется вне synchronized блока, чтобы предоставить быстрый, незаблокированный путь для обычного случая, когда экземпляр уже существует. Вторая проверка внутри synchronized блока является необходимой, потому что несколько потоков могут одновременно пройти первую проверку на null, когда экземпляр все еще не инициализирован. Без этой второй проверки каждый поток последовательно захватывал бы блокировку и создавал бы отдельные экземпляры, нарушая свойство синглтона. Внутренняя проверка гарантирует, что только первый поток, вошедший в критическую секцию, выполняет конструкцию, в то время как последующие потоки обнаруживают, что экземпляр уже инициализирован и пропускают создание.
Как модель памяти Java различает гарантии видимости записи volatile и выход из блока synchronized?
Оба конструкта устанавливают отношения happens-before, но работают на различных уровнях и с разными характеристиками производительности. Выход из блока synchronized сбрасывает все измененные переменные из рабочей памяти потока в основную память, действуя как глобальный барьер памяти. В отличие от этого, запись volatile специально предотвращает переупорядочивание этой конкретной переменной с окружающими инструкциями и гарантирует, что запись становится видимой немедленно. До Java 5 volatile не имел этих гарантий, что делало его недостаточным для безопасной публикации; современный JMM рассматривает записи volatile аналогично операциям release в C++ и чтения как операции acquire, обеспечивая целевую видимость без полной стоимости блокировки монитора.
Могут ли неизменяемые объекты устранить необходимость в volatile в паттерне двойной проверки блокировки?
Нет, потому что поля final гарантируют неизменяемость только после завершения конструктора, а не в момент публикации самой ссылки. Без volatile переупорядочивание инструкций может привести к тому, что ссылка будет записана в основную память до завершения выполнения конструктора, позволяя другому потоку увидеть ненулевую ссылку на частично сконструированный объект. Хотя поля final гарантируют, что значения не могут измениться после конструкции, они не предотвращают видимость значений по умолчанию или неинициализированных значений, если ссылка выходит слишком рано. Безопасная публикация требует либо volatile, либо synchronized, чтобы гарантировать отношение happens-before между конструкцией и видимостью, независимо от внутренней неизменяемости объекта.