Think about your house’s thermostat. There’s exactly one of them controlling the heating for the whole home — not one per room, quietly disagreeing about whether it’s warm enough. If every room had its own thermostat making independent decisions, the house would be chaos: one room blasting heat while another blasts cold air, with nobody in charge of the whole picture. Instead, there’s a single, shared thermostat that every part of the house checks and trusts, and that single source of truth is exactly what keeps the temperature sensible everywhere.

The Singleton pattern brings that same idea into software. It’s a design pattern that guarantees a particular class can only ever have one single instance in the entire running program, no matter how many different places in the code ask for it. Every single request for that object hands back the exact same one, shared everywhere, instead of quietly creating a fresh copy each time.

It’s worth being clear from the very start about what makes Singleton different from simply reusing an object out of habit. Plenty of code reuses the same object without any special pattern involved at all — you create one thing, pass it around, and everyone happens to use it. Singleton goes a step further: it makes reuse mandatory and unavoidable, structurally built into the class itself, so that even a careless or unfamiliar programmer, years later, physically cannot create a second, competing copy by accident. That difference between “usually shared” and “guaranteed to be shared” is the whole reason this pattern exists as a named, deliberate design choice rather than just a coding habit.

Formally, the Singleton pattern is a creational design pattern — meaning it belongs to the family of patterns concerned with how objects get built — whose entire job is to ensure a class has only one instance, and to provide one well-known, shared way for the rest of the program to reach that instance. Two separate promises are bundled together inside that one sentence, and it’s worth pulling them apart, because both matter equally.

1. The “only one” promise. No matter how many times, or from how many different places, the code asks to create this object, it should always get back the same one, never a second copy.
2. The “shared access” promise. There needs to be one obvious, agreed-upon way for any part of the program to reach that single instance — usually a specific method everyone calls to “get” it.

It’s worth being precise about what makes this different from simply creating one object and being careful never to create a second. A true Singleton doesn’t rely on careful, disciplined programmers remembering not to create extras — it makes creating a second instance structurally impossible, built directly into the class itself, so the guarantee holds even if someone new joins the project years later and has never heard the word “Singleton” in their life.

This is also a good moment to clear up a common point of confusion: Singleton is a pattern about object identity, not about the object’s behaviour or purpose. A Singleton class could hold configuration settings, manage a network connection, track a game’s score, or do almost anything else — the pattern says nothing about what the class actually does. What it insists on, and only on, is that no matter what job the class performs, there is exactly one of it, and everyone who asks for it gets handed the same one.

The Singleton pattern is one of the original 23 patterns catalogued in 1994 by the four authors — Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, nicknamed the “Gang of Four” — in their landmark book Design Patterns: Elements of Reusable Object-Oriented Software. It was placed in the smallest of the three pattern families, the creational group, alongside Factory Method, Abstract Factory, Builder, and Prototype.

Interestingly, Singleton has had a rockier reputation over the decades than almost any other pattern in the original catalogue. It was embraced enthusiastically in the years right after the book’s release, showing up constantly in early object-oriented codebases as the go-to solution whenever a team needed “one shared thing.” But as software teams gained more experience — particularly with automated testing and multi-threaded programs — many architects began noticing real, recurring costs hidden behind Singleton’s apparent convenience, costs that are explored in depth later in this guide.

That history matters, because it shapes how a thoughtful architect should approach Singleton today: not as a pattern to avoid entirely, and not as a default first choice either, but as a tool with a genuinely narrow, well-understood set of situations where it earns its place.

It’s also worth knowing that the pattern’s underlying idea is far older than the 1994 catalogue itself. Long before object-oriented programming existed, plenty of systems already relied on the concept of a single, authoritative source — a single master clock coordinating a factory floor, a single central switchboard routing every telephone call in a city. The Gang of Four didn’t invent the idea of “only one, shared everywhere”; they simply gave that recurring shape a name, a formal structure, and a place in a widely shared vocabulary that engineers could finally use to talk about it precisely.

It’s worth pausing on why “only one” is sometimes exactly what a program needs, rather than an arbitrary restriction. A handful of recurring situations in software genuinely call for a single, shared, coordinating object.

Notice the common thread running through all four: in each case, having two of the object wouldn’t just be wasteful — it would actually be wrong, producing inconsistent or contradictory behaviour. That distinction is the real test for whether Singleton genuinely fits a situation: ask not “would one be convenient?” but “would two actually cause a problem?”

It helps to picture the opposite scenario too, since it makes the “genuinely wrong” test easier to apply in practice. Imagine a to-do list app that accidentally created two separate settings objects — one telling the interface to display in dark mode, and a second, unrelated copy still holding the old light mode setting because it was created from a slightly stale part of the code. Depending on which copy a particular screen happened to read from, the app would look inconsistent, sometimes dark, sometimes light, with no obvious explanation to the confused user staring at it. That is exactly the kind of quiet, hard-to-trace bug the Singleton pattern exists to rule out from the start, by making the “two copies” scenario structurally impossible rather than merely unlikely.

Nearly every implementation of the Singleton pattern, across every programming language, is built from the same three structural ingredients working together — three small, deliberate pieces that between them make “only one, ever” a genuine, enforceable guarantee.

• A private, hidden instance. The single object is stored inside the class itself, kept out of reach of any outside code that might try to create competing copies.
• A private constructor. The normal, everyday way of creating an object — calling “new” directly — is deliberately blocked from outside the class, so nobody can accidentally sneak in a second instance.
• A public access method. One shared, publicly available method (often named something like getInstance()) is the only approved way to reach the object — creating it the very first time it’s needed, and simply handing back the same one on every later call.

It’s worth noticing how deliberately restrictive this structure is, compared to an ordinary class. A normal class practically invites you to create as many instances as you like — that’s the entire point of object-oriented programming, being able to stamp out many independent copies of the same blueprint. A Singleton class quietly works against that natural instinct, blocking off the usual route and funnelling every single request through one narrow, controlled doorway instead. That deliberate restriction is exactly what makes the guarantee trustworthy: it isn’t a suggestion or a convention that a careful team might follow, it’s a rule enforced by the structure of the code itself.

The clearest way to understand Singleton is to watch it evolve from a naive first attempt into a properly working version, noticing exactly which problem each refinement is solving.

Step One: The Naive Attempt

class AppLogger:
    def __init__(self):
        self.log_lines = []

# Nothing stops two completely separate instances from existing
logger_a = AppLogger()
logger_b = AppLogger()
print(logger_a is logger_b)  # False — this is not a Singleton yet

This class works perfectly well as an ordinary object, but it offers no actual guarantee — anyone, anywhere in the codebase, can call AppLogger() as many times as they like, quietly creating a scattered mess of unrelated logger objects that never share their data.

Step Two: Controlling Creation

class AppLogger:
    _instance = None

    def __new__(cls):
        # __new__ runs before __init__, and we intercept it here
        if cls._instance is None:
            cls._instance = super().__new__(cls)
            cls._instance.log_lines = []
        return cls._instance

    def log(self, message):
        self.log_lines.append(message)

logger_a = AppLogger()
logger_b = AppLogger()
print(logger_a is logger_b)  # True — same object, every time
logger_a.log("Started up")
print(logger_b.log_lines)  # ["Started up"] — visible from either variable

Now the class genuinely enforces its own promise. Notice something important: no matter which variable name is used to reach it, both point at the same underlying object, so writing through one is instantly visible through the other. That shared visibility is the entire point of the pattern.

public class AppLogger {
    private static AppLogger instance;
    private AppLogger() { }  // blocked from outside the class

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

Comparing the two languages side by side reveals something worth remembering: the underlying idea is identical in both, but the exact mechanics differ because the languages themselves work differently under the hood. Python intercepts object creation through a special method called __new__, while Java relies on a private constructor combined with a static field. Whatever language you’re working in, the questions to ask stay the same: where is the one shared copy stored, what stops anyone from creating a second one, and what single door does everyone use to reach it?

There’s an important design choice hiding inside every Singleton implementation: exactly when should the single instance actually get created? There are two competing answers, each with genuine trade-offs.

Lazy initialization introduces a subtle danger the moment a program can run more than one thread of execution at the same time — which is extremely common in modern software. Imagine two threads both calling getInstance() at almost exactly the same moment, before the single instance has been created yet.

Both threads check “has this been created yet?” at nearly the same instant, both see “no” before either has finished creating one, and both proceed to build their own separate instance. The Singleton’s core promise — only one instance, ever — silently breaks, and the bug is often maddeningly hard to reproduce, because it only shows up under specific timing conditions that don’t happen every single run.

public class AppLogger {
    private static volatile AppLogger instance;
    private AppLogger() { }

    public static AppLogger getInstance() {
        if (instance == null) {              // first, fast check
            synchronized (AppLogger.class) {
                if (instance == null) {          // second check, now safely locked
                    instance = new AppLogger();
                }
            }
        }
        return instance;
    }
}

This technique, often called double-checked locking, only pays the cost of locking during the brief window when the object might not exist yet, and skips that cost entirely on every later call once the instance is already safely built. It’s a clever balance between safety and speed, though it’s also a good example of why thread-safe Singletons are noticeably more complex to write correctly than they first appear.

It’s worth understanding why the check happens twice rather than once, because the reasoning is subtle. The first check, before the lock, exists purely for speed — most of the time, the instance already exists, and there’s no point paying the cost of a lock just to confirm what’s already obviously true. The second check, after acquiring the lock, exists for safety — it’s entirely possible that another thread slipped in and created the instance in the tiny gap of time between the first check and actually acquiring the lock, so the code checks again, this time protected, before deciding whether to build anything. Skipping either check reintroduces one of the two problems this pattern is carefully balancing: skip the first, and every single call pays an unnecessary locking cost forever; skip the second, and the original race condition quietly returns.

Beyond textbook examples, Singleton shows up in genuinely common, practical corners of real software systems. Here are some of the places it appears most often.

It’s worth noting that game programming, in particular, has a long, complicated relationship with Singleton — it’s extremely common in game engines for convenience, precisely because so many systems (input, audio, scoring) genuinely need one central coordinator, yet experienced game architects also warn that overusing it across an entire codebase can make large games surprisingly difficult to test and maintain, for the same reasons explored in the next section.

Beyond these classic examples, Singleton also shows up quietly inside caching systems, where one shared cache needs to be checked and updated consistently by every part of an application, and inside thread pool managers, which coordinate a limited, shared set of worker threads across an entire program. In every one of these cases, the same underlying justification applies: the resource being managed — a log file, a settings file, a pool of connections, a cache, a set of worker threads — is something the whole system needs to agree about, and letting two disconnected versions exist side by side would create exactly the kind of contradiction a Singleton is built to prevent.

Singleton has a reputation, among many experienced architects, as one of the most misused patterns in the entire catalogue. Understanding exactly why is essential to using it well, rather than reaching for it out of habit.

It’s Really Just Global State, Dressed Up

At its core, a Singleton is a form of global state — a single object reachable from literally anywhere in the program. Global state has been understood as risky since long before design patterns existed, because it allows any part of a codebase to quietly affect any other part, creating hidden dependencies that are hard to trace.

It Makes Testing Genuinely Harder

Automated tests usually want a fresh, isolated, predictable starting point for every test run. A Singleton, by definition, persists across the whole program’s lifetime, which means one test can accidentally leave behind state that quietly affects the next test — producing flaky, unreliable test results that are painful to debug.

It Hides Dependencies

When a class needs another object, the healthiest approach is usually to receive it openly, as a clearly visible parameter. A Singleton instead lets a class reach out and grab what it needs silently, from anywhere inside its own code, without that dependency ever showing up in its public signature — making the class quietly harder to understand at a glance.

None of this means Singleton is inherently bad — it means Singleton is a pattern whose costs are easy to underestimate at first glance, and whose benefits are easy to overestimate. The pattern earns its place only when the “only one, genuinely” requirement from earlier in this guide is real, not just convenient.

Here’s a small, concrete illustration of the testing problem in practice. Imagine an automated test that checks whether a shopping cart correctly applies a ten percent discount. If the discount logic quietly reads its rate from a global Singleton settings object, and an earlier, unrelated test happened to change that rate while testing a different discount scenario, the cart test might fail — not because the cart logic is broken, but because a completely different test left behind some leftover state. Chasing down failures like this, where the actual bug is nowhere near the test that failed, is one of the most common and most frustrating consequences of relying too heavily on Singleton-based global state.

Because of the concerns above, many experienced architects reach for alternatives that capture the useful part of Singleton — a single, shared, coordinated object — without its sharpest downsides.

# settings.py — this module is only ever loaded once by Python
theme = "light"
language = "en"

# anywhere_else.py
import settings
print(settings.theme)  # every importer sees the exact same shared values

Dependency Injection, in particular, has become the preferred default in many professional codebases precisely because it keeps the “one shared instance” benefit while making every dependency visible and swappable — solving the testing and hidden-dependency problems that make traditional Singleton implementations so controversial.

To see the practical difference clearly, compare two versions of an order-processing class. One version reaches inside itself and silently calls Logger.getInstance() whenever it needs to write a log line — the dependency on logging is invisible from the outside, buried inside the method body. The other version simply accepts a logger as a parameter when it’s created, openly declaring “I need something that can log messages” right there in its own definition. Both versions might use the exact same underlying shared logger in production, but the second version can be handed a completely different, fake logger during a test, with zero changes to the class itself — a flexibility the first version simply doesn’t offer.

Even in situations where Singleton genuinely fits, a handful of failure modes come up again and again. Recognising them early is the difference between a pattern that quietly serves a system and one that quietly poisons it.

Reaching for Singleton Out of Convenience

The single most common mistake is using Singleton simply because it’s an easy way to make an object reachable from anywhere, rather than because the situation genuinely requires exactly one instance to exist.

Forgetting About Multiple Threads

A lazy Singleton implementation that looks perfectly correct in casual testing can silently create two instances under real production load, once multiple threads genuinely overlap in timing — a bug that’s notoriously hard to catch before it happens live.

Letting a Singleton Grow Into a “God Object”

Because a Singleton is so easy to reach from anywhere, there’s a strong temptation to keep adding more and more responsibilities to it over time, until it quietly becomes a bloated object that knows and does far too much — a well-known anti-pattern in its own right.

A handful of questions come up whenever a team debates whether to reach for Singleton. Getting straight answers on them prevents a lot of unnecessary back-and-forth.

Is Singleton the same thing as a global variable?

They’re closely related, but not identical. A plain global variable can usually be reassigned or replaced by any code that touches it. A properly built Singleton actively protects itself against having a second instance created, which a simple global variable does not guarantee on its own.

Can a Singleton ever be reset or replaced during a program’s run?

Technically yes, if the class is specifically designed to allow it, but doing so goes against the spirit of the pattern and is usually a sign that a different design — like Dependency Injection — would fit the situation more naturally.

Does every programming language need special tricks to build a Singleton?

The core idea is universal, but the exact mechanics vary. Languages like Python, where modules are only loaded once, make a Singleton-like shared object almost trivial to achieve. Languages like Java or C++ typically require more explicit machinery, like private constructors and careful thread-safety handling.

Is it true that many senior engineers avoid Singleton entirely?

Many do prefer to avoid it as a default choice, largely for the testing and hidden-dependency reasons discussed earlier — but “avoid by default” is different from “never use.” Most experienced architects still reach for it in the narrow situations where two instances would genuinely cause incorrect behaviour, while defaulting to Dependency Injection everywhere else.

How is Singleton different from just using a class with only static methods?

A class made entirely of static methods, with no instance at all, avoids some Singleton concerns but also loses genuine object-oriented flexibility — it can’t be passed around, substituted with a test version, or extended through inheritance nearly as easily as a properly designed Singleton instance can.