When to use proper version of singleton thread-safe implementation?

Question

I have a stateless helper-like class which I want to make as a singleton. This class will be shared across different threads.

Am I correct that in this case (instance does not require huge memory allocation size and thus can be loaded several times without resources and performance impact) there is no need in implementing such a singleton with proper multi-threading lazy initialization strategy (Double Checked Locking & volatile, On Demand Holder idiom, Enum Singleton, Synchronized Accessor)?

Is it right to implement such a singleton with a simple non-multi-threading lazy initialization version strategy (like in the code below) in order to have less amount of boilerplate code?

public class Singleton {
    private static Singleton INSTANCE;

    private Singleton() {
    }

    public static Singleton getInstance() {
        if (INSTANCE == null) {
            INSTANCE = new Singleton();
        }
        return INSTANCE;
    }
}

And only in case when state of the singleton class shared across different threads it is required to add proper multi-threading version of a singleton initialization?

Atleast make the constructor private! And as far as your question is concerned it really depends on "How expensive your object is?". Using the above code in a good multithreaded environment can lead to the creation of many instances. — Ouney
Lazy developer pattern (I am too). There are small code templates; enum will not do out-of-the-box. You might also think of container managed persistence, like OSGi (=service oriented) or whatever if you have got several singletons. — Joop Eggen
you can remove the entire lazy init and put a static final initialization into the class, the instance will be available way before any code is able to call it - its initalized during the classloader-run and will never be ran twice except if you use dynamic loading and load/unload it in more than 1 place — specializt
I can't understand the reason why you don't want to use a On demand holder. This example from wiki, if you omit comments, is 1 line shorter than your approach, and better I think. en.wikipedia.org/wiki/… — Ezequiel

Alexander Torstling Alexander Torstling · Accepted Answer · 2015-05-28T11:51:38

If your class is entirely stateless - make it a util class with only static functions.

If you have state and want a semi-singleton I would say that what you have done is misleading since there is no way for the reader to know if you were aware of the fact that you can get multiple instances or not. If you decide to stick with your posted code - rename it multiton or document the behaviour carefully. But don't do it just to reduce boilerplate though - you are in fact creating more problems for the reader than you are removing.

In my opinion the "Initialization on Demand Holder" idiom is the nicest singleton pattern. But I would recommend against Singletons in general. You would be better off passing a reference to a shared instance to your thread when you start it.

When to use proper version of singleton thread-safe implementation?

2 Answers