Understanding the Singleton Pattern: From Core Concept to Thread-Safe Java

Leo — Mon, 26 Oct 2026 01:52:16 +0000

Imagine you are building an application with a settings screen. A user switches the app theme to "dark", and ten different screens across the app need to apply that choice.

If each screen instantiated its own settings object with new, one screen might read "dark" while another still holds "light". What you actually need is one single settings object that is initialized once, exists as a single unique instance, and is shared across your entire application.

That is the exact problem the Singleton design pattern was created to solve.

Defined by the Gang of Four (GoF) in Design Patterns, its intent comes down to two guarantees:

Ensure a class has only one instance.
Provide a global point of access to it.

A plain global variable gives you the second guarantee, but it never stops someone from calling new and creating another instance of that class. A Singleton gives you both—and it does so using three core pieces:

A private constructor: locks the front door so ordinary external code cannot instantiate the class with new.
A static access method (getInstance()): acts as the single reception desk that everyone must go through.
One cached instance: stored in a private static field and returned on every subsequent call.

The Textbook Java Implementation (and Why It Breaks)

If you write the classic lazy initialization version in Java—where the instance is created only when someone asks for it the first time—it looks like this:

public class AppConfig {
    private static AppConfig instance;        // the one and only instance
    private String theme = "dark";

    private AppConfig() { }                   // nobody else can call new

    public static AppConfig getInstance() {   // the global access point
        if (instance == null) {
            instance = new AppConfig();       // created on first request
        }
        return instance;
    }

    public String getTheme() { return theme; }
}

When you test this in a simple single-threaded main method, it works as expected:

AppConfig a = AppConfig.getInstance();
AppConfig b = AppConfig.getInstance();
System.out.println(a == b);   // true: both variables point to the same object

The Hidden Trap: Concurrency

This simple implementation has a critical flaw: it is only safe when one task runs at a time.

In a multithreaded application, picture what happens when Thread A and Thread B call getInstance() at the exact same moment:

Thread A checks if (instance == null), sees that instance is null, and starts instantiating AppConfig.
Before Thread A finishes creating and assigning the object, Thread B also calls getInstance(), sees that instance is still null, and enters the if block too.
Both threads call new AppConfig(), leaving each thread holding a different instance.

It is just like two employees checking a cabinet, seeing there is no key yet, and each going off to have a new one made: individually, each person acted sensibly, but together they broke the "only one unique key" rule.

Fixing It in Java (Without Slowing Everything Down)

Developers have come up with several ways to make a Singleton thread-safe in Java, and each one trades something for something else:

Eager initialization: create the instance right when the JVM loads the class—simple, but wasteful if the object is never used.
synchronized method: put synchronized on getInstance()—thread-safe, but slow because threads must wait in line on every call.
Double-checked locking: synchronize only on the first creation, using the volatile keyword so writes to instance are visible across threads and the JVM doesn't reorder the initialization steps inside new.
The Bill Pugh Holder idiom: place the instance inside a nested static Holder class that isn't initialized until getInstance() is called:

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 log(String message) { System.out.println("LOG: " + message); }
}

Because the Java Language Specification (JLS) guarantees that the class initialization phase is sequential, the Holder idiom gives you lazy initialization and thread safety with no if, no synchronized, and no volatile.

The enum Singleton: recommended as the preferred approach in a summary of Joshua Bloch's Effective Java, because it also guards against two sneaky ways a private constructor can be bypassed (Reflection and Serialization).

The Part We Need to Talk About: The Architectural Price

Even when you write a rock-solid, thread-safe Singleton, convenience comes with a real cost.

The very feature that makes Singleton so tempting—shared global access—is the same reason it:

Violates the Single Responsibility Principle (the class manages both its business logic and its own lifecycle/uniqueness)
Creates tight coupling across your codebase
Can mask bad design
Makes unit testing difficult due to shared global state

So before reaching for a Singleton, the most important question isn't just "how do I make it thread-safe?"—it's:

Does this component truly have to exist as a single unique instance, or am I using it just because it's handy?

Read the Full Deep Dive

I just published the full, fully cited article over on Leo's Station, where I walk through all of these pieces step by step, including:

A visual breakdown of how Singleton works vs. global variables
Detailed walkthroughs and summary cheat-sheet of all 5 Java approaches (Eager, synchronized, Double-checked locking, Holder idiom, and Enum)
How Reflection and Serialization (readResolve()) can break a Singleton's uniqueness
Where the standard Java library itself uses Singletons (Runtime.getRuntime(), Desktop.getDesktop())
A clear guide on when to use Singleton (loggers, config, caches, thread/DB pools) and when to think twice

Read the full article here:

Understanding the Singleton Pattern: From Core Concept to Thread-Safe Java — Leo's Station

Let's discuss!

When you need a single shared component in Java today, do you still write a Singleton (like the Holder idiom or an enum), or do you rely entirely on Dependency Injection / IoC containers? Share your thoughts below!

How NASA's Roman telescope maps the universe: one instrument, three surveys

Leo — Tue, 13 Oct 2026 09:41:49 +0000

Most space telescopes work like a spotlight: point at one target and study it closely. NASA's Nancy Grace Roman Space Telescope is built more like a surveyor's camera. It launched on August 30, 2026, and NASA expects its first science images by early 2027.

If you like systems that sample the world at different resolutions and rates, Roman is a fun design to read about.

Same mirror as Hubble, a much bigger window

Roman's main mirror is 2.4 m across, the same as Hubble's. Its Wide Field Instrument takes images as sharp as Hubble's over a field of view at least 100 times larger (0.28 square degrees).

Hubble shows one street corner in fine detail. Roman shows the whole neighborhood at the same detail.

Survey 1: a map with three zoom levels

The High-Latitude Wide-Area Survey has three tiers, like a road atlas, a city map and a street view:

Tier	Area	What it is for
Wide	2,700 sq. degrees, one filter	the "road atlas"
Medium	2,400 sq. degrees, three filters, images and spectra	the "city map"
Deep	19.2 sq. degrees, about 1.2 magnitudes deeper	the "street view"

The goal is to study cosmic acceleration with weak gravitational lensing and the way galaxies cluster.

Survey 2: the same sky, again and again

The High-Latitude Time-Domain Survey revisits the same fields to catch things that change, mainly Type Ia supernovae, which are used to measure how the universe expanded. The northern and southern fields are each visited about every 5 days, and some filters repeat every 10 days. It is a time series, observed at a fixed cadence.

Survey 3: planets from bent space

The Galactic Bulge Time-Domain Survey watches the crowded centre of the Milky Way. It uses microlensing: when a star passes in front of a more distant one, its gravity bends the light like a natural magnifying glass. NASA expects it to find more than a thousand wide-orbit planets, plus free-floating planets that orbit no star. In its high-cadence seasons it samples every 12 minutes.

A test for finding Earth-like worlds

Roman also carries a Coronagraph, a technology demonstration that blocks a star's glare so fainter things next to it can be seen. Its deformable mirrors have more than 1,600 actuators, each commanded to better than 62 picometers.

What we do not know yet

NASA's recent updates do not say when the surveys will begin or how many supernovae it wany number you read elsewhere. My full article lists the sources, with a link for everyclaim:

Read the full article on Leo's Station

Image credit: NASA.

Microsoft started Project Silica to make a next-generation storage solution.

Leo — Thu, 18 Jun 2026 13:50:25 +0000

I think this is an interesting project and the future of storage. We wouldn't have to worry about how to maintain our data anymore, and it can be preserved there for thousands of years.

My thoughts: https://www.leostation.space/observatory/project-silica-the-next-generation-information-storage

DEV Community: Leo