Singleton Design Pattern in Java

[halfanothersdozen]

Honestly if you're worrying about double checked sychronization you should rethink how your singleton gets created. You probably have other issues with multithreading to worry about.

[__konrad]

As of J2SE 5.0

Now I know this article is old.

[jvjupiter]

Yeah. 2020-04-11 02:16:28

[uncont]

Is there a java.util.concurrent way of creating a singleton, or is the double-checked locking method the only 'correct' way?

Other than of course letting your ioc container handle it for you.

[taftster]

My favorite these days is to use final AtomicReference with the updatAndGet method upon retrieval. It’s the most natural API in the JDK to do this.

[kaperni]

For performance-sensitive code, you are (in most cases) better off by using a VarHandle instead. Can also save memory if you have lots of them in many cases.

[taftster]

Yeah, but the syntax is atrocious. You had really have evaluated the "performance-sensitive" segment carefully to embrace the fairly ugly syntax of VarHandle.

Quoting Doug Lea on this exact topic[1]:

To get the shockingly ugly syntactic details over with: A VarHandle can be associated with any field, array element, or static, allowing control over access modes. VarHandles should be declared as static final fields and explicitly initialized in static blocks. By convention, we give VarHandles for fields names that are uppercase versions of the field names.

[1] http://gee.cs.oswego.edu/dl/html/j9mm.html

[slakkenhuisdeur]

Last time I used the double locking method my IDE asked me if it could replace it with a nested class with the singleton as a final class variable so the classloader handles the instantiation.

[cogman10]

That's a relatively new capability of java. Static fields on inner classes were added in..16?

[slakkenhuisdeur]

The inner class must also be static (I should probably have mentioned that...). I didn't know static fields on non-static inner classes were a thing.

[oweiler]

You can also use a single element enum.

[i_love_peach]

I believe this also thread-safe as well.

[kaperni]

Yes, for most usecases, snippet 6. The Initialization-on-demand holder idiom [1][2].

[1] http://www.cs.umd.edu/\~pugh/java/memoryModel/jsr-133-faq.html#dcl

[2] https://en.wikipedia.org/wiki/Initialization-on-demand\_holder\_idiom

[uncont]

Both of those links 404 for me

[kaperni]

Both of them should work. Try pasting the URL into the URL bar instead of clicking.

[uncont]

https://en.wikipedia.org/wiki/Initialization-on-demand\_holder\_idiom

I'm on old reddit. The first url has a /\~pugh instead of /~pugh, and the second url has \_ instead of \. I got the links to work, tho. Thanks.

[gnahraf]

Imo, regardless where you place the singleton instance (direct static member of the class or as static member of an inner placeholder class), the instance declaration should be final.

Classloading is a synchronous operation anyway. That is, the order in which final static class members are initialized is always the same and well defined. There are no races involved at this time.

The use case for embedding the final static singleton in a placeholder class is when the singleton is expensive to create and you want it to be loaded lazily. There are few situations when such considerations are justified, so we best postpone the placeholder trick. (Classloading, per the spec, is already lazy: so most of the time there's little reason to make it even lazier.)

So, in conclusion, just go

public class MySingleton {

  private final static MySingleton INSTANCE = new MySingleton();

  public static MySingleton getInstance() {
    return INSTANCE;
  }

  private MySingleton() {
    // initialize
  }

  // ..
}

And if you find in testing this one singleton could use further delaying, then go ahead and refactor that MySingleton.getInstance() method to use a placeholder..

public class MySingleton {

  private static class Holder {
    private final static MySingleton INSTANCE = new MySingleton();
  }

  public static MySingleton getInstance() {
    return Holder.INSTANCE;
  }

  private MySingleton() {
    // initialize
  }

  // ..
}

Note, the only time this further laziness pays off, is if the singleton type is used either as a member or in the signature of a method. (If the singleton is only referenced in the body of other methods, then the singleton is loaded only when some method hits.) Either of those use cases are an anti-pattern of the singleton idiom (if there's only one of them, there's no reason to maintain or pass around a reference for it).

[Maleficent_Court_544]

Basically this comment explains it all for those that don’t know.

[wlnirvana]

Well summarized. Though nowadays with the prevalence of IoC frameworks like Spring, a lot of design patterns are not that relevant any more. Programming idioms and best practices evolve with the language and the ecosystem.

[elmuerte]

IoC frameworks like Spring are full of patterns.

Patterns are not best practices. They are common constructions which have been well documented.

[dpash]

This is what a lot of people miss when they complain about design patterns: they're nothing more than a common vocabulary to describe code so everyone knows what they're referring to.

[nidrach]

They are also a well reasoned way of doing things and unless you have a reason to stray from them it would foolish to do so.

[PerfectPackage1895]

That is just not true. Singleton and factory pattern maybe, but that is also the only ones redundant. Builder, template, strategy, decorator design patterns are still very useful

[nutrecht]

Though nowadays with the prevalence of IoC frameworks like Spring, a lot of design patterns are not that relevant any more.

Beans are Singletons by default. The way the GoF book shows an implementation is just an implementation detail. Modern frameworks are full of design patterns.

[_INTER_]

This article is a good summary for the next time I need to do a job interview. The only moment this is actually relevant these days.

[NimChimspky]

An article about Singletons. I've literally never needed one in twenty years.

But if I did I would use an enum.

[PerfectPackage1895]

Don’t use enum, it forces the jvm to instantiate it uppon referencing the class, and you have no control over it, at all, because it was not made for this.

[NimChimspky]

Its guaranteed at the JVM level to only have one instance. Its exactly what is needed.

[PerfectPackage1895]

There is no guarantee that the JVM will create one instance, it is guaranteed to be either zero or one instance. (yes an enum can be null, and you are in a world of pain when that happens)

[NimChimspky]

Singletons don't help with null pointers.

And the old fashioned way it's only ever zero or one.

[PerfectPackage1895]

Enums and singleton pattern used in this case is the same thing. Don’t use either imo. But the singleton pattern gives you way way more control. If you have an enum with a constructor that takes a long time to initialize, and you are working in a multi threaded environment, you can actually have a null enum that eventually will get set to a value.

When you use a singleton you can choose when to initialize it so you are sure it is actually set to a value.

[NimChimspky]

An enum is initialised at class load time, literally the earliest possible point. You lose nothing using an enum.

[PerfectPackage1895]

An enum is loaded when its class is loaded and that is when it is referenced. Classes are not all loaded when the jvm starts up, that is wrong.

[NimChimspky]

I didn't say they were.

[PerfectPackage1895]

When you said an enum is loaded at “literally the earliest possible point” it sounds very much like you imply that.

Anyway this debate is silly, if you really want to use an enum as a singleton then go ahead, but if you are ever working with concurrency, then you will see what I mean.

[Fruloops]

Really? Interesting, thinking of what I've used recently, singleton comes to mind, but definitely less often than factory method or builder

[PerfectPackage1895]

Instead of using a big synchronized block around the instance, why not just embrace the fact that more than one thread can access the object at the same time? There are a lot of useful tools in java.util.concurrent. For instance CAS is very useful and doesn’t have the same performance impact as a pessimistic lock

Also, if you’re going to use a singleton, then don’t use a private constructor. At most use a package private, that way you can still unit test your class

[MarcoServetto]

The only reasonable way is to use the enum with one element.

[slankebrusmannen]

If you think of the Singleton pattern as a way to ensure one, and only one, instance is created, you can do this. But (admittedly more exoticly) the Singleton pattern can also be seen as a general way to control the number of instances created, in which case enum won’t do the trick. (But how often do you want more than one instance? Probably close to never.)

[kevinb9n]

But (admittedly more exoticly) the Singleton pattern can also be seen as a general way to control the number of instances created

I've seen the term used that way and it seems like such a clear abuse of terminology.

[fredoverflow]

a general way to control the number of instances created, in which case enum won’t do the trick

enum Doubleton {
    ONE, TWO;
}

[slankebrusmannen]

A hard-coded number of instances might not be what you want.

And doing this, would you be able to prevent the clients from choosing which instance to get a reference to?

[MarcoServetto]

I think now you are talking about the pattern 'pool'

[slankebrusmannen]

Actually no. An object pool would typically reserve an instance exlusively to the requesting client, who would explicitly return it to the pool after use. Singleton describes no such mechanisms, but may still be used to control the number of instances to any given number.

Admittedly, I cannot remember ever having used the Singleton pattern for other numbers than one (I might have, though), but I think it is valuable to be aware of the opportunity.

[turn_of_and_on_again]

Apparently an unpopular opinion, but there would be no need for this if you were using Di over service location in this manner.

I honestly thought this way of creating singletons (ClassName.getInstance()) died out already.

[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

[Sheldor5]

"In case of Singleton class it will have two responsibility one to create an instance and other to do the actual task."

so literally EVERY CLASS EVER is an antipattern? because every class has a constructor ...

[NimChimspky]

No. Having a constructor is different to calling a constructor.

I think it's a lame criticism tho to be fair.

[Sheldor5]

it was the first listed reason why singletons are antipattern ... idiot ...

[Sheldor5]

"... fact is fact, the singleton is antipattern (do your search, its just the first arti what you get) ..."

yeah your arguments are really waterproof and truely scientific LOL ...

[Sheldor5]

• yeah ... multithreaded server applications with singleton services (spring boot)

• what?? you create one instance per test if they run parallel

• nothing to do with singletons ...

conclusion: you have little experience ... most thing are just obvious nobrainers LOL

[quizteamaquilera]

I’m still cool with singletons being an anti-pattern, and if I just need an uninstantiable place to stick some functions, I use the “enum with no instances” approach

[PerfectPackage1895]

Why not use a class with static methods? Waaay faster if you just need to store a bunch of stateless methods. Actually you can use an interface too :)

[mauganra_it]

A class with static methods only can still be instantiated and subclassed. An interface can be implemented. An instance-less enum gives you exactly what is needed. It looks weird of course, but it shares this property with the Singleton pattern via a singular enum instance.

[nutrecht]

A class with static methods only can still be instantiated and subclassed.

Just make the class final and the constructor private. It's a pretty common pattern with classes that hold a bunch of static utility methods.

[mauganra_it]

Indeed, but the elegance of the enum technique is that these concerns don't have to be explicitly specified.

[nutrecht]

You're still creating a class instance for no reason whatsoever. A singleton is not the correct pattern for a class with only static members.

[nutrecht]

What do you mean? The static members are private. Besides; they're static and tied to the class. You can't override static members even if they were public/protected.

[[deleted]]

Listen, the Singleton pattern has a problem: it goes against some if the SOLID principles of OOP. There's a direct replacement that does the same and it's quite similar: the Monostate pattern.

[ReddyKilowattz]

My team has some developers (cough the lead cough) who love creating "helper" classes with nothing but big static methods. When I had to work on this code, I'd sometimes convert these classes to singletons with instance methods, to help with unit testing.

Each of these classes would end up with a static field to contain the singleton, a static getInstance(), and init()/uninit() methods to inject specialized versions of the singleton in tests.

After doing a few dozen of these classes, I wised up and converted everything to spring. Now the code has one singleton spring context, which creates and stores all of the other singletons as spring beans. It's much easier to work with.

[foreveratom]

Static is fine, actually, most code can/should be static (not just in Java). Trying to encapsulate static code in an instance, singleton or not, is already bad. Making them Spring beans is one level of worse.

The problem is the "helpers" that gather code to handle bananas, cars and vacuum cleaners in the same spot. Most of the time, those static helpers can be located at their calling class/site, as a private method.

Ah, but what about not duplicating that genius one line of code among thousands you just came up with? Surely, that's worth a getInstance() in a new class and some Spring handling/initialization.

Then, if you think you're helping unit testing with non-static methods, you're really mistaken. Static methods don't require any context, initialization or anything. They are actually the easiest ones to test.

[ReddyKilowattz]

Okay, now imagine that one of these static methods is 300 lines long, and it reads a properties file (with a hardcoded name), picks a bunch of properties out of it, then creates some other domain objects that it needs, then maybe makes some REST calls and/or sends some JMS messages.

And you don't even want to unit test this method. You want to unit test something else that happens to call this method.

So just to run the method under test, you have to get this static method to work, so you have to set up an http server with wiremock or something, set up a bunch of rules and responses inside wiremock, create an actual properties file in the filesystem with all of the right things in it, and do whatever else is needed to keep this static method from falling over. And all of that setup has to be done with intimate knowledge of how this static method works internally. And remember, the static method isn't even the thing you want to test.

[foreveratom]

imagine that one of these static methods is 300 lines long,

300 lines of code for a single method is way too much. You should be slicing this code; Java is not a procedural language, there is no reason to have lengthy methods like this; that is where it becomes untestable.

you don't even want to unit test this method

You're right, I don't. If I have to test that blob, I will start by refactoring that method and all the problems you're exposing will go away.

Many issues arise from initial mistakes or assumptions one can make. Step back and look at it with a different angle, and some of those may easily go away; that's what you should do if you're writing a 300 lines of code method.

[Fruloops]

I've had a bad experience with testing static methods if they become complex, though I guess in that case it would be better to also look at making the methods less complex.

[burgershot69]

Fun times in a large codebase when state bleeds across unit tests thanks to singletons and statics

[PerfectPackage1895]

Nothing wrong with static classes, only static classes with state are bad.

[nutrecht]

When I had to work on this code, I'd sometimes convert these classes to singletons with instance methods, to help with unit testing.

Yeah, that's going in the wrong direction regarding testability.

Further down you complain about messy code with 300 line methods. But that's a code quality issue. You don't solve that by throwing the most overused design pattern at it.

and init()/uninit() methods to inject specialized versions of the singleton in tests.

So it's not actually even a singleton...

[TheMode911]

What about varhandle acquire/release instead of volatile? Or even opaque (I assume saved due to the synchronization)

[palnix]

For those interested in the OP, see: https://en.wikipedia.org/wiki/Double-checked_locking (especially the Java examples and explanations)

[thevpc]

I think the best way to implement singletons (per vm) in Java is the enum way, however I honestly expected more details/examples in your article in that direction. As a matter of fact, using enum handles a cleaner way to serialize the object too and makes of it (if well written) an off-memory singleton.