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

Первым паттерном, который мы рассмотрим, разумеется, станет синглетон. Как только его по-русски не называют, кстати. Синглтон. Синглетон. Наконец, ОДИНОЧКА. Не, ну вы представляете, ОДИНОЧКА?! Покажите мне живого человека, который так говорит? Я ни одного за 30 лет использования паттернов GoF не видел.

Казалось бы, что о нём можно сказать разумного, доброго, вечного, а главное — нового? Паттерн довольно тривиальный, всего лишь способ создать объект класса, который нельзя инстанцировать более одного раза, а потом использовать этот объект везде, где нужно (часто в совсем разных местах). И довольно спорный во многих случаях. Особенно в Python, где я обычно не советую его использовать так, как в C++.

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

Но нас будет интересовать, что соответствует нашему паттерну в Python (а что только люди не делают, когда пытаются его реализовать!). Пробежимся же по основным способам реализации, прежде чем сделаем свои выводы. Интернет, надо сказать, полон рекомендаций по реализации синглетонов в Python, и значительная их часть — феерическая ересь, как будто специально придуманная, чтобы запутать пользователя класса и создать тяжело выявляемые проблемы.

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

Калька с C++

Сначала посмотрим на то, как реализовать синглетоны в Python наподобие C++. Прямая калька с C++ будет выглядеть примерно так:

import threading


class _Log:
    _lock = threading.Lock()
    _object: '_Log | None' = None
    def __init__(self, fname: str):
        pass


def get_log(fname: str) -> _Log:
    if _Log._object is None:
        with _Log._lock :
            if _Log._object is None:
                _Log._object = _Log(fname)
    return _Log._object

Если вам нужна ещё и потокобезопасность (в данном случае get_log() может параллельно вызываться из разных потоков), всё немного усложняется, и придётся написать примерно следующее:

import threading


class _Log:
    _lock = threading.Lock()
    _object: '_Log | None' = None
    def __init__(self, fname: str):
        pass



def get_log(fname: str) -> _Log:
    if _Log._object is None:
        with _Log._lock :
            if _Log._object is None:
                _Log._object = _Log(fname)
    return _Log._object

Этот пример использует стандартный приём, называемый Double-Checked Locking (DCL). По-русски аналог — «двойная проверка с блокировкой». Представьте себе, что get_log() вызывают из разных потоков параллельно. Поскольку непосредственно доступ к переменным класса (в данном случае именно класса, хотя экземпляра тоже) в CPython скрыт под GIL, проверить, создан ли объект ранее, можно всегда и совершенно без синхронизации. Впрочем, так делают и в C++, лишь бы присваивание указателю и его чтение (по отдельности, не вместе, конечно) были атомарны. И если глобальная переменная _OBJECT уже содержит созданный объект, можно не волноваться, он создан ранее. В этом случае никакая синхронизация нам не потребуется. А вот если вы попали в первый оператор if, гарантировать, что кто-то не сделал того же самого параллельно, нельзя. И поэтому дальше мы убеждаемся, что «в живых остался только один», потом снова проверяем, что объект ранее никем не инициализирован, и только потом создаём его. Если внутрь первого if  войдут одновременно два (возможно, больше, но это мало что меняет) потока, то успевший захватить блокировку первым создаст объект, а второй, захватив освобождённую первым блокировку позднее, обнаружит, что объект уже кем-то создан.

Для начала надо понять одно допущение, на котором основан DCL. Этот кодировочный паттерн предполагает, что как минимум можно параллельно осуществлять присваивание переменной _object и попытку её прочитать без ошибок синхронизации, известных как race conditions («условия гонок»). Впрочем, в традиционном CPython с GIL это так и есть.

По своей идее вышеприведённый код не то чтобы страшен. Не может быть, чтобы люди не придумали чего-то «пожёстче». Они и придумали. Я для смеха попросил ChatGPT предложить мне известные ему реализации паттерна в Python (почти все я видел и ранее в реальном коде). Некоторые я даже приведу здесь, но не для того, чтобы кто-то это повторил, а для того, чтобы отговорить кого-то данный кошмар использовать, ибо это просто, как говорили лет 20 назад, адъ и Израиль.

Магический метод new

Итак, первый шедевр — использование магического метода__new__. Рассмотрим его в несколько подходов. Сначала проиллюстрируем общую идею.

import threading


class Singleton:
    _instance = None
    _lock = threading.Lock()

    def __new__(cls, *args, **kwargs):
        if not cls._instance:
            with cls._lock:
                if not cls._instance:
                    cls._instance = super(Singleton,
cls).__new__(cls, *args, **kwargs)
        return cls._instance

s1 = Singleton()
s2 = Singleton()
print(s1 is s2)  # True

Этот класс, однако, не вполне настоящий. У него вообще нет конструктора, что для реальных синглетонов не очень вероятно. Добавим. И для «проверки на вшивость» напечатаем в нём, что конструктор отработал. Заодно убедимся, что объект инициализируется ровно один раз.

import threading


class Singleton:
    _instance = None
    _lock = threading.Lock()

    def __new__(cls, *args, **kwargs):
        if not cls._instance:
            with cls._lock:
                if not cls._instance:
                    cls._instance = super(Singleton,
cls).__new__(cls, *args, **kwargs)
        return cls._instance

    def __init__(self):
        print("INIT")

s1 = Singleton()
s2 = Singleton()
print(s1 is s2)  # True

Запустим этот код. Что мы видим?

INIT
INIT
True

Как так?! Объект один, но каждый раз при попытке доступа вызывается __init__, что является практически катастрофой. При этом поведение объяснимо: если __new__ вернул объект своего класса или же объект класса-потомка, вызывается конструктор, так в документации и написано. Но что теперь делать? В принципе, можно в объекте завести флажок, в первый ли раз вызывается __init__, и пользоваться им, ничего не делая в последующие разы. Но до чего же это неудобно! Причём сделать это в специальном базовом классе, чтобы создавать классы-синглетоны простым наследованием, не очень получается: конструктор вызывается только у самого последнего производного класса, и все конструкторы предков вызываются по цепочке MRO вручную (если конструктор не определён, там, конечно, обратятся к предкам, но это нам не помогает никак).

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

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

Предок с new и ад многопоточности

Доведём до ума (если это выражение тут вообще уместно) предыдущий пример, реализовав наш план с  методом _singleton_init(). Отладочные печати я тоже добавлю.

import threading
from abc import abstractmethod


class Singleton:
    _instance = None
    _lock = threading.RLock()

    def __new__(cls, *a, **kw):
        if not cls._instance:
            with cls._lock:
                if not cls._instance:
                    cls._instance = super(Singleton, cls).__new__(cls)
        return cls._instance

    @abstractmethod
    def _singleton_init(self, *a, **kw):
        ...

    def __init__(self, *a, **kw):
        if not hasattr(self, '_init'):
            self._init = True
            self._singleton_init(*a, **kw)


class Singleton1(Singleton):
    def _singleton_init(self, i: int):
        self.value = i
        print(f"Singleton1.__init__({i})")


class Singleton2(Singleton):
    def _singleton_init(self, i: int):
        self.value = i
        print(f"Singleton2.__init__({i})")


s11 = Singleton1(1)
s12 = Singleton1(2)
s21 = Singleton2(1)
s22 = Singleton2(2)
print(s11 is s12 and s21 is s22 and s11 is not s21)  # True

Очевидно, что код рабочий. Каждый псевдоконструктор _singleton_init() вызывается ровно однажды. Все экземпляры Singleton1 едины, Singleton2 — тоже, но между классами смешения экземпляров нет. И псевдоконструктор каждого вызывается ровно однажды, а именно при первом обращении. Всё хорошо? Ну, если забыть про этот нелепый _singleton_init() вместо __init__, конечно. Всё ведь хорошо, да? То, что пустой (_instance = None) атрибут экземпляра находится в базовом классе и один на всех, не страшно. При создании экземпляра производного класса в том классе тоже появится атрибут с таким же именем, скрывая пустой.

А вот то, что у нас объект синхронизации находится в базовом классе, уже интереснее. Потому, кстати, я заменил Lock на RLock. Зачем?

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

class Singleton1(Singleton):
    def _singleton_init(self, i: int):
        self.value = Singleton2(i).value + 1
        print(f"Singleton1.__init__({i})")

Он будет при этом повторно захватывать тот же объект синхронизации. В том же потоке. И для того, чтобы такой захват был возможен, нам нужен рекурсивный объект — RLock. При первом захвате он перейдёт в состояние «захвачен потоком таким-то один раз», потом — «захвачен потоком таким-то два раза», потом вернётся в «один раз», и только потом будет освобожден. А вот если использовать обычный Lock, то ему неважно, тот же поток захватывает его, другой ли — объект захвачен, значит, ждём. Естественно, вечно (ясно, что наш поток ничего не освободит). Это самоблокировка, наиболее глупый сценарий мёртвой блокировки (deadlock). Обычно потоков нужно хотя бы два, да и объектов синхронизации тоже. Но если использовать нерекурсивную блокировку, вполне реально, как видите, справиться даже одним потоком и одним объектом. Долго ли умеючи-то?

В общем, казалось бы, мы успешно применили DCL, что решает нашу проблему потокобезопасности. И да, действительно решает. Но есть нюанс.

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

Есть два синглетона (A и B) и два потока (1 и 2), оба наследуются от класса Singleton. А ещё есть какие-то другие данные, и с ними связан другой объект синхронизации. Дальше картина такая:

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

• Одновременно поток 2 начинает похожим образом инстанцировать синглетон B, успевая при этом первым захватить блокировку. Поток 1 при этом ждёт. Выполняется только поток 2.

• Поток 2 доходит до вызова конструктора B, и его конструктор тоже хочет получить доступ к данным, которые ранее заблокировал поток 1. Естественно, он обнаруживает, что блокировку захватить не может, начиная ждать её.

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

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

Когда мы дойдём до поведенческих паттернов (behavioral patterns), мы ещё столкнёмся с паттерном Observer (Наблюдатель, Подписчик — как только его не переводят), который всегда представляет собой большую проблему в многопоточном окружении и требует особых плясок с бубном. Здесь всё немного проще, но если неудачно организовать синхронизацию, тоже реально нарваться. Это означает, что нам недостаточно просто пронаследоваться от Singleton и забыть..

Метакласс

Говорят, если вы думаете, не использовать ли метаклассы, они вам не нужны, и это во многом так, хотя метаклассы позволяют делать много интересного. Можно редактировать иерархию классов. Можно добавлять к классам методы. Да вообще с классом можно сделать чуть ли не что угодно, даже контролировать процесс создания его экземпляров через метод __call__. Вот и реализация синглетонов через метакласс подоспела:

import threading


class SingletonMeta(type):
    _instances = {} # Словарь для хранения экземпляров
    _lock = threading.RLock()

    def __call__(cls, *args, **kwargs):
        """
        Управляет созданием экземпляров класса.
        """
        if cls not in cls._instances:
            with cls._lock:
                if cls not in cls._instances:
                    instance = super().__call__(*args,
                        **kwargs)
                    cls._instances[cls] = instance
        return cls._instances[cls]


class MySingleton(metaclass=SingletonMeta):
    def __init__(self, *args, **kwargs):
        ...

Здесь проблемы с повторным вызовом конструктора, естественно, нет: конструктор вызывается в super().__call__(), к которому мы обращаемся ровно один раз.

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

Borg, или шалость удалась

Название паттерну, который предлагается как альтернатива синглетону, придумали хорошее: в «Star Trek» Borg — коллективный разум, все его представители имеют полностью коллективное сознание. Да и вообще явно весёлый человек в своё время его придумал. Пусть, дескать, каждый, кто хочет, создаёт объект класса, и все объекты даже будут как будто разные, но внутри одинаковые — все данные у них всегда одни и в одном экземпляре существуют. Ну что, шутка вышла хорошая.

class Borg:
    _shared_state = {}  # Общий словарь для всех экземпляров

    def __new__(cls, *args, **kwargs):
        obj = super(Borg, cls).__new__(cls)
        obj.__dict__ = cls._shared_state
        return obj

    def __init__(self, value):
        self.value = value


b1 = Borg(10)
b2 = Borg(20)
print(b1.value)
print(b2.value)

Как видите, здесь словарь атрибутов объекта при создании экземпляра заменяется на общий для всех экземпляров словарь. Наследования, естественно, не предполагается (все потомки будут иметь общий __dict__). Но это нетрудно реализовать и через метаклассы, да и через базовый класс тоже довольно легко. Было бы зачем. Вот скажите, зачем вам делать синглетон, где вы имеете разные объекты с разным id, которые одинаковы по своей сути? Это остроумно (вообще я рукоплещу автору за идею), но вряд ли практично, так как может вызывать путаницу. Одно дело явно вызвать get_что-то-там(), понимая, что вы получите всегда один и тот же объект, а совсем другое — создавать обычные классы, возможно, даже не догадываясь об их «борговской» природе, видеть, что создаются разные объекты, а потом удивляться, что их атрибуты меняются непонятно когда и непонятно как.

И — вишенка на торте! — этот код два раза напечатает 20, а вовсе не 10, как в случае с синглетоном. Потому что второе создание борга тоже вызвало __init__. Браво! В общем, для практического кода паттерн кажется ужасным.

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

def borg():
    class _BorgBase:
        _shared_state = {}
        def __new__(cls, *args, **kwargs):
            obj = super().__new__(cls)
            obj.__dict__ = cls._shared_state
            return obj
    return _BorgBase


class Borg1(borg()):
    def __init__(self, value):
        self.value = value


class Borg2(borg()):
    def __init__(self, value):
        self.value = value

Идея проста. Класс _BorgBase определён не один раз, а внутри области видимости функции borg(). Каждый вызов функции порождает новый класс со своим словарём атрибутов для экземпляров. И экземпляры Borg1 абсолютно идентичны по данным, Borg2 — тоже, но между собой Borg1 и Borg2 не связаны, что и будет естественным поведением (насколько вообще поведение боргов может быть естественным).

В чём же сильная сторона решения? А в том, что ему не нужны объекты синхронизации. Создание словаря атрибутов объекта происходит очень рано, на этапе объявления класса (в случае с borg() — класса-наследника), а поскольку объявление, вероятно, происходит на уровне модуля, инициализация класса всегда производится ровно один раз и потокобезопасно, думать о синхронизации вообще не приходится. Это плюс. Но странности подхода он не перевешивает.

А как, собственно, надо?

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

Давайте подумаем, чего мы обычно ждём от синглетона, и прежде всего это:

1. Ленивая инстанциация (при первом использовании).

2. Единственность экземпляра до конца работы программы.

Но, согласитесь, это ведь уже напоминает нам что-то. Что-то очень, очень знакомое, присутствующее в языке, наверное, с начала его существования (я начал с Python 2.4 в 2007 году, и оно уже было). И это… модуль. Просто питоновский модуль. Он инициализируется при первом import. Сколько бы раз вы его ни импортировали, он инициализируется ровно в одном экземпляре, если вы не используете специальные экзотические трюки типа ручной загрузки модулей, конечно.

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

Посему вот такая реализация синглетона (естественно, это не просто кусок кода, а отдельный модуль), нравится мне куда больше:

class _MySingleton:
    ...

    
_MY_SINGLETON = _MySingleton()


def get_my_singleton():
    return _MY_SINGLETON

Часто можно и функции не делать, а просто глобальный объект использовать, но и так неплохо. Только надо помнить, что не в момент вызова функции создаётся наш объект, а при первом импорте модуля.

Единственное, чего у модуля нет — это параметров инициализации. Но ведь синглетон, как правило, настраивается (если вообще настраивается) один раз, и его параметры в 99% случаев — это просто часть глобальной конфигурации системы. Часто это можно решить наличием файла settings.py, который импортирует каждый нуждающийся. А ещё можно настройки синглетона держать в специальном модуле, хотя это тоже стрельба из пушки по воробьям.

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

Абстрагируемся от того, нужен ли тут синглетон, просто представим, что нужен. Теперь реализуем два модуля примерно такого содержания:

## chartcoll.py
# Это модуль для пользователей
CHART_PATH = "."

class IChartCollection:
    pass  # Здесь будет интерфейс

def get_chart_collection(path: str) -> IChartCollection:
    global CHART_PATH
    CHART_PATH = path
    import chartcoll_impl
    return chartcoll_impl.CHART_COLLECTION


## chartcoll_impl.py
# Этот модуль спрятан
from chartcoll import CHART_PATH, IChartCollection

class ChartCollection(IChartCollection):
    def __init__(self, path: str):
        pass

CHART_COLLECTION = ChartCollection(CHART_PATH)

Точкой доступа к нашему синглетону становится chartcoll.py, и, строго говоря, выглядит всё это для пользователя совершенно как старый добрый синглетон в стиле C++. С тем отличием, что этот модуль содержит только интерфейс, а глобальный объект находится совсем в другом модуле, chartcoll_impl.py.  chartcoll_impl.py свободно может импортировать первый модуль и прочитать путь из CHART_PATH. Громоздко? Может быть, но учитывая, что синглетонов в системе не должно быть много, это приемлемо. Зато ни слова о синхронизации сказать не пришлось. Присваивание строки переменной обычно атомарно (впрочем, поговорим и об этом), загрузку модуля синхронизирует сам интерпретатор. И главное — это нужно в тех редких случаях, когда вам не обойтись без передачи параметра. А вообще — надо ли?

В общем, логика проста:

1. Объект без состояния, служащий просто корнем интерфейса — не надо даже класса создавать. Просто модуль.

2. Объект посложнее, но без параметров создания — просто глобальный объект в модуле. Или — внезапно — вообще класс, а не объект (только методы не забудьте сделать статическими). Импортировали модуль — и используете.

3. Объект, полагающийся на глобальные настройки — ну, наверное, он может прочитать их из модуля settings. Можно, конечно, использовать и подход с двумя файлами, но я бы скорее не стал.

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

А на кой он вообще нужен?

Я давно недолюбливаю этот паттерн. Даже в C++ обычно использовал его разве что в ситуации, когда мне было нужно выдать интерфейс корневого API некоей библиотеки. И уже этот API был лишь средством создания других объектов библиотеки. В C++ последовательность инициализации модулей вообще бывает непредсказуема, там приходится придумывать что-то. Но в Python она предсказуема до невозможности: первым загружается тот, кого первым импортировали. И если вы импортировали какой-то модуль к себе, то после этого импорта вы имеете полное право рассчитывать, что модуль инициализирован.

Словом, зачем тут вообще синглетоны по модели C++? Привычные реализации этого паттерна до ужаса непитоничны (unpythonic). И всё равно, по сути, синглетон — что-то вроде глобального объекта, лишь немного более цивилизованного. Он, конечно, облегчает жизнь тем, кому лень обдумывать способы передачи нужного контекста в нужное место программы, но чаще не так уж и ценен. И даже если вы решили его применить, вместо традиционных реализаций проще использовать модули.

О жизни без GIL

И последнее. Сейчас появляется вариант CPython без GIL. Пока это экзотика, и я подозреваю, что до продакшена это всё дойдёт не так скоро, поскольку большинство расширений, которые отчасти и делают Python таким привлекательным, завязаны на GIL.

И единственной реализацией синглетона, которая будет заведомо и без проблем работать там без изменений, окажется простое использование модуля и глобальной переменной в нём. Или класса (не объекта) в модуле. Даже без плясок с get_что-то-там(). Просто переменной.

Почему? Да потому что модуль не может быть ни полуинициализированным, ни дважды инициализированным, ни инициализируемым из нескольких потоков параллельно, на уровне механизма импорта модулей о потокобезопасности позаботятся без вас. Именно такая реализация будет работать везде, вообще везде. И только она.

Выводы

То, что в C++ — смерть (глобальные объекты), в Python оказывается самой адекватной реализацией синглетона просто по причине принципиально другого подхода к инициализации модулей.  И не надо колоть дрова поперёк волокон, таща в язык неприменимый к его особенностям опыт из других языков. Есть то, что конфликтует с принципами языка, и о таких вещах стоит забыть.