How do you create thread-safe Singleton in Java?

Question

Please give your answer with an example

Answer 1

https://www.geeksforgeeks.org/java-singleton-design-pattern-practices-examples/

Answer 2

You just need to synchronize the get method that returns your reference:

https://code.sololearn.com/cnIa16ff0Efw/?ref=app

Answer 3

Thanks guys have been following your comments and i really appreciate your answers and all the explanations.

Answer 4

Paul has a good implementation except that we shouldn't use the same object/class to synchronize over. We should have a private monitor that does that.

Answer 5

By pure curiosity Chriptus13, why wouldn't you use the same object for synchronization ?

Answer 6

Paul I posted that as a comment on your code 😄

Answer 7

Chriptus13 I see your point and agree that it would be safer. However, the added safety is limited since the point of making the Singleton thread safe was to not have to deal with synchronization when handling it thus it's unlikely you need/want to synchronize on it.
Also, if you want to use a monitor object, you can increase the speed by reducing the synchronized block (see FasterSingleton in the code).

Answer 8

Paul actually that has problems because you are reading shared state outside the synchronized block.
You could instead use AtomicReferences to prevent and optimize it.

Answer 9

Paul reference assignment is indeed atomic altrough thats not the only thing you are doing, you cannot forget the if check before that assignment. And since JVM doesn't garantee any instruction ordenation on multi thread code you cannot assume that no other thread can execute that assignment before the current one even though both had seen the if check true.

Answer 10

Chriptus13 I invite to look at the code again. What you mention would only happen if there was no null check before the assignment.

Even if two threads see _inst as a null reference with the first if, one will get the lock first on _mon and do the single instantiation then free _mon. Then the second thread will lock _mon and do nothing since _inst is not null anymore then release the lock. No double instantiation, everything is fine.

Answer 11

Paul oh I see, I'm sorry I must have made confusion!! Anyways it is not safe to split the reads/writes of shared state between synchronized and non synchronized blocks.
But also now I spot that you forget to remove the synchronized modifier on the method signature.

Answer 12

Chriptus13 oh thanks for the synchronized on the function.

For the read data outside a synchronized block, it depends on what you are trying to achieve this code is completely thread-safe (since the assignment is atomic) and will be a lot faster than the one where the synchronization is happening at every call.

I would agree that this would a bit too extreme for someone who is starting to learn java. But for someone a bit experienced who will understand what is happening and need a bit more speed, the second implementation is definitely the way to go.

Moreover, most of the time when doing multi-threading, it is a good thing to reduce the size of the synchronized code.

Answer 13

Chriptus13 AtomicReference only adds protection for the update of the reference (which is already protected by _mon)
The reference assignment is already atomic which means when I check for null outside the synchronized, it's either null or a valid reference (ref https://stackoverflow.com/questions/44283378/why-is-reference-assignment-atomic-in-java#44287276)

Thus, there is no data race possible when checking the equality with null and thus the code is fine