Шаблон проектирования синглтона Java: Вопросы

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

2. Вот где это становится волосатым. Например, если класс инициализируется в контексте приложения Tomcat, то время жизни экземпляра одиночного экземпляра привязывается к этому контексту. Но может быть трудно предсказать, где ваши классы будут инициализированы; так что лучше не делать никаких предположений. Если вы хотите абсолютно точно убедиться, что для каждого контекста существует только один экземпляр, вы должны связать его как атрибут ServletContext. (Или пусть структура внедрения зависимостей позаботится об этом.)

3. -

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

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

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

Как указывалось другими авторами, загрузчик классов в java будет определять область применения синглтона. Синглтоны в кластерах обычно являются «не единичными экземплярами», а набором экземпляров, которые демонстрируют похожее поведение. Это могут быть компоненты в SOA.

Я не согласен с @irreputable.

Область синглтона - это его узел в дереве загрузчика классов. Он содержит загрузчик классов, и любые дочерние загрузчики классов могут видеть файл Singleton.

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

Например, если у вас есть библиотека в jar-файле в системном пути к классам сервера приложений, и эта библиотека использует синглтон, этот синглтон (вероятно) будет одинаковым для каждого «приложения», развернутого в сервер приложений. Это может быть хорошо, а может и не быть (зависит от библиотеки).

ИМХО, загрузчики классов являются одной из самых важных концепций в Java и JVM, и синглтоны играют прямо в это, поэтому я думаю, что Java-программисту важно «заботиться».

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

public enum Singleton { ONE_AND_ONLY_ONE ; ... members and other junk ... }

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

3: Наконец, он спросил, можно ли использовать одноэлементный объект с кластерами с объяснением и есть ли способ заставить Spring не реализовывать одноэлементный шаблон проектирования, когда мы вызываем Bean Factory, чтобы получить объекты?

На первую часть этого вопроса трудно ответить без технологического контекста. Если кластерная платформа включает в себя возможность выполнять вызовы удаленных объектов, как если бы они были локальными объектами (например, как это возможно с EJB, использующими RMI или IIOP под капотом), тогда да, это можно сделать. Например, резидентные одноэлементные объекты JVM могут быть прокси для одноэлементного объекта в масштабе кластера, который изначально был расположен / подключен через JNDI или что-то в этом роде. Но синглтоны для всего кластера являются потенциальным узким местом, потому что каждый вызов одного из синглтон-прокси приводит к (дорогостоящему) RPC для одного удаленного объекта.

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

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

Я не думаю, что Java-программисту должно быть до этого дело, если только он не пишет какие-то фреймворки. «По одной на виртуальную машину» - достаточно хороший ответ. Люди часто говорят так, хотя, строго говоря, они говорят «по одному на каждого классного загрузчика».

Можно ли иметь один синглтон на кластер? Что ж, это игра в концепции. Я не хотел бы, чтобы интервьюер называл это таким образом.

Синглтон обычно реализуется с помощью статического объекта экземпляра (private SingletonType SingletonType.instance), который лениво создается с помощью статического метода SingletonType SingletonType.getInstance(). В использовании синглтонов есть много подводных камней, настолько много, что многие считают синглтон анти-паттерном проектирования. Учитывая вопросы о Spring, интервьюер, вероятно, искал понимание не только синглтонов, но и их подводных камней, а также обходного пути для этих подводных камней, известного как внедрение зависимостей. Вы можете найти видео на странице Google Guice особенно полезным для понимания подводных камней синглтонов и того, как DI решает эту проблему.

Следующий код взят из здесь

Ключевой момент заключается в том, что вы должны переопределить метод clone ... Википедия , пример также полезен.

public class SingletonObject
{
  private SingletonObject()
  {
    // no code req'd
  }

  public static SingletonObject getSingletonObject()
  {
    if (ref == null)
        // it's ok, we can call this constructor
        ref = new SingletonObject();        
    return ref;
  }

  public Object clone()
    throws CloneNotSupportedException
  {
    throw new CloneNotSupportedException(); 
    // that'll teach 'em
  }

  private static SingletonObject ref;
}