Инициализация Initialize-On-Demand против простого статического инициализатора в реализации Singleton

Question

Действительно ли идиома Initialize-On-Demand действительно необходима при реализации одноэлементного безопасного потока с использованием статической инициализации, или достаточно простого статического объявления экземпляра?

Простое объявление экземпляра как статического поля:

class Singleton
{
 private static Singleton instance=new Singleton();

 private Singleton () {..}
 public static Singleton getInstance()
 {
  return instance;
 }
}

против

class Singleton {
   static class SingletonHolder {
      static final Singleton INSTANCE = new Singleton();
   }

   private Singleton () {..}

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

Я спрашиваю это, потому что Брайан Гетц рекомендует первый подход в этой статье:

http://www.ibm.com/developerworks/java/library/j-dcl/index.html

пока он предлагает последнее в этой статье

http://www.ibm.com/developerworks/library/j-jtp03304/

Предоставляет ли последний подход какие-либо преимущества, которых нет у первого?

Answer 1

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

Answer 2

Хорошо, что я могу сказать Этим статьям 7-9 лет.

Теперь у нас есть> Java 1.5, где у нас есть сила перечисления enum.Согласно «Josh Block», лучший способ написать синглтон - это написать перечисление Single Element

public enum MySingleton{
    Singleton;

    // rest of the implementation.
    // ....
}

Но, по-вашему, нет проблем в использовании любой из реализаций.Лично я предпочитаю первый вариант, потому что он простой, простой для понимания.

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

Также сделайте класс финальным, потому что мы можем нарушить синглтон, расширив класс.

Answer 3

Шаблон простого объявления создает синглтон, когда загружается класс Singleton. Идиома инициализации по требованию создает синглтон, когда вызывается Singeton.getInstance (), т.е. когда загружается класс SingetonHolder.

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

Тем не менее, мой совет - стараться не делать там слишком много, чтобы вам помог самый простой шаблон.

-dg