Нет это не будет создано много раз. Это статично, таким образом, это будет только создано однажды, право, когда класс будет затронут впервые Classloader.

Только исключение - если у Вас, оказывается, есть несколько Classloaders.

(от GeekAndPoke):

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

Одна вещь, на которую я смотрел бы, firstTime() метод - почему не может работа в doPreparations() быть обработанным в самом одиночном элементе?

Походит на противный набор зависимостей.

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

, Который сказал, JVM не гарантирует, что Ваш класс будет загружен только однажды. Однако, даже если это будет загружено несколько раз, Ваше веб-приложение будет все еще видеть только соответствующий одиночный элемент, поскольку это будет загружено или в веб-приложении classloader или в его родителе. Если у Вас будет несколько развернутых веб-приложений, то в первый раз () будет назван однажды для каждого приложения.

самые очевидные вещи проверить состоят в том, который в первый раз () должен синхронизироваться и что новый флаг установлен прежде, чем выйти из того метода.

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

, Конечно, если это загружается из отдельных загрузчиков класса, Вы получаете несколько "одиночных элементов", но это - ограничение каждой одноэлементной идиомы в Java.

РЕДАКТИРОВАНИЕ : новые () и doPreparations () биты действительно смотрят подозреваемый все же. Разве они не могут быть перемещены в конструктора одноэлементного экземпляра?

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

public class Single {

private static class SingleHolder {
   private static final Single INSTANCE = new Single();
}

private Single() {
...load properties...
}

public static Single getInstance() {
    return SingleHolder.INSTANCE;
}

}

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

Нет - статическая инициализация эти instance будет только когда-либо делаться однажды. Две вещи рассмотреть:

• Это не ориентировано на многопотоковое исполнение (экземпляр не "публикуется" к оперативной памяти)
• Ваш firstTime, метод, вероятно, называют многократно, если правильно не синхронизируется

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

кроме того, шаблон "одиночка" был critized много. Посмотрите, например Singleton, я люблю Вас, но Вы приносите мне вниз

Нет, Это не создаст несколько копий 'Единственных'. (Проблему Classloader посетят позже)

реализация, которую Вы обрисовали в общих чертах, описан как 'Нетерпеливая Инициализация' в книге Briant Goetz -' Параллелизм Java на практике '.

public class Single
{
    private static Single theInstance = new Single();

    private Single() 
    { 
        // load properties
    }

    public static Single getInstance() 
    {
        return theInstance;
    }
}

Однако код не Вы требуемый. Ваш код пытается выполнить ленивую инициализацию после того, как экземпляр будет создан. Это требует, чтобы вся клиентская библиотека работала 'в первый раз ()/doPreparation ()' перед использованием его. Вы собираетесь полагаться на клиент, чтобы сделать правильную вещь, которые делают код очень хрупким.

можно изменить код как следующее, таким образом, не будет никакого дублирующего кода.

public class Single
{
    private static Single theInstance = new Single();

    private Single() 
    { 
        // load properties
    }

    public static Single getInstance() 
    {   
        // check for initialization of theInstance
        if ( theInstance.firstTime() )
           theInstance.doPreparation();

        return theInstance;
    }
}

, К сожалению, это - плохая реализация ленивой инициализации, и это не будет работать в параллельной среде (как контейнер J2EE).

существует много статей, написанных об инициализации Singleton, конкретно на модели памяти. JSR 133 обратился ко многим слабость в модели памяти Java в Java 1.5 и 1.6.

С Java 1.5 & 1.6, у Вас есть несколько вариантов, и они упоминаются в книге' Эффективный Java' Joshua Bloch.

1. Нетерпеливый Initialziation, как вышеупомянутое [Объект EJ 3]
2. Ленивая Идиома Класса Держателя Initalization [Объект EJ 71]
3. Перечислимый Тип [Объект EJ 3]
4. Проверенная дважды Блокировка с 'энергозависимым' статическим полем [Объект EJ 71]

Решение 3 и 4 будет только работать в Java 1.5 и выше. Таким образом, лучшим решением был бы № 2.

, Вот psuedo-реализация.

public class Single
{
    private static class SingleHolder
    {
        public static Single theInstance = new Single();
    }

    private Single() 
    { 
        // load properties
        doPreparation();
    }

    public static Single getInstance() 
    {
        return SingleHolder.theInstance;
    }
}

Уведомление, которое 'doPreparation ()' является в конструкторе, таким образом, Вы - гарантия для получения правильно инициализированного экземпляра. Кроме того, Вы - piggying назад на ленивой загрузке класса JVM и не нуждаетесь ни в какой синхронизации 'getInstance ()'.

Одна вещь Вы заметили, что статическое поле theInstance не 'окончательное'. пример на Параллелизме Java не имеет 'финала', но EJ делает. Возможно, James может добавить больше цвета к своему ответу на 'classloader' и требовании 'финала' для гарантии правильности,

Однако существует побочный эффект это с использованием 'статического финала'. Компилятор Java очень агрессивен, когда он видит 'статический финал' и пытается встроить его как можно больше. Это упоминается на [1 110] сообщение в блоге Jeremy Manson .

public class A
{
    final static String word = "Hello World";
}

public class B
{
    public static void main(String[] args) {
        System.out.println(A.word);
    }
}

public class A
{
    final static String word = "Goodbye World";
}

Hello World

Что касается проблемы classloader, ответ да, у Вас может быть больше чем один экземпляр Singleton в нескольких classloaders. Можно найти больше информации о [1 111] Википедия . Существует также определенная статья о [1 112] Websphere.

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

В коде ниже вы можете увидеть, как он создается только один раз (при первом вызове конструктора)

дата пакета;

import java.util.Date;

открытый класс USDateFactory реализует DateFactory { частный статический USDateFactory usdatefactory = null;

private USDateFactory () { }

public static USDateFactory getUsdatefactory() {
    if(usdatefactory==null) {
        usdatefactory = new USDateFactory();
    }
    return usdatefactory;
}

public String getTextDate (Date date) {
    return null;
}

public NumericalDate getNumericalDate (Date date) {
    return null;
}

}