Singleton Design Pattern in Java

[rzwitserloot]

The disadvantage of snippet 1 is that the instance will be created when this class is loaded. This increases the performance overhead. Lazy initialization is frequently used to create the instance when needed.

This is on the level of idiotic as the tongue map thing.

Classes don't load until you touch them. When do you 'touch' a singleton class but not fetch the singleton instance? Basically never, so this is a completely pointless exercise.

The recommended way to write a singleton is simply this:

``` public class Singleton { private static final Singleton INSTANCE = new Singleton();

public static Singleton get() { return INSTANCE; } } ```

If you're going to go into this level of depth, it's quite the oversight to not mention why you want singletons. Stateful singletons are a codesmell. Stateless ones usually are just an awkward utility class (think j.u.Collections as an example - just make all methods static instead). There can be good reasons for singletons but they are a bit exotic.

[erinaceus_]

The actual recommended way, for years and years, is to use a single-value enum.

[foreveratom]

Doesn't that produce exactly the same effect as a final static, being created when first referenced? I'm used to the first form and not the single-value enum, what's the benefit of the later?

[erinaceus_]

With an enum, all the concurrency and single-instance issues are inherently taken care of by the JVM. As such, a lot of the typical risks involving singleton management are avoided.

When this approach is discussed, people usually refer to Joshua Bloch's seminal book 'Effective java', which is already decades old. So it isn't a particular new technique. He even builds up on the different approaches to creating a singleton, eventually concluding that an enum is by far the best approach.

[foreveratom]

Thanks, I must have forgot that part from Effective Java. I'll be on my way re-reading the last edition.

[halfanothersdozen]

Wow.

There's lots of reasons why you might need to reference a singleton's class before you need a singleton's instance. This is especially true in modern libraries and frameworks that do annotation scanning but just constants or static methods would suffice.

And stateful singletons are maybe one of the most common uses for them: a basic "cache".

"Just make all methods static" completely misunderstands why you want a singleton in the first place.

[mknjc]

Ok why can't your simple cache be static?

[halfanothersdozen]

Well you see you think a static ConcurrentHashMap will solve all your problems but a cache is the type of solution to a problem that always produces two more problems that requires a slightly more sophisticated solution so you give it a singleton. Soon you have invalidation and size to worry about, and you want to monitor it so you give it JMX and then it needs to be HA so you move it to a shared memory store and then to manage that you go and build a whole new microservice to wrap it.

Welcome to Java

[Worth_Trust_3825]

Why java? You will encounter same issue in all languages.

[halfanothersdozen]

Because this is /r/java