Гарантия возникает из правила happens-before Java Memory Model (JMM), связанного с инициализацией класса. Когда JVM впервые обращается к статическому полю или методу класса, она должна сначала завершить фазу инициализации этого класса. Эта фаза выполняет блоки статических инициализаторов и присвоение полей под внутренней блокировкой, уникальной для данного объектного класса. В результате любое действие записи, выполненное в статическом инициализаторе, например создание единственного экземпляра, образует связь happens-before с любым последующим чтением этого поля потоками, обращающимися к классу, обеспечивая полную видимость построенного состояния без необходимости использования ключевых слов synchronized или объявления volatile.
public class ConnectionPool { private ConnectionPool() { // дорогая TCP рукопожатие и создание потоков } private static class Holder { static final ConnectionPool INSTANCE = new ConnectionPool(); } public static ConnectionPool getInstance() { return Holder.INSTANCE; // Запускает инициализацию класса Holder } }
Проблема: Финансовому торговому приложению требовался ConnectionPool-синглтон, который был дорог в создании из-за начальных TCP рукопожатий и создания потоков, однако он мог не понадобиться в некоторых легковесных диагностических режимах. Ранняя инициализация потратила бы сотни миллисекунд при старте, даже когда пул оставался неиспользованным, в то время как Double-checked locking требовал тщательной обработки семантики volatile и барьеров порядка для предотвращения перестановки инструкций.
Решение 1: Ранняя инициализация: Этот подход инициализирует статическое поле при загрузке класса, что просто для реализации и гарантировано потокобезопасно за счет JVM. Однако он не выполняет требование избежать затрат на создание, когда пул никогда не используется, тратя значительные ресурсы в диагностических режимах и ненужно увеличивая время старта развертывания.
Решение 2: Синхронизированный доступ: Обертывание метода получения в synchronized обеспечивает безопасность между всеми потоками и просто в кодировании. К сожалению, это заставляет каждого вызывающего получать монитор, даже после создания экземпляра, создавая серьезное узкое место при высокой частоте торговли, где микросекунды имеют значение, и потоки конкурируют за одну и ту же блокировку.
Решение 3: Инициализация по требованию: Это определяет закрытый статический класс ConnectionPoolHolder, содержащий статический финальный ConnectionPool экземпляр, где getInstance просто возвращает ConnectionPoolHolder.INSTANCE. Это использует ленивую загрузку классов от JVM: класс-держатель инициализируется только когда вызывается getInstance, и блокировка инициализации класса гарантирует безопасную публикацию без явной синхронизации или накладных расходов volatile.
Выбранное решение: Команда выбрала идиому держателя за ее нулевые накладные расходы после инициализации и гарантированную безопасность в рамках Java Memory Model, поскольку она прекрасно уравновешивала ленивую инициализацию с эффективностью времени выполнения.
Результат: Приложение достигло доступа с задержкой менее микросекунды к ссылке на пул в условиях конкурентной нагрузки, откладывая тяжелую инициализацию до первого использования, устраняя накладные расходы при старте в диагностических режимах и оставаясь свободным от гонок во время торговых сессий высокой нагрузки.
Что произойдет с последующими потоками, если конструктор синглтона выбрасывает исключение во время инициализации класса держателя?
Если статический инициализатор выбрасывает исключение, JVM помечает класс как неудавшийся в инициализации и выбрасывает ExceptionInInitializerError (оборачивая причину). Критически важно, что любой последующий поток, пытающийся получить доступ к ConnectionPoolHolder, получит NoClassDefFoundError, даже если коренная причина была временной (например, временная недоступность сети). В отличие от Double-Checked Locking, который потенциально может повторить создание в блоках catch, идиома держателя требует внешней логики восстановления, поскольку класс остается в состоянии неудавшейся инициализации на протяжении всей жизни определенного ClassLoader.
Можно ли адаптировать паттерн инициализации по требованию для синглтонов с областью экземпляров в многоарендном контейнере?
Нет. Паттерн строго основывается на статических полях и блокировках инициализации на уровне класса. Для синглтонов с областью экземпляров или по арендаторам держатель должен быть внутренним классом контекста арендатора, но блокировки инициализации класса действуют на каждый ClassLoader, а не на каждый экземпляр контейнера. Это приводит либо к совместному использованию экземпляров между арендаторами (что представляет собой риск безопасности и изоляции), либо к необходимости явной синхронизации внутри экземпляра арендатора, что подрывает цель паттерна - доступ без блокировок. Кандидаты часто путают ленивую загрузку на уровне класса с ленивой загрузкой на уровне объекта.
Как этот идиом ведет себя, когда в средах серверов приложений задействованы несколько иерархий ClassLoader?
Каждый ClassLoader независимо инициализирует свою собственную копию класса держателя. В Tomcat или WildFly, если класс синглтона присутствует как в веб-приложении, так и в общем родительском загрузчике, или если веб-приложение развертывается заново (создавая новый ClassLoader), будут существовать разные экземпляры. Это нарушает контракт синглтона по всему процессу JVM. Паттерн гарантирует безопасность потоков в рамках одного пространства загрузки класса, но не обеспечивает глобальную семантику синглтона JVM, что является критическим различием в модульных средах, где обеспечивается изоляция загрузчика классов.