[Из песочницы] Function Pointer — забытая реализация шаблона Singleton
Много статей написано о том, как правильно реализовывать на Java шаблон проектирования Singleton.Как правило, специалисты ломают копья вокруг проблемы, как совместить корректную работу в условиях многопоточного использования и эффективное выполнение, обеспечивающее производительность, близкую максимальной.
Лично я считаю единственным корректным способом реализации синглтона на Java так называемый Synchronized Accessor:
public class Singleton { private static Singleton instance; public static synchronized Singleton getInstance () { if (instance == null) { instance = new Singleton (); } return instance; } } Именно так задумывали реализацию подобной задачи авторы виртуальной машины Java, именно такая реализация используется в стандартной библиотеке классов языка Java. Если же для программы метод доступа к синглтону становится узким местом, то это повод для того, чтобы произвести редизайн программы, чтобы она обращалась к глобальному объекту не так часто.
Однако, пытаясь освежить в памяти возможности Java concurrency, я почитал старые статьи о вариантах синглтонов и удивился, что не нахожу описания еще одного способа, который я называю Function Pointer.Function Pointer заслуживает внимание тем, что он годится не только для шаблона Singleton, но и для многих других задач. Его можно использовать тогда, когда в программе существует несколько ветвей кода, одна из которых, начиная с какого-то момента, становится единственной. Остальные ветви остаются зомби-кодом, который уже никогда не будет выполняться. Как раз такая ветка присутствует в большинстве вариантов синглтона.
Идея заключается в том, что мы создаем интерфейс с одним методом и несколько реализаций. Каждая ветка помещается в отдельную имплементацию интерфейса. В конце метода добавляем установку в глобальной переменной (Function Pointer) той реализации, которая должна будет отработать в следующий раз.
Вот как это выглядит:
public final class Singleton { private static FunctionPointer accessor = new SynchronizedFunction (); private Singleton () { System.err.printf (»%s.%s ()%n», Singleton.class.getName (), Singleton.class.getSimpleName ()); } private static interface FunctionPointer { Singleton get (); } private static final class SynchronizedFunction implements FunctionPointer { @Override public synchronized Singleton get () { if (accessor!= this) { return accessor.get (); } Singleton instance = new Singleton (); accessor = new DummyFunction (instance); return instance; } } private static final class DummyFunction implements FunctionPointer { private final Singleton instance; private DummyFunction (Singleton instance) { this.instance = instance; }
@Override public Singleton get () { return instance; } } public static Singleton getInstance () { return accessor.get (); } } При первом вызове Singleton.getInstance () управление получит объект SynchronizedFunction. Его метод get () объявлен как synchronized, поэтому для потоков, которые его вызывают, будут справедливы отношения happens-before. Это гарантирует нам, что код Singleton instance = new Singleton (), выполнится ровно 1 раз. Другие потоки, вошедшие в SynchronizedFunction, увидят, что поле accessor уже изменено, и пройдут по условию accessor!= this.
Все потоки, которые вызовут Singleton.getInstance () после окончания SynchronizedFunction.get (), перейдут по сслыке в метод DummyFunction.get (), который уже не содержит ни условий, ни критических секций. Это просто метод-аксессор, который возвращает всегда одно и то же значение.
Нам даже не нужно объявлять поля volatile. Если какой-то поток не увидит записи в поле accessor, то он попадет в synchronized-метод, где он обязан будет увидеть все обновления, сделанные другими потоками в этом методе.
Ну, а в классе DummyFunction единственное поле объявлено final. Java нам гарантирует, что final-поля видны одинаково во всех потоках.
При компиляции данного кода Eclipse сообщает, что доступ к полям с видимостью private компилятор осуществляет каким-то нестандартным менее эффективным способом и советует из соображений производительности увеличить видимость поля accessor и конструкторов. В данном случае все эти медленные обращения производятся не более 1 раза, поэтому советами компилятора можно пренебречь.
Часто в реализациях шаблона Singleton обращают внимание на возможность обработки ошибок, возникающих в конструкторе целевого класса. Сделаем конструктор, который срабатывает только со 2-го раза:
private static final AtomicInteger cnt = new AtomicInteger (); private Singleton () { if (cnt.incrementAndGet () == 1) { throw new IllegalArgumentException («Ошибка. Попробуйте еще раз.»); } System.err.printf (»%s.%s ()%n», MySingleton.class.getName (), MySingleton.class.getSimpleName ()); } Легко убедиться, что наша реализация позволяет корректно поймать и обработать исключение, выброшенное из конструктора. В случае ошибки статическое поле accessor не будет изменено, и наш Singleton останется в исходном непроинициализированном состоянии.
Посмотрим, насколько эффективно сможет откомпилировать наш класс Hotspot JVM. Запустим Java с опциями -XX:+UnlockDiagnosticVMOptions -XX:+PrintInlining. Получаем вот такую диагностику:
@ 20 ru.habrahabr.Singleton: getInstance (9 bytes) inline (hot) @ 3 ru.habrahabr.Singleton$DummyFunction: get (5 bytes) accessor Я не очень разбираюсь в сообщениях JIT-компилятора, но по-моему, это самое быстрое, что можно получить из метода getInstance (). Вместо него подставлен метод accessor, возвращающий значение одного из полей.
Подведем итоги + Гарантирован 1 экземпляр класса Singleton+ Безопасность при многопоточном использовании+ Ленивая инициализация+ Обработка ошибок конструктора+ Эффективная реализация- Вызов виртуального метода при получении экземпляра Singleton- Громоздкий код- 3 дополнительных класса: интерфейс и 2 реализацииLinks [1] Реализация Singleton в JAVA[2] Правильный Singleton в Java[3] Singleton pattern[4] What is an efficient way to implement a singleton pattern in Java?[5] The «Double-Checked Locking is Broken» Declaration[6] Singleton Design Pattern
