Каков эффективный способ реализации одноэлементного шаблона в Java?

Убедитесь, что вам это действительно нужно. Выполните поиск в Google по запросу "одноэлементный антипаттерн", чтобы увидеть некоторые аргументы против него.

Я полагаю, что в этом нет ничего плохого по сути, но это всего лишь механизм для раскрытия некоторых глобальных ресурсов / данных, поэтому убедитесь, что это лучший способ. В частности, я нашел внедрение зависимости (DI) более полезным, особенно если вы также используете модульные тесты, потому что DI позволяет вам использовать фиктивные ресурсы для целей тестирования.

В Википедии есть несколько Примеры синглтонов, также на Java. Реализация Java 5 выглядит довольно завершенной и ориентированной на многопоточность (применена блокировка с двойной проверкой).

Обдумайте, зачем вам нужен синглтон, прежде чем писать его. Об их использовании ведутся квазирелигиозные дебаты, о которых вы можете довольно легко споткнуться, если загуглите синглтоны на Java.

Лично я стараюсь избегать синглтонов как можно чаще по многим причинам, большинство из которых, опять же, можно найти в поисковой системе синглтонов. Я чувствую, что довольно часто синглтонами злоупотребляют, потому что их легко понять всем. Они используются как механизм для получения «глобальных» данных в объектно-ориентированном дизайне, и они используются, потому что легко обойти управление жизненным циклом объекта (или действительно думать о том, как вы можете сделать A изнутри B). Посмотрите на такие вещи, как инверсия контроля (IoC) или внедрение зависимости (DI), чтобы найти золотую середину.

Если он вам действительно нужен, то в Википедии есть хороший пример правильной реализации синглтона.

Забудьте о ленивая инициализация; это слишком проблематично. Это самое простое решение:

public class A {    

    private static final A INSTANCE = new A();

    private A() {}

    public static A getInstance() {
        return INSTANCE;
    }
}

Если вам не нужна ленивая загрузка, просто попробуйте:

public class Singleton {
    private final static Singleton INSTANCE = new Singleton();

    private Singleton() {}

    public static Singleton getInstance() { return Singleton.INSTANCE; }

    protected Object clone() {
        throw new CloneNotSupportedException();
    }
}

Если вам нужна отложенная загрузка и вы хотите, чтобы ваш синглтон был потокобезопасным, попробуйте шаблон двойной проверки:

public class Singleton {
    private static Singleton instance = null;

    private Singleton() {}

    public static Singleton getInstance() {
        if (null == instance) {
            synchronized(Singleton.class) {
                if (null == instance) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }

    protected Object clone() {
        throw new CloneNotSupportedException();
    }
}

Поскольку шаблон двойной проверки не гарантированно работает (из-за некоторых проблем с компиляторами, я больше ничего об этом не знаю), вы также можете попытаться синхронизировать весь метод getInstance или создать реестр для всех ваших синглтонов.

Потокобезопасность в Java 5+:

class Foo {
    private static volatile Bar bar = null;
    public static Bar getBar() {
        if (bar == null) {
            synchronized(Foo.class) {
                if (bar == null)
                    bar = new Bar();
            }
        }
        return bar;
    }
}

Обратите внимание на модификатор volatile. :) Это важно, потому что без него JMM (модель памяти Java) не гарантирует, что другие потоки увидят изменения его значения. Об этом позаботится синхронизация не - она ​​только сериализует доступ к этому блоку кода.

Ответ @Bno подробно описывает подход, рекомендованный Биллом Пью (FindBugs), и, возможно, лучше. Прочтите и проголосуйте за его ответ тоже.

Используйте перечисление:

public enum Foo {
    INSTANCE;
}

Джошуа Блох объяснил этот подход в своем выступлении Эффективная перезагрузка Java на Google I / O 2008: ссылка на видео. Также см. Слайды 30-32 его презентации (Effective_java_reloaded.pdf):

The Right Way to Implement a Serializable Singleton

public enum Elvis {
    INSTANCE;
    private final String[] favoriteSongs =
        { "Hound Dog", "Heartbreak Hotel" };
    public void printFavorites() {
        System.out.println(Arrays.toString(favoriteSongs));
    }
}

Редактировать:онлайн-часть "Эффективной Java" говорит:

"This approach is functionally equivalent to the public field approach, except that it is more concise, provides the serialization machinery for free, and provides an ironclad guarantee against multiple instantiation, even in the face of sophisticated serialization or reflection attacks. While this approach has yet to be widely adopted, a single-element enum type is the best way to implement a singleton."

Меня озадачивают некоторые ответы, в которых предлагается внедрение зависимости (DI) в качестве альтернативы использованию синглтонов; это не связанные между собой концепции. Вы можете использовать DI для внедрения одноэлементных или не одноэлементных экземпляров (например, для каждого потока). По крайней мере, это правда, если вы используете Spring 2.x, я не могу говорить о других фреймворках DI.

Итак, мой ответ на OP будет (во всем, кроме самого тривиального примера кода):

1. Используйте структуру DI, например Spring Framework, затем
2. Сделайте это частью вашей конфигурации DI, независимо от того, являются ли ваши зависимости одиночными, ограниченными запросами, сеансами и т. д.

Этот подход дает вам красивую развязанную (и, следовательно, гибкую и тестируемую) архитектуру, где вопрос об использовании синглтона является легко обратимой деталью реализации (при условии, что любые синглтоны, которые вы используете, являются потокобезопасными).

Решение, опубликованное Стю Томпсоном действителен в Java 5.0 и новее. Но я бы предпочел не использовать его, потому что считаю, что он подвержен ошибкам.

Легко забыть об изменчивом заявлении и трудно понять, зачем оно необходимо. Без volatile этот код больше не был бы потокобезопасным из-за дважды проверенного антипаттерна блокировки. См. Подробнее об этом в параграфе 16.2.4 Параллелизм Java на практике. Вкратце: этот шаблон (до Java 5.0 или без оператора volatile) мог возвращать ссылку на объект Bar, который (все еще) находится в неправильном состоянии.

Этот шаблон был изобретен для оптимизации производительности. Но это уже не проблема. Следующий код отложенной инициализации работает быстро и, что более важно, легче читается.

class Bar {
    private static class BarHolder {
        public static Bar bar = new Bar();
    }

    public static Bar getBar() {
        return BarHolder.bar;
    }
}

В зависимости от использования есть несколько «правильных» ответов.

Начиная с Java 5, лучший способ сделать это - использовать перечисление:

public enum Foo {
   INSTANCE;
}

До Java 5 наиболее простой случай:

public final class Foo {

    private static final Foo INSTANCE = new Foo();

    private Foo() {
        if (INSTANCE != null) {
            throw new IllegalStateException("Already instantiated");
        }
    }

    public static Foo getInstance() {
        return INSTANCE;
    }

    public Object clone() throws CloneNotSupportedException{
        throw new CloneNotSupportedException("Cannot clone instance of this class");
    }
}

Пройдемся по коду. Во-первых, вы хотите, чтобы урок был финальным. В этом случае я использовал ключевое слово final, чтобы пользователи знали, что оно окончательное. Затем вам нужно сделать конструктор закрытым, чтобы пользователи не могли создавать свои собственные Foo. Создание исключения из конструктора не позволяет пользователям использовать отражение для создания второго Foo. Затем вы создаете поле private static final Foo для хранения единственного экземпляра и метод public static Foo getInstance() для его возврата. Спецификация Java гарантирует, что конструктор вызывается только при первом использовании класса.

Когда у вас есть очень большой объект или код тяжелой конструкции, и также имеет другие доступные статические методы или поля, которые могут использоваться до того, как потребуется экземпляр, тогда и только тогда вам нужно использовать ленивую инициализацию.

Вы можете использовать private static class для загрузки экземпляра. Тогда код будет выглядеть так:

public final class Foo {

    private static class FooLoader {
        private static final Foo INSTANCE = new Foo();
    }

    private Foo() {
        if (FooLoader.INSTANCE != null) {
            throw new IllegalStateException("Already instantiated");
        }
    }

    public static Foo getInstance() {
        return FooLoader.INSTANCE;
    }
}

Поскольку строка private static final Foo INSTANCE = new Foo(); выполняется только при фактическом использовании класса FooLoader, она заботится о ленивом создании экземпляра и гарантирует безопасность потоков.

Если вы также хотите иметь возможность сериализовать свой объект, вам необходимо убедиться, что десериализация не создаст копию.

public final class Foo implements Serializable {

    private static final long serialVersionUID = 1L;

    private static class FooLoader {
        private static final Foo INSTANCE = new Foo();
    }

    private Foo() {
        if (FooLoader.INSTANCE != null) {
            throw new IllegalStateException("Already instantiated");
        }
    }

    public static Foo getInstance() {
        return FooLoader.INSTANCE;
    }

    @SuppressWarnings("unused")
    private Foo readResolve() {
        return FooLoader.INSTANCE;
    }
}

Метод readResolve() гарантирует, что будет возвращен единственный экземпляр, даже если объект был сериализован при предыдущем запуске вашей программы.

Иногда простого "static Foo foo = new Foo();" недостаточно. Просто подумайте о том, какие основные данные вы хотите вставить.

С другой стороны, вам придется синхронизировать любой метод, который создает экземпляр одноэлементной переменной как таковой. Синхронизация сама по себе неплохая, но она может привести к проблемам с производительностью или блокировке (в очень редких ситуациях, используя этот пример. Решение -

public class Singleton {

    private static Singleton instance = null;

    static {
          instance = new Singleton();
          // do some of your instantiation stuff here
    }

    private Singleton() {
          if (instance!=null) {
                  throw new ErrorYouWant("Singleton double-instantiation, should never happen!");
          }
    }

    public static getSingleton() {
          return instance;
    }

}

Что теперь происходит? Класс загружается через загрузчик классов. Сразу после интерпретации класса из байтового массива виртуальная машина выполняет блок статический {}. вот и весь секрет: статический блок вызывается только один раз, когда данный класс (имя) данного пакета загружается этим одним загрузчиком классов.

Я использую Spring Framework для управления своими одиночками.

Он не обеспечивает «одноэлементность» класса (чего вы в любом случае не сможете сделать, если задействовано несколько загрузчиков классов), но он предоставляет действительно простой способ создания и настройки различных фабрик для создания различных типов объекты.

Вам понадобится идиома двойная проверка, если вам нужно лениво загрузить переменную экземпляра класса. Если вам нужно лениво загрузить статическую переменную или синглтон, вам понадобится идиома инициализация по требованию держателя.

Кроме того, если синглтон должен быть сериализуемым, все остальные поля должны быть временными, а метод readResolve () должен быть реализован для поддержания неизменности синглтон-объекта. В противном случае каждый раз, когда объект десериализуется, будет создаваться новый экземпляр объекта. Что делает readResolve (), так это заменяет новый объект, прочитанный readObject (), что заставляет этот новый объект быть собранным в мусор, поскольку на него нет переменной.

public static final INSTANCE == ....
private Object readResolve() {
  return INSTANCE; // Original singleton instance.
} 

Я бы сказал, что это одноэлементное перечисление.

Синглтон с использованием перечисления в Java обычно является способом объявления одноэлементного объекта перечисления. Синглтон перечисления может содержать переменные экземпляра и методы экземпляра. Для простоты также обратите внимание, что если вы используете какой-либо метод экземпляра, вам необходимо обеспечить потокобезопасность этого метода, если он вообще влияет на состояние объекта.

Использование перечисления очень легко реализовать и не имеет недостатков в отношении сериализуемых объектов, которые необходимо обходить другими способами.

/**
* Singleton pattern example using a Java Enum
*/
public enum Singleton {
    INSTANCE;
    public void execute (String arg) {
        // Perform operation here
    }
}

Вы можете получить к нему доступ через Singleton.INSTANCE, и это намного проще, чем вызывать метод getInstance() в Singleton.

1.12 Serialization of Enum Constants

Enum constants are serialized differently than ordinary serializable or externalizable objects. The serialized form of an enum constant consists solely of its name; field values of the constant are not present in the form. To serialize an enum constant, ObjectOutputStream writes the value returned by the enum constant's name method. To deserialize an enum constant, ObjectInputStream reads the constant name from the stream; the deserialized constant is then obtained by calling the java.lang.Enum.valueOf method, passing the constant's enum type along with the received constant name as arguments. Like other serializable or externalizable objects, enum constants can function as the targets of back references appearing subsequently in the serialization stream.

The process by which enum constants are serialized cannot be customized: any class-specific writeObject, readObject, readObjectNoData, writeReplace, and readResolve methods defined by enum types are ignored during serialization and deserialization. Similarly, any serialPersistentFields or serialVersionUID field declarations are also ignored--all enum types have a fixed serialVersionUID of 0L. Documenting serializable fields and data for enum types is unnecessary, since there is no variation in the type of data sent.

Quoted from Oracle documentation

Другая проблема обычных синглтонов заключается в том, что после реализации интерфейса Serializable они больше не остаются синглетонами, потому что метод readObject() всегда возвращает новый экземпляр, как конструктор в Java. Этого можно избежать, используя readResolve() и отказавшись от вновь созданного экземпляра, заменив его синглтоном, как показано ниже:

 // readResolve to prevent another instance of Singleton
 private Object readResolve(){
     return INSTANCE;
 }

Это может стать еще более сложным, если ваш одноэлементный класс поддерживает состояние, так как вам нужно сделать их временными, но в одноэлементном перечислении сериализация гарантируется JVM.

Хорошо для чтения

1. Шаблон Singleton
2. Перечисления, синглтоны и десериализация
3. Двойная проверка блокировки и шаблон Singleton

Ниже приведены три разных подхода.

1. Enum

    /**
    * Singleton pattern example using Java Enum
    */
    public enum EasySingleton {
        INSTANCE;
    }
   

2. Двойная проверка блокировки / отложенная загрузка

    /**
    * Singleton pattern example with Double checked Locking
    */
    public class DoubleCheckedLockingSingleton {
         private static volatile DoubleCheckedLockingSingleton INSTANCE;
   
         private DoubleCheckedLockingSingleton() {}
   
         public static DoubleCheckedLockingSingleton getInstance() {
             if (INSTANCE == null) {
                synchronized(DoubleCheckedLockingSingleton.class) {
                    // Double checking Singleton instance
                    if (INSTANCE == null) {
                        INSTANCE = new DoubleCheckedLockingSingleton();
                    }
                }
             }
             return INSTANCE;
         }
    }
   

3. Статический заводской метод

    /**
    * Singleton pattern example with static factory method
    */
   
    public class Singleton {
        // Initialized during class loading
        private static final Singleton INSTANCE = new Singleton();
   
        // To prevent creating another instance of 'Singleton'
        private Singleton() {}
   
        public static Singleton getSingleton() {
            return INSTANCE;
        }
    }
   

Заявление об ограничении ответственности: Я только что обобщил все замечательные ответы и написал их своими словами.

При реализации синглтона у нас есть два варианта:

1. Ленивая загрузка
2. Ранняя загрузка

Ленивая загрузка увеличивает накладные расходы (много, если честно), поэтому используйте ее только тогда, когда у вас есть очень большой объект или тяжелый код конструкции и также имеет другие доступные статические методы или поля, которые могут использоваться до того, как потребуется экземпляр, тогда и только тогда вам нужно использовать ленивую инициализацию. В противном случае хорошим выбором будет ранняя загрузка.

Самый простой способ реализовать синглтон:

public class Foo {

    // It will be our sole hero
    private static final Foo INSTANCE = new Foo();

    private Foo() {
        if (INSTANCE != null) {
            // SHOUT
            throw new IllegalStateException("Already instantiated");
        }
    }

    public static Foo getInstance() {
        return INSTANCE;
    }
}

Все хорошо, кроме раннего загруженного синглтона. Давайте попробуем синглтон с ленивой загрузкой

class Foo {

    // Our now_null_but_going_to_be sole hero
    private static Foo INSTANCE = null;

    private Foo() {
        if (INSTANCE != null) {
            // SHOUT
            throw new IllegalStateException("Already instantiated");
        }
    }

    public static Foo getInstance() {
        // Creating only  when required.
        if (INSTANCE == null) {
            INSTANCE = new Foo();
        }
        return INSTANCE;
    }
}

Пока все хорошо, но наш герой не выживет, сражаясь в одиночку с несколькими злыми потоками, которые хотят много экземпляров нашего героя. Так что давайте защитим его от злой многопоточности:

class Foo {

    private static Foo INSTANCE = null;

    // TODO Add private shouting constructor

    public static Foo getInstance() {
        // No more tension of threads
        synchronized (Foo.class) {
            if (INSTANCE == null) {
                INSTANCE = new Foo();
            }
        }
        return INSTANCE;
    }
}

Но этого мало, чтобы защитить своего героя !!! Это лучшее, что мы можем / должны сделать, чтобы помочь нашему герою:

class Foo {

    // Pay attention to volatile
    private static volatile Foo INSTANCE = null;

    // TODO Add private shouting constructor

    public static Foo getInstance() {
        if (INSTANCE == null) { // Check 1
            synchronized (Foo.class) {
                if (INSTANCE == null) { // Check 2
                    INSTANCE = new Foo();
                }
            }
        }
        return INSTANCE;
    }
}

Это называется «идиомой двойной проверки блокировки». Легко забыть об изменчивом заявлении и трудно понять, зачем оно необходимо. Подробнее: Декларация «Двойная проверка блокировки нарушена»

Теперь мы уверены в злых потоках, но как насчет жестокой сериализации? Мы должны убедиться, что даже во время десериализации не создается новый объект:

class Foo implements Serializable {

    private static final long serialVersionUID = 1L;

    private static volatile Foo INSTANCE = null;

    // The rest of the things are same as above

    // No more fear of serialization
    @SuppressWarnings("unused")
    private Object readResolve() {
        return INSTANCE;
    }
}

Метод readResolve() гарантирует, что будет возвращен единственный экземпляр, даже если объект был сериализован при предыдущем запуске нашей программы.

Наконец, мы добавили достаточную защиту от потоков и сериализации, но наш код выглядит громоздким и некрасивым. Давайте преобразим нашего героя:

public final class Foo implements Serializable {

    private static final long serialVersionUID = 1L;

    // Wrapped in a inner static class so that loaded only when required
    private static class FooLoader {

        // And no more fear of threads
        private static final Foo INSTANCE = new Foo();
    }

    // TODO add private shouting construcor

    public static Foo getInstance() {
        return FooLoader.INSTANCE;
    }

    // Damn you serialization
    @SuppressWarnings("unused")
    private Foo readResolve() {
        return FooLoader.INSTANCE;
    }
}

Да, это наш самый герой :)

Поскольку строка private static final Foo INSTANCE = new Foo(); выполняется только при фактическом использовании класса FooLoader, она заботится о ленивом создании экземпляра и гарантирует безопасность потоков.

И мы зашли так далеко. Вот лучший способ добиться всего, что мы сделали, - наилучший из возможных способов:

public enum Foo {
    INSTANCE;
}

Что внутри будет рассматриваться как

public class Foo {

    // It will be our sole hero
    private static final Foo INSTANCE = new Foo();
}

Вот и все! Больше не нужно бояться сериализации, потоков и некрасивого кода. Также Синглтон ENUMS лениво инициализируется.

This approach is functionally equivalent to the public field approach, except that it is more concise, provides the serialization machinery for free, and provides an ironclad guarantee against multiple instantiation, even in the face of sophisticated serialization or reflection attacks. While this approach has yet to be widely adopted, a single-element enum type is the best way to implement a singleton.

-Джошуа Блох в «Эффективной Java»

Теперь вы, возможно, поняли, почему ENUMS считаются лучшим способом реализации синглтона, и спасибо за терпение :)

Обновил на моем блог.

Для JSE 5.0 и выше используйте подход Enum. В противном случае используйте подход статического одноэлементного держателя ((подход с отложенной загрузкой, описанный Биллом Пью). Последнее решение также является поточно-ориентированным и не требует специальных языковых конструкций (т. Е. Изменчивых или синхронизированных).

Простейший одноэлементный класс:

public class Singleton {
  private static Singleton singleInstance = new Singleton();
  private Singleton() {}
  public static Singleton getSingleInstance() {
    return singleInstance;
  }
}

public class Singleton {

    private static final Singleton INSTANCE = new Singleton();

    private Singleton() {
        if (INSTANCE != null)
            throw new IllegalStateException(“Already instantiated...”);
        }


    public synchronized static Singleton getInstance() {
        return INSTANCE;
    }

}

Поскольку мы добавили ключевое слово Synchronized перед getInstance, мы избежали состояния гонки в случае, когда два потока одновременно вызывают getInstance.

Я по-прежнему думаю, что после Java 1.5 enum является лучшей доступной реализацией singleton, поскольку она также гарантирует, что даже в многопоточных средах создается только один экземпляр.

public enum Singleton {
    INSTANCE;
}

Готово!

Версия 1:

public class MySingleton {
    private static MySingleton instance = null;
    private MySingleton() {}
    public static synchronized MySingleton getInstance() {
        if (instance == null) {
            instance = new MySingleton();
        }
        return instance;
    }
}

Ленивая загрузка, потокобезопасность с блокировкой, низкая производительность из-за synchronized.

Версия 2:

public class MySingleton {
    private MySingleton() {}
    private static class MySingletonHolder {
        public final static MySingleton instance = new MySingleton();
    }
    public static MySingleton getInstance() {
        return MySingletonHolder.instance;
    }
}

Ленивая загрузка, потокобезопасность с неблокировкой, высокая производительность.

Взгляните на этот пост.

Примеры шаблонов проектирования GoF в основных библиотеках Java

Из раздела "Синглтон" лучшего ответа,

Singleton (recognizeable by creational methods returning the same instance (usually of itself) everytime)

• java.lang.Runtime#getRuntime()
• java.awt.Desktop#getDesktop()
• java.lang.System#getSecurityManager()

Вы также можете изучить пример синглтона из самих классов Java.

Различные способы сделать одноэлементный объект:

1. Согласно Джошуа Блох - Enum будет лучшим.

2. Вы также можете использовать блокировку с двойной проверкой.

3. Можно использовать даже внутренний статический класс.

Одноэлементное перечисление

Самый простой способ реализовать синглтон, который является потокобезопасным, - использовать Enum:

public enum SingletonEnum {
  INSTANCE;
  public void doSomething(){
    System.out.println("This is a singleton");
  }
}

Этот код работает с момента появления Enum в Java 1.5.

Двойная проверка блокировки

Если вы хотите создать «классический» синглтон, работающий в многопоточной среде (начиная с Java 1.5), вам следует использовать этот.

public class Singleton {

  private static volatile Singleton instance = null;

  private Singleton() {
  }

  public static Singleton getInstance() {
    if (instance == null) {
      synchronized (Singleton.class){
        if (instance == null) {
          instance = new Singleton();
        }
      }
    }
    return instance;
  }
}

Это не было поточно-ориентированным до версии 1.5, потому что реализация ключевого слова volatile была другой.

Ранняя загрузка синглтона (работает даже до Java 1.5)

Эта реализация создает экземпляр синглтона при загрузке класса и обеспечивает безопасность потоков.

public class Singleton {

  private static final Singleton instance = new Singleton();

  private Singleton() {
  }

  public static Singleton getInstance() {
    return instance;
  }

  public void doSomething(){
    System.out.println("This is a singleton");
  }

}

Вот как реализовать простой одиночка:

public class Singleton {
    // It must be static and final to prevent later modification
    private static final Singleton INSTANCE = new Singleton();
    /** The constructor must be private to prevent external instantiation */
    private Singleton(){}
    /** The public static method allowing to get the instance */
    public static Singleton getInstance() {
        return INSTANCE;
    }
}

Вот как правильно лениво создать свой синглтон:

public class Singleton {
    // The constructor must be private to prevent external instantiation
    private Singleton(){}
    /** The public static method allowing to get the instance */
    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
    /**
     * The static inner class responsible for creating your instance only on demand,
     * because the static fields of a class are only initialized when the class
     * is explicitly called and a class initialization is synchronized such that only
     * one thread can perform it, this rule is also applicable to inner static class
     * So here INSTANCE will be created only when SingletonHolder.INSTANCE
     * will be called
     */
    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }
}

Другой аргумент, часто используемый против синглтонов, - их проблемы с тестируемостью. Синглтоны нелегко смоделировать в целях тестирования. Если это окажется проблемой, я хотел бы внести следующие небольшие изменения:

public class SingletonImpl {

    private static SingletonImpl instance;

    public static SingletonImpl getInstance() {
        if (instance == null) {
            instance = new SingletonImpl();
        }
        return instance;
    }

    public static void setInstance(SingletonImpl impl) {
        instance = impl;
    }

    public void a() {
        System.out.println("Default Method");
    }
}

Добавленный метод setInstance позволяет настроить реализацию макета одноэлементного класса во время тестирования:

public class SingletonMock extends SingletonImpl {

    @Override
    public void a() {
        System.out.println("Mock Method");
    }

}

Это также работает с подходами к ранней инициализации:

public class SingletonImpl {

    private static final SingletonImpl instance = new SingletonImpl();

    private static SingletonImpl alt;

    public static void setInstance(SingletonImpl inst) {
        alt = inst;
    }

    public static SingletonImpl getInstance() {
        if (alt != null) {
            return alt;
        }
        return instance;
    }

    public void a() {
        System.out.println("Default Method");
    }
}

public class SingletonMock extends SingletonImpl {

    @Override
    public void a() {
        System.out.println("Mock Method");
    }

}

У этого есть недостаток, заключающийся в том, что эта функция также доступна для обычного приложения. У других разработчиков, работающих над этим кодом, может возникнуть соблазн использовать метод «setInstance» для изменения конкретной функции и, таким образом, изменения всего поведения приложения, и поэтому этот метод должен содержать, по крайней мере, хорошее предупреждение в своей документации javadoc.

Тем не менее, для возможности тестирования макета (при необходимости) такое раскрытие кода может быть приемлемой платой.

Есть четыре способа создать синглтон в Java.

1. Нетерпеливый синглтон инициализации

    public class Test {
        private static final Test test = new Test();
   
        private Test() {
        }
   
        public static Test getTest() {
            return test;
        }
    }
   

2. Синглтон с отложенной инициализацией (потокобезопасный)

    public class Test {
         private static volatile Test test;
   
         private Test() {
         }
   
         public static Test getTest() {
            if (test == null) {
                synchronized(Test.class) {
                    if (test == null) {
                        test = new Test();
                    }
                }
            }
            return test;
        }
    }
   

3. Синглтон Билла Пью с рисунком держателя (желательно лучший)

    public class Test {
   
        private Test() {
        }
   
        private static class TestHolder {
            private static final Test test = new Test();
        }
   
        public static Test getInstance() {
            return TestHolder.test;
        }
    }
   

4. Одноэлементное перечисление

    public enum MySingleton {
        INSTANCE;
   
        private MySingleton() {
            System.out.println("Here");
        }
    }
   

Лучший синглтон-шаблон, который я когда-либо видел, использует интерфейс поставщика.

• Это универсальный и многоразовый
• Поддерживает ленивую инициализацию
• Он синхронизируется только до тех пор, пока не будет инициализирован, затем блокирующий поставщик заменяется неблокирующим поставщиком.

Смотри ниже:

public class Singleton<T> implements Supplier<T> {

    private boolean initialized;
    private Supplier<T> singletonSupplier;

    public Singleton(T singletonValue) {
        this.singletonSupplier = () -> singletonValue;
    }

    public Singleton(Supplier<T> supplier) {
        this.singletonSupplier = () -> {
            // The initial supplier is temporary; it will be replaced after initialization
            synchronized (supplier) {
                if (!initialized) {
                    T singletonValue = supplier.get();
                    // Now that the singleton value has been initialized,
                    // replace the blocking supplier with a non-blocking supplier
                    singletonSupplier = () -> singletonValue;
                    initialized = true;
                }
                return singletonSupplier.get();
            }
        };
    }

    @Override
    public T get() {
        return singletonSupplier.get();
    }
}