The Singleton Pattern in Java

Hey there! I’ve been trying to refresh my memory on design patterns, and I figured I’d start with something simple - The Singleton Pattern. Even though I already knew what it was, I realized it had been a while since I looked at the actual syntax. And let’s be honest, sometimes things that seem easy in theory can still trip us up when it’s time to code.

So here’s a quick, beginner-friendly post on the Singleton Pattern in Java. It’s the one you reach for when you need a single, shared instance of a class, like a logger that prints messages without spinning off into chaos. We’ll walk through what the pattern is, why it’s useful, when to use it, and how to implement it in Java using two thread-safe techniques. I’ll cover Double-Checked Locking using volatile and synchronized, and also the Initialization-on-Demand Holder Idiom, which is as cool as it sounds. Let’s get started!

---

What Is the Singleton Pattern?

The Singleton Pattern is a design pattern that:

• Guarantees a class has only one instance in your program.
• Provides a single, global access point to that instance.

Think of it like a single shared notebook for a team - everyone uses the same one, and no duplicates are created. Common uses in Java include loggers or database connections that should exist only once.

---

Why Use the Singleton Pattern?

The Singleton Pattern is awesome because it:

• Saves Resources: Avoids creating multiple heavy objects (e.g., database connections), keeping your program efficient.
• Ensures Consistency: All parts of your program use the same instance, preventing issues like writing to different log files.
• Simplifies Access: You can access the instance from anywhere without passing it around.

Caution: Overusing Singletons can make testing harder, so use them only when needed.

---

When to Use the Singleton Pattern

Use a Singleton when:

• You need one shared resource (e.g., a logger printing to the console).
• You’re managing a costly resource (e.g., a database connection).
• You want a single source for app-wide settings (e.g., user preferences).

Avoid it when:

• You might need multiple instances.
• The object isn’t a shared resource (e.g., a regular Car object).

---

How to Code a Singleton in Java

We’ll implement a Logger class that prints messages to the console, using two thread-safe approaches to ensure only one instance exists, even with multiple threads running simultaneously.

Approach 1: Double-Checked Locking with volatile and synchronized

This approach uses lazy initialization (creating the instance only when needed) and ensures thread safety with volatile and synchronized blocks.

public class Logger {
    // Volatile ensures threads see the correct instance
    private static volatile Logger INSTANCE;

    // Private constructor to prevent new instances
    private Logger() {
        if (INSTANCE != null) {
            throw new RuntimeException("Use getInstance() to get the Logger!");
        }
    }

    // Method to get the single instance
    public static Logger getInstance() {
        if (INSTANCE == null) { // First check (no lock)
            synchronized (Logger.class) { // Lock for thread safety
                if (INSTANCE == null) { // Second check (with lock)
                    INSTANCE = new Logger();
                }
            }
        }
        return INSTANCE;
    }

    // Method to log messages
    public void log(String message) {
        System.out.println("Log: " + message);
    }
}

Why It Works

• Private Constructor: Prevents creating new Logger objects with new. The check inside blocks tricks like reflection.
• Lazy Initialization: The Logger is created only when getInstance() is called, saving resources if unused.
• Thread Safety:
  • The synchronized block ensures only one thread creates the instance.
  • The double if (INSTANCE == null) checks improve performance by avoiding locks after the instance is created.
• Singleton Guarantee: The checks and lock ensure only one Logger is created.

The volatile Keyword

The volatile keyword is critical for thread safety:

• Visibility: Ensures all threads see the latest value of INSTANCE by writing directly to main memory.
• No Reordering: Guarantees the Logger is fully initialized before INSTANCE is set, preventing threads from accessing a partially created object.

Without volatile, a thread might see a non-null INSTANCE that isn’t fully initialized due to Java’s memory optimizations.

---

Approach 2: Initialization-on-Demand Holder Idiom

This simpler approach uses Java’s class loading for lazy initialization and thread safety, without needing volatile or synchronized.

public class Logger {
    // Private constructor to prevent new instances
    private Logger() {
        if (Holder.INSTANCE != null) {
            throw new RuntimeException("Use getInstance() to get the Logger!");
        }
    }

    // Static inner class to hold the instance
    private static class Holder {
        private static final Logger INSTANCE = new Logger();
    }

    // Method to get the single instance
    public static Logger getInstance() {
        return Holder.INSTANCE;
    }

    // Method to log messages
    public void log(String message) {
        System.out.println("Log: " + message);
    }
}

Why It Works

• Private Constructor: Prevents new Logger objects and blocks reflection-based creation.
• Lazy Initialization: The Holder class loads only when getInstance() references Holder.INSTANCE, delaying Logger creation until needed.
• Thread Safety: Java’s class loading (per Java Language Specification 12.4.2) locks the Holder class during initialization, ensuring one instance. Since inner class is loaded only when it’s explicitly called, Holder.INSTANCE is initialized when getInstance() is called explicitly the first time. When a class is initialized, the JVM uses a per-class lock (tied to the class’s Class object) to ensure that initialization happens exactly once, even if multiple threads try to trigger it simultaneously.
• Singleton Guarantee: The static final INSTANCE is set once during Holder loading and can’t be changed.

Importance of static and final

• Static: Ensures INSTANCE belongs to the Holder class, maintaining one shared Logger.
• Final: Prevents reassigning INSTANCE, preserving the Singleton.

What If static or final Is Removed?

• Without static: Each Holder object creates a new Logger, breaking the Singleton.
• Without final: INSTANCE could be reassigned, allowing new Logger objects.
• Without both: Multiple, reassignable Logger objects could exist, defeating the Singleton purpose.

Why No volatile?

Java’s class loading ensures visibility and proper initialization, making volatile unnecessary.

---

Using the Singleton

Here’s how to use either Logger implementation:

public class Main {
    public static void main(String[] args) {
        Logger logger1 = Logger.getInstance();
        Logger logger2 = Logger.getInstance();

        logger1.log("Hello, world!");
        logger2.log("This is a test!");

        System.out.println("Same instance? " + (logger1 == logger2));
    }
}

Output:

Log: Hello, world!
Log: This is a test!
Same instance? true

Both logger1 and logger2 refer to the same Logger, confirming the Singleton works.

---

Testing Thread Safety

To verify thread safety:

public class LoggerTest {
    public static void main(String[] args) {
        Runnable task = () -> {
            Logger logger = Logger.getInstance();
            System.out.println(Thread.currentThread().getName() + " got Logger: " + logger.hashCode());
        };

        Thread thread1 = new Thread(task, "Thread-1");
        Thread thread2 = new Thread(task, "Thread-2");
        thread1.start();
        thread2.start();
    }
}

Output (hash codes may vary):

Thread-1 got Logger: 123456789
Thread-2 got Logger: 123456789

Both threads access the same Logger, proving thread safety for both approaches.

---

Which Approach to Choose?

• Double-Checked Locking:
  • Demonstrates volatile and synchronized for thread safety.
  • More complex, but useful for learning or specific cases.
• Initialization-on-Demand Holder Idiom:
  • Simpler, cleaner, and leverages Java’s class loading.
  • Recommended for beginners due to its reliability and less error-prone design.

The Holder Idiom is typically the better choice for its simplicity and robustness.

---

Tips for Using Singletons

• Use Sparingly: Singletons are great for shared resources, but overuse complicates testing.
• Protect the Constructor: Use a private constructor with a check to prevent extra instances.
• Test Thoroughly: Verify the Singleton in various scenarios to ensure it remains unique.

---

Conclusion

The Singleton Pattern is ideal for creating unique, shared objects in Java, like our Logger. The Double-Checked Locking approach uses volatile and synchronized for thread-safe lazy initialization, with volatile ensuring proper visibility and initialization. The Initialization-on-Demand Holder Idiom is simpler, relying on Java’s class loading for the same guarantees without extra keywords. Both methods ensure a single, thread-safe instance. Happy coding!

---