Паттерны проектирования: Singleton

Привет! Сегодня будем подробно разбираться в разных паттернах проектирования, и начнем с шаблона Singleton, который еще называют “одиночка”. Давай вспомним: что мы знаем о шаблонах проектирования в целом? Шаблоны проектирования — это лучшие практики, следуя которым можно решить ряд известных проблем. Шаблоны проектирования как правило не привязаны к какому-либо языку программирования. Воспринимай их как свод рекомендаций, следуя которым можно избежать ошибок и не изобретать свой велосипед.

Что такое синглтон?

Синглтон — это один из самых простых шаблонов (паттернов) проектирования, который применяется к классу. Иногда говорят: “этот класс — синглтон”, подразумевая, что этот класс реализует паттерн проектирования синглтон. Иногда необходимо написать класс, у которого можно будет создать только один объект. Например, класс, отвечающий за логирование или подключение к базе данных. Шаблон проектирования синглтон описывает, как мы можем выполнить такую задачу. Синглтон — это шаблон (паттерн) проектирования, который делает две вещи:

1. Дает гарантию, что у класса будет всего один экземпляр класса.

2. Предоставляет глобальную точку доступа к экземпляру данного класса.

Отсюда — две особенности, характерные для практически каждой реализации паттерна синглтон:

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

2. Публичный статический метод, который возвращает экземпляр класса. Данный метод называют getInstance. Это глобальная точка доступа к экземпляру класса.

Варианты реализации

Шаблон проектирования синглтон применяют по-разному. Каждый вариант по-своему хорош и плох. Тут как всегда: идеала нет, но нужно к нему стремиться. Но прежде всего давай определимся, что такое хорошо и что такое плохо, и какие метрики влияют на оценку реализации шаблона проектирования. Начнем с положительного. Вот критерии, которые придают реализации сочности и привлекательности:

• Ленивая инициализация: когда класс загружается во время работы приложения именно тогда, когда он нужен.

• Простота и прозрачность кода: метрика, конечно, субъективная, но важная.

• Потокобезопасность: корректная работа в многопоточной среде.

• Высокая производительность в многопоточной среде: потоки блокируют друг друга минимально, либо вообще не блокируют при совместном доступе к ресурсу.

Теперь минусы. Перечислим критерии, которые выставляют реализацию в нелучшем свете:

• Не ленивая инициализация: когда класс загружается при старте приложения, независимо от того, нужен он или нет (парадокс, в мире IT лучше быть лентяем)

• Сложность и плохая читаемость кода. Метрика также субъективная. Будем считать, что если кровь пошла из глаз, реализация так себе.

• Отсутствие потокобезопасности. Иными словами, “потокоопасность”. Некорректная работа в многопоточной среде.

• Низкая производительность в многопоточной среде: потоки блокируют друг друга все время либо часто, при совместном доступе к ресурсу.

Код

Теперь мы готовы рассмотреть различные варианты реализации с перечислением плюсов и минусов:

Simple Solution

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

    private Singleton() {
    }

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

Самая простая реализация. Плюсы:

• Простота и прозрачность кода

• Потокобезопасность

• Высокая производительность в многопоточной среде

Минусы:

• Не ленивая инициализация.

В попытке исправить последний недостаток, мы получаем реализацию номер два:

Lazy Initialization

public class Singleton {
  private static Singleton INSTANCE;

  private Singleton() {}

  public static Singleton getInstance() {
    if (INSTANCE == null) {
      INSTANCE = new Singleton();
    }
    return INSTANCE;
  }
}

Плюсы:

• Ленивая инициализация.

Минусы:

• Не потокобезопасно

Реализация интересна. Мы можем инициализироваться лениво, но утратили потокобезопасность. Не беда: в реализации номер три мы все синхронизируем.

Synchronized Accessor

public class Singleton {
  private static Singleton INSTANCE;

  private Singleton() {
  }

  public static synchronized Singleton getInstance() {
    if (INSTANCE == null) {
      INSTANCE = new Singleton();
    }
    return INSTANCE;
  }
}

Плюсы:

• Ленивая инициализация.

• Потокобезопасность

Минусы:

• Низкая производительность в многопоточной среде

Отлично! В реализации номер три мы вернули потокобезопасность! Правда, медленную… Теперь метод getInstance синхронизирован, и входить в него можно только по одному. На самом деле нам нужно синхронизировать не весь метод, а лишь ту его часть, в которой мы инициализируем новый объект класса. Но мы не можем просто обернуть в synchronized блок часть, отвечающую за создание нового объекта: это не обеспечит потокобезопасность. Все немного сложнее. Правильный способ синхронизации представлен ниже:

Double Checked Locking

public class Singleton {
    private static Singleton INSTANCE;

  private Singleton() {
  }

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

Плюсы:

• Ленивая инициализация.

• Потокобезопасность

• Высокая производительность в многопоточной среде

Минусы:

• Не поддерживается на версиях Java ниже 1.5 (в версии 1.5 исправили работу ключевого слова volatile)

Отмечу, что для корректной работы данного варианта реализации обязательно одно из двух условий. Переменная INSTANCE должна быть либо final, либо volatile. Последняя реализация, которую мы сегодня обсудим, — Class Holder Singleton.

Class Holder Singleton

public class Singleton {

   private Singleton() {
   }

   private static class SingletonHolder {
       public static final Singleton HOLDER_INSTANCE = new Singleton();
   }

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

Плюсы:

• Ленивая инициализация.

• Потокобезопасность.

• Высокая производительность в многопоточной среде.

Минусы:

• Для корректной работы необходима гарантия, что объект класса Singleton инициализируется без ошибок. Иначе первый вызов метода getInstance закончится ошибкой ExceptionInInitializerError, а все последующие NoClassDefFoundError.

Реализация практически идеальная. И ленивая, и потокобезопасная, и быстрая. Но есть нюанс, описанный в минусе. Сравнительная таблица различных реализаций паттерна Singleton:

Плюсы и минусы паттерна Singleton

В целом синглтон делает именно то, что от него ждут:

1. Дает гарантию, что у класса будет всего один экземпляр класса.

2. Предоставляет глобальную точку доступа к экземпляру данного класса.

Однако у этого шаблона есть недостатки:

1. Синглтон нарушает SRP (Single Responsibility Principle) — класс синглтона, помимо непосредственных обязанностей, занимается еще и контролированием количества своих экземпляров.

2. Зависимость обычного класса или метода от синглтона не видна в публичном контракте класса.

3. Глобальные переменные это плохо. Синглтон превращается в итоге в одну здоровенную глобальную переменную.

4. Наличие синглтона снижает тестируемость приложения в целом и классов, которые используют синглтон, в частности.

Ну вот и все. Мы рассмотрели с тобой паттерн проектирования синглтон. Теперь в разговоре за жизнь с друзьями программистами ты сможешь сказать не только чем он хорош, но и пару слов о том, чем он плох. Удачи в освоении новых знаний.

Дополнительное чтение:

• Использование паттерна синглтон
• Правильный Singleton в Java
• Singleton "On Demand Holder idiom"
• Effective Ways to Implement and Use the Singleton Design Pattern
• Java Singleton Design Pattern Best Practices with Examples