싱글턴(Singleton) 패턴 : 심화The Singleton Pattern: Advanced

Creating classes dynamically with type

This time, let’s look at how to create a class by using type directly. type takes three arguments and creates a class dynamically.

1. name: the name of the class
2. bases: a tuple of base classes
3. attrs: the class dictionary

AdvancedList = type('AdvancedList', (list,), { "hello": lambda self: print("hello") })

h = AdvancedList((1,2,3,4))
h.hello()

This creates a class named AdvancedList whose base class is list, and defines a hello method as one of its attributes.

Eager

%%{
  init: {
    'theme': 'base',
    'themeVariables': {
      'primaryColor': '#2a3844',
      'lineColor': '#fff',
      'primaryTextColor': '#fff',
      'tertiaryColor': '#fff'
    }
  }
}%%

classDiagram
    direction BT

    class SingletonMeta{
        -_instances: dict

        -__init__()
        -__call__() Singleton
    }

    class Singleton{
        +some_business_logic()
    }

    Singleton --|> SingletonMeta

Singleton implementation: Eager

The Eager singleton pattern is a form of the singleton design pattern in which the instance is created ahead of time, before it’s needed.

1. Define a metaclass and override __init__
2. Use the metaclass’s super to define the class and create the object
3. Override the metaclass’s __call__

import logging

class SingletonMeta(type):
    _instances = {}

    def __init__(cls, name, bases, attrs):
        logging.info("metaclass __init__")

        super().__init__(name, bases, attrs)

        instance = super().__call__()
        cls._instances[cls] = instance

    def __call__(cls, *args, **kwargs):
        logging.info("metaclass __call__")

        return cls._instances.get(cls)

from eager.meta import SingletonMeta

class Singleton(metaclass=SingletonMeta):
    def some_business_logic(self):
        ...

from eager.singleton import Singleton

def test_meta_singleton():
    obj_1 = Singleton()
    obj_2 = Singleton()

    assert obj_1 is obj_2

If you step through it with a debugger, you’ll see the metaclass’s __init__ method is called automatically when the class is loaded, not when an object is created from the class. That lets you create an instance for each class that uses the metaclass.

For the metaclass, super() is type, which it inherits from. This is the same process as creating a class with type, which we saw earlier. After that, when the metaclass’s __call__ method is called, it returns the object that was created in advance.

INFO     root:meta.py:8 metaclass __init__

INFO     root:meta.py:15 metaclass __call__
INFO     root:meta.py:15 metaclass __call__

By creating the singleton instance when the program starts, this approach naturally sidesteps concurrency issues in a multithreaded environment. The Eager singleton pattern has the advantages of giving you clear control over when the instance is created and letting you access the instance at runtime without any extra handling.

On the other hand, it can waste resources and introduce dependencies on initialization order, which can make the code less flexible.

Eager pattern / Lazy pattern

The Eager and Lazy singleton patterns differ in when the object is created.

Eager singleton pattern

• Definition: In the Eager singleton pattern, the singleton instance is created when the class is loaded. That is, the instance is created and allocated in memory when the program starts or when the class is first loaded.
• Pros: Safe in a multithreaded environment. Since the instance is created at program start, it can be accessed without concurrency issues.
• Cons: The instance is created up front even when it’s never actually needed, which wastes resources.

Lazy singleton pattern

• Definition: In the Lazy singleton pattern, the singleton instance is created at the moment it’s actually needed, i.e. the first time the instance is accessed.
• Pros: The instance is created only when it’s actually needed, so resources are used efficiently. It also shortens the initial load time.
• Cons: Requires extra synchronization in a multithreaded environment.

Class diagram: Thread Safe

%%{
  init: {
    'theme': 'base',
    'themeVariables': {
      'primaryColor': '#2a3844',
      'lineColor': '#fff',
      'primaryTextColor': '#fff',
      'tertiaryColor': '#fff'
    }
  }
}%%

classDiagram
    direction BT

    class SingletonMeta{
        -_instances: dict

        -__call__() Singleton
    }

    class Singleton{
        +some_business_logic()
    }

    Singleton --|> SingletonMeta

Singleton implementation: Thread Safe

A race condition is a problem that can occur when multiple threads or processes access a shared resource at the same time. In a multithreaded environment, if several threads hit a Lazy singleton at the moment the instance is being created, there’s a risk of a race condition in which the “single” instance gets created multiple times.

So we need additional synchronization logic to prevent this.

1. Define a metaclass and override __new__
2. Use threading.Lock()

from typing import Self
import threading
class SingletonMeta(type):
    _instances = None
    _lock = threading.Lock()

    def __call__(cls, *args, **kwargs) -> Self:
        with cls._lock:
            if cls not in cls._instances:
                cls._instances[cls] = super().__call__(*args, **kwargs)

        return cls._instances[cls]

from thread.meta import SingletonMeta
class Singleton(metaclass=SingletonMeta):
    def some_business_logic(self):
        pass

Checking in a multithreaded environment

To reproduce a race condition in a multithreaded environment, let’s add time.sleep to each metaclass. Even with a relatively short sleep in the Lazy singleton, you can see the test alternate between passing and failing. In contrast, the singleton using thread.Lock() reliably creates only one object even with a long sleep.

import threading
import time
class SingletonMeta(type):
    _instances = {}
    _lock = threading.Lock()

    def __call__(cls, *args, **kwargs):
        with cls._lock:
            if cls not in cls._instances:
                time.sleep(1) # added to trigger a race condition

                instance = super().__call__(*args, **kwargs)
                cls._instances[cls] = instance

        return cls._instances[cls]

import time
class SingletonMeta(type):
    _instances = {}

    def __call__(cls, *args, **kwargs):
        if cls not in cls._instances:
            time.sleep(0.00001) # added to trigger a race condition

            instance = super().__call__(*args, **kwargs)
            cls._instances[cls] = instance

        return cls._instances[cls]

import logging
import threading

from meta.singleton import Singleton as LazySingleton
from thread.singleton import Singleton as ThreadSafeSingleton
def test_thread_safe_singleton():
    result = race_condition(get_thread_singleton_instance)

    assert len(set(result)) == 1
def test_lazy_singleton():
    result = race_condition(get_lazy_singleton_instance)

    assert len(set(result)) == 1
def race_condition(func):
    threads = []
    results = [None] * 100  # list to store results
    barrier = threading.Barrier(100)  # make 100 threads run at the same time

    def wrapper(index):
        barrier.wait()  # wait until every thread reaches this point
        results[index] = func()

    for i in range(100):
        t = threading.Thread(target=wrapper, args=(i,))
        threads.append(t)

    for t in threads:
        t.start()

    for t in threads:
        t.join()

    return results  # return the results list
def get_thread_singleton_instance():
    s = ThreadSafeSingleton()
    logging.info(s)

    return s
def get_lazy_singleton_instance():
    s = LazySingleton()
    logging.info(s)

    return s

# When running test_lazy_singleton 
# - you can see it sometimes passes and sometimes fails

>       assert len(set(result)) == 1
E       assert 4 == 1

Wrapping up

We’ve looked at the singleton pattern in Python. Which of the various singleton patterns to use depends on the situation.

1. When the object is created
2. Whether you’re in a multithreaded environment

The Lazy singleton pattern creates the instance only when it’s actually needed, so it uses resources efficiently, but its drawback is that it needs synchronization in a multithreaded environment.

The Eager singleton pattern creates the instance at program start, guaranteeing safety in a multithreaded environment, but it can waste resources.