Singleton Pattern · Design Patterns

What is the Singleton pattern?

Singleton means your program keeps only one object of a type, and every caller gets that same object through one shared door (often getInstance()).

Think of it like a building with one reception desk. Nobody builds a second reception in each hallway. Everyone walks to the same desk.

You usually need three pieces:

Block casual creation — private constructor (or the language’s equivalent).
Store the one instance — in a static field, module variable, or sync.Once.
Expose one accessor — getInstance(), Get(), or a module export.

If those three hold, you have a Singleton.

Why it exists (a short story)

Your checkout flow loads settings from a file. Your reporting job also loads settings. Each does new Config(...).

Months later, checkout reads one timeout and reports reads another. Bugs look random. The real issue is simple: two configs.

Singleton (or “create once and inject everywhere”) is how teams stop that class of bug.

One shared instance

  Checkout ──┐
             ├──▶ getInstance() ──▶ Config (only one)
  Reports  ──┘

Wrong vs right

Wrong: many `new` calls

# Looks fine… until two features each create their own config
checkout_config = Config("checkout.properties")
report_config = Config("report.properties")
# Now the app has two sources of truth

// Looks fine… until two features each create their own config
Config checkoutConfig = new Config("checkout.properties");
Config reportConfig = new Config("report.properties");
// Now the app has two sources of truth

// Looks fine… until two features each create their own config
checkoutConfig := NewConfig("checkout.properties")
reportConfig := NewConfig("report.properties")
// Now the app has two sources of truth

// Looks fine… until two features each create their own config
const checkoutConfig = new Config('checkout.properties');
const reportConfig = new Config('report.properties');
// Now the app has two sources of truth

Two objects means two truths. Settings drift. Memory and connections get duplicated.

Right: one shared accessor

Callers stop constructing. They ask for “the” config. The type (or the app’s composition root) owns the rule that there is only one.

How to build it

1) Eager creation

Create the instance as soon as the type loads.

class EagerSingleton:
    _instance = None

    def __new__(cls):
        if cls._instance is None:
            cls._instance = super().__new__(cls)
        return cls._instance

# Idiomatic Python: one module-level object
config = EagerSingleton()

def get_instance():
    return config

public class EagerSingleton {
    private static final EagerSingleton instance = new EagerSingleton();

    private EagerSingleton() {}

    public static EagerSingleton getInstance() {
        return instance;
    }
}

package singleton

type EagerSingleton struct{}

var instance = &EagerSingleton{}

func GetInstance() *EagerSingleton {
	return instance
}

class EagerSingleton {
  private static instance = new EagerSingleton();

  private constructor() {}

  static getInstance() {
    return EagerSingleton.instance;
  }
}

Good when: the object is cheap and you always need it.
Watch out: you pay creation cost even if nobody uses it.
In Java this is usually thread-safe because class loading is synchronized.

2) Lazy creation (unsafe if naive)

Create on the first call.

_instance = None

def get_instance():
    global _instance
    if _instance is None:  # two threads can both pass
        _instance = object()
    return _instance

public class LazySingleton {
    private static LazySingleton instance;

    private LazySingleton() {}

    public static LazySingleton getInstance() {
        if (instance == null) {          // Thread A and B can both pass
            instance = new LazySingleton();
        }
        return instance;
    }
}

package singleton

type LazySingleton struct{}

var instance *LazySingleton

func GetInstance() *LazySingleton {
	if instance == nil { // two goroutines can both pass
		instance = &LazySingleton{}
	}
	return instance
}

class LazySingleton {
  private static instance?: LazySingleton;

  private constructor() {}

  static getInstance() {
    if (!LazySingleton.instance) {
      LazySingleton.instance = new LazySingleton();
    }
    return LazySingleton.instance;
  }
}

Good when: creation is expensive and maybe unused.
Watch out: in multi-threaded code, two callers can both see “not created yet” and each make an instance. Then Singleton is broken silently.

3) Safe lazy: lock while creating

import threading

_lock = threading.Lock()
_instance = None

def get_instance():
    global _instance
    with _lock:
        if _instance is None:
            _instance = object()
        return _instance

public class ThreadSafeSingleton {
    private static ThreadSafeSingleton instance;

    private ThreadSafeSingleton() {}

    public static synchronized ThreadSafeSingleton getInstance() {
        if (instance == null) {
            instance = new ThreadSafeSingleton();
        }
        return instance;
    }
}

package singleton

import "sync"

type ThreadSafeSingleton struct{}

var (
	instance *ThreadSafeSingleton
	mu       sync.Mutex
)

func GetInstance() *ThreadSafeSingleton {
	mu.Lock()
	defer mu.Unlock()
	if instance == nil {
		instance = &ThreadSafeSingleton{}
	}
	return instance
}

// App code usually runs on one JS thread.
// Still model the idea: create once, reuse forever.
class ThreadSafeSingleton {
  private static instance?: ThreadSafeSingleton;

  private constructor() {}

  static getInstance() {
    if (!ThreadSafeSingleton.instance) {
      ThreadSafeSingleton.instance = new ThreadSafeSingleton();
    }
    return ThreadSafeSingleton.instance;
  }
}

Good when: you need lazy + safe and the method is not ultra-hot.
Watch out: every call may pay for locking, even after the object exists.

4) Safer lazy: double-check / once

import threading

_lock = threading.Lock()
_instance = None

def get_instance():
    global _instance
    if _instance is None:
        with _lock:
            if _instance is None:
                _instance = object()
    return _instance

public class DoubleCheckedSingleton {
    private static volatile DoubleCheckedSingleton instance;

    private DoubleCheckedSingleton() {}

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

package singleton

import "sync"

type OnceSingleton struct{}

var (
	instance *OnceSingleton
	once     sync.Once
)

func GetInstance() *OnceSingleton {
	once.Do(func() {
		instance = &OnceSingleton{}
	})
	return instance
}

class DoubleCheckedStyle {
  private static instance?: DoubleCheckedStyle;

  private constructor() {}

  static getInstance() {
    if (!DoubleCheckedStyle.instance) {
      DoubleCheckedStyle.instance = new DoubleCheckedStyle();
    }
    return DoubleCheckedStyle.instance;
  }
}

Java note: volatile matters. Without it, another thread can see a half-built object.
Go note: prefer sync.Once — it is the clear, idiomatic tool.
Python/TS note: a module-level instance is often simpler than hand-rolled locks.

5) Holder class / module instance (strong default)

# Module import runs once — clear and idiomatic
class AppConfig:
    def __init__(self, name: str) -> None:
        self.name = name

config = AppConfig("catalog")

def get_config() -> AppConfig:
    return config

public class BillPughSingleton {
    private BillPughSingleton() {}

    private static class Holder {
        private static final BillPughSingleton INSTANCE = new BillPughSingleton();
    }

    public static BillPughSingleton getInstance() {
        return Holder.INSTANCE;
    }
}

package singleton

import "sync"

type HolderStyle struct{}

var (
	instance *HolderStyle
	once     sync.Once
)

func GetInstance() *HolderStyle {
	once.Do(func() {
		instance = &HolderStyle{}
	})
	return instance
}

// ES modules evaluate once per app — usually enough
class AppConfig {
  constructor(readonly name: string) {}
}

const config = new AppConfig('catalog');

export function getConfig() {
  return config;
}

Prefer this pattern when you want lazy + safe without clever locking.
Java: Bill Pugh holder. Go: sync.Once. Python/TS: module-level object.

Worked example: config manager

One place answers “what is db.url?”

class ConfigManager:
    def __init__(self) -> None:
        self._data = {"db.url": "postgres://localhost/app"}

    def get(self, key: str) -> str:
        return self._data[key]

config = ConfigManager()

def get_config() -> ConfigManager:
    return config

db_url = get_config().get("db.url")

public class ConfigManager {
    private final Properties props = new Properties();

    private ConfigManager() {
        // load config.properties once
    }

    private static class Holder {
        private static final ConfigManager INSTANCE = new ConfigManager();
    }

    public static ConfigManager getInstance() {
        return Holder.INSTANCE;
    }

    public String get(String key) {
        return props.getProperty(key);
    }
}

String dbUrl = ConfigManager.getInstance().get("db.url");

package config

import "sync"

type Manager struct {
	data map[string]string
}

var (
	instance *Manager
	once     sync.Once
)

func Get() *Manager {
	once.Do(func() {
		instance = &Manager{
			data: map[string]string{"db.url": "postgres://localhost/app"},
		}
	})
	return instance
}

func (m *Manager) Get(key string) string {
	return m.data[key]
}

// dbURL := config.Get().Get("db.url")

class ConfigManager {
  private data = { 'db.url': 'postgres://localhost/app' };

  get(key: keyof typeof this.data) {
    return this.data[key];
  }
}

const config = new ConfigManager();

export function getConfig() {
  return config;
}

const dbUrl = getConfig().get('db.url');

Every feature asks the same manager. Settings stay consistent.

When Singleton helps

Use it when a second instance would be wrong:

Process-wide settings
A single metrics / logging sink for the process
A shared resource where duplicates corrupt state

The test is not “would a global be handy?”
The test is: “Would two instances break correctness?”

When Singleton hurts (read this twice)

Singleton is famous — and often overused.

Testing gets harder. If code calls getInstance() deep inside, tests cannot easily swap a fake.

Dependencies go invisible. Readers cannot see what a class needs from its constructor.

Hidden global state makes bugs that depend on call order.

In modern apps, a healthier default is often:

Create one instance at startup.
Pass it in (dependency injection).

You still have one object. You avoid a global door. Prefer Singleton when the type itself must enforce “only one.” Prefer injection when the application decides “we only need one.”

Idea	What it solves
Singleton	Exactly one instance + one access point
DI / one shared bean	One instance, but wired explicitly
Static utility class	No instance — only functions (different tool)
Factory	Which object to create, not how many

Factory answers “make the right payment type.”
Singleton answers “there must be only one config.”

Practical checklist

Prefer holder / once / module instance over locking every call.
Use eager creation when the object is tiny and always needed.
If you use double-checked locking in Java, never forget volatile.
Do not make every service a Singleton.
If the type can be cloned or deserialized, close those side doors too.

Exercise

Turn this logger into a safe Singleton. Then prove two lookups are the same object.

class Logger:
    # TODO: make this a safe Singleton
    def info(self, message: str) -> None:
        print(message)

public class Logger {
    // TODO: make this a safe Singleton
    public void info(String message) {
        System.out.println(message);
    }
}

package logger

type Logger struct{}

// TODO: make this a safe Singleton
func (l *Logger) Info(message string) {
	println(message)
}

class Logger {
  // TODO: make this a safe Singleton
  info(message: string) {
    console.log(message);
  }
}

Your goals

Outside code cannot freely new extra loggers.
getInstance() / Get() / module export always returns the same object.
Creation is thread-safe (or idiomatic for the language).

Show one solid answer

class Logger:
    def info(self, message: str) -> None:
        print(message)

logger = Logger()

def get_logger() -> Logger:
    return logger

public class Logger {
    private Logger() {}

    private static class Holder {
        private static final Logger INSTANCE = new Logger();
    }

    public static Logger getInstance() {
        return Holder.INSTANCE;
    }

    public void info(String message) {
        System.out.println(message);
    }
}

package logger

import "sync"

type Logger struct{}

var (
	instance *Logger
	once     sync.Once
)

func Get() *Logger {
	once.Do(func() {
		instance = &Logger{}
	})
	return instance
}

func (l *Logger) Info(message string) {
	println(message)
}

class Logger {
  info(message: string) {
    console.log(message);
  }
}

const logger = new Logger();

export function getLogger() {
  return logger;
}

Quick proof: fetch twice and compare identity (== / is / pointer equality).

Interview questions

Q1. What is Singleton?
A design that keeps one instance of a type and exposes a single way to get it.

Q2. Eager vs lazy?
Eager creates when the type loads. Lazy creates on first use.

Q3. Why is naive lazy unsafe?
Two threads can both observe “missing” and each construct an instance.

Q4. How do you make lazy safe in Java?
Synchronized method, double-checked locking with volatile, or a static holder class. Holder is usually the cleanest class-based option.

Q5. What are the drawbacks?
Harder tests, hidden dependencies, global state. Many teams prefer create-once + inject.

Q6. Singleton vs dependency injection?
Both can yield one instance. DI makes the dependency explicit. Singleton enforces uniqueness inside the type (and often via a global accessor).

What to learn next

Next: Factory Pattern — create the right object without scattering new and type checks everywhere.