Develop Reference

What is the difference between these two implementation of singleton?

I am having problem to understand the difference between these two function. Aren't they both implementing singleton? If so whats the benefit over one another.
private static GameManager instance = new GameManager();
public static GameManager get(){return instance;}
and the bellow,
private static GameManager _instance;
public static GameManager instance(){
if(_instance == null) _instance = new GameManager();
return _instance;
}

There are two main differences:
The first example is "eager", and the second one is "lazy". Specifically, the first one will create the singleton object as soon as the singleton class is initialized, but the second one will create the singleton object when instance() is called the first time.
Generally speaking, eager initialization is simpler. However, it may be the case that initialization may depend on other things, and lazy initialization provides a way to defer the initialization until they have happened.
The second example has an insidious problem if two or more threads can call instance() simultaneously. Specifically, the two threads might get different GameManager objects.
The analogous problem in the first example is that one thread might see a null if there is an issue with class initialization cycles in the application. That could lead to one thread seeing a null value. However, the semantics of class initialization mean that there is a happens-before relation between class initialization and calling a method on the initialized class. Therefore, both threads are guaranteed to see the correct initial state for the GameManager object.
But note that the "double checked lock" example is only correct for Java 5 and later.
If there are multiple threads sharing the GameManager instance, it is most likely necessary to do other things to get the application to (always) behave correctly.

The difference is that the second implementation is no good in multi-threaded environment because it may create more than one instance. This is when two threads check if instance == null at the same time and both get true
Note that option #1 can also be lazy:
class GameManager {
private static GameManager instance = new GameManager();
private GameManager() {
System.out.println("instance created");
}
public static GameManager getInstance() {
return instance;
}
}
Try to use it and you will see that instance is created only when we first call getInstance()

They are both implemented as singleton. The only difference is that the Singleton instance is Lazy Loaded on the second code block. In other words, it won't initialize the GameManager until instance method is called.
You should also probably rewrite your code to something simpler such as:
public static GameManager instance = new GameManager();

The first implementation is more safely than other one implementation in multiple processor.Following rule guarantee why first implementation is safely.
Because the JLS 17.4.5 Happens-before Order define one rule:
The default initialization of any object happens-before any other actions (other
than default-writes) of a program.
so the instance field is initialized fully when someone call the method get().
The second implementation is called lazy initialization,but it is not correctly in your code.In order to staring program faster,using the lazy initialization is a good practice if the initialization of GameManager spend more time.
With second implementation,there is two approach which can make the GameManager thread safe.
The first,you can make the method instance synchronized,just like this:
public synchronized static GameManager instance(){
if(_instance == null) _instance = new GameManager();
return _instance;
}
But it is not high performance,because every call will be synchronized with that method in multiple thread.
The second,you can use double-check in the method instance,and declare the _instance as volatile,the following code:
static volatile GameManager _instance;
public static GameManager instance(){
if (_instance== null) { //0
synchronized(GameManager.class) { //1
if (_instance == null) //2
_instance= new GameManager (); //3
}
}
return o;
}
This implementation code is correctly and high performance.
Why the field_instanceshould be volatile?Let's see the following situation with novolatile,there is two thread calledthread1andthread2,and they all call the methodinstance()`:
thread1 run at point 0 in above code
thread1 check the _instance is null and no one acquire the lock,so it can run at point 3
with the code _instance= new GameManager (); //3 ,because of the instruction reorder in Java Memory Model,the JVM can break up the instruction order in 'interpreterorjit.Let's see what happened with that code.The instance has been constructed,the constructing instance is just be allocated memory(like the instructionnewinJVM,not inJAVA),and then assign to the field_instance`,but notice the instance is not initialize completely(for example,not initialize field with default value,or call static construct method);
The thread2 run at point 0,and check the _instance is not null,so it will return the _instance which is not initialize fully,and the instance is not
trustworthy.
If the _instance is volatile,the volatile can guarantee the _instance initialize fully when someone read it.See the 17.4.5 Happens-before Order,there is one rule:
A write to a volatile field (§8.3.1.4) happens-before every subsequent read of
that field.t

Is there any need to add volatile keyword to guarantee thread-safe singleton class in java?

According to this post, the thread-safe singleton class should look as below. But I'm wondering whether there's a need to add volatile keyword to static CrunchifySingleton instance variable. Since if the instance is created and stored in CPU cache, at which time it is not written back to main memory, meanwhile, another thread invoke on getInstance() method. Will it incur an inconsistency problem?
public class CrunchifySingleton {
private static CrunchifySingleton instance = null;
protected CrunchifySingleton() {
}
// Lazy Initialization
public static CrunchifySingleton getInstance() {
if (instance == null) {
synchronized (CrunchifySingleton.class) {
if (instance == null) {
instance = new CrunchifySingleton();
}
}
}
return instance;
}
}

I echo #duffymo's comment above: lazy singletons are nowhere near as useful as they initially appear.
However, if you absolutely must use a lazily-instantiated singleton, the lazy holder idiom is much a easier way to achieve thread safety:
public final class CrunchifySingleton {
private static class Holder {
private static final CrunchifySingleton INSTANCE = new CrunchifySingleton();
}
private CrunchifySingleton() {}
static CrunchifySingleton getInstance() { return Holder.INSTANCE; }
}
Also, note that to be truly singleton, the class needs to prohibit both instantiation and subclassing - the constructor needs to be private, and the class needs to be final, respectively.

Yep, if your Singleton instance is not volatile or even if it is volatile but you are using sufficiently old JVM, there's no ordering guarantees for the operations in which the line
instance = new CrunchifySingleton();
decomposes with regard to the volatile store.
The compiler can then reorder these operations so that your instance is not null (because memory has been allocated), but is still uninitialized (because its constructor still hasn't been executed).
If you want to read more about the hidden problems around Double-Checked Locking, specifically in Java, see The "Double-Checked Locking is Broken" Declaration.
The lazy holder idiom is a nice pattern that generalizes well for general static field lazy loading, but if you need a safe and simple Singleton pattern, I'd recommend what Josh Bloch (from Effective Java fame) recommends - the Java Enum Singleton:
public enum Elvis {
INSTANCE;
public void leaveTheBuilding() { ... }
}

The code how you quoted it is broken in Java. Yes, you need volatile and at least Java 5 to make the double-checked idiom thread safe. And you should also add a local variable in your lazy initialization to improve performance. Read more about it here: https://en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java

Yes, making volatile will gaurantee that every time any thread is trying to access your critical section of code, the thread reads the data from memory itself and not from hread cache.

You need volatile in this case but a better option is to use either an enum if it is stateless
enum Singleton {
INSTANCE;
}
however stateful singletons should be avoid every possible. I suggest you try creating an instance which you pass via dependency injection.

How make a synchronized Singleton design pattern in Java?

I have gone through a singleton design pattern in Java which is below mentioned. I am having trouble to understand how does the Synchronized keyword in the public static getter or accessor method prevent more than one object creation ?
If at all it is being called twice from two different classes Synchronized should make their calls Synchronized i.e. one after the other . How does it govern only one object creation?
Please explain in details and also check the comments if my assumptions about the modifiers are correct or not
class MySingleton
{
private static MySingleton singletonObj; //as it is private it cannot be referenced outside of this class
//and as it is static all the instances of this class share the same copy of this refrence variable
private MySingleton()
{
System.out.println("Welcome to a singleton design pattern");
System.out.println("Objects cannot be instantiated outside of this class");
}
public static synchronized MySingleton getASingletonObject()
{
if(singletonObj==null)
{
singletonObj=new MySingleton();
}
return singletonObj;
}
}
Help is much appreciated :)
Thanks

Your question is about the way it works: You have one instance not because of the synchronized, but because it is stored in a static variable, and is instancied only one time (with a lazy creation - checked by the if).
The synchronized ensure you that only one Thread will instanciate the object, and avoid a bug where many Threads could create duplicates.
Here is the other way to implement it, and i find it more simple, and as efficient:
public class Singleton
private static final Singleton instance=new Singleton();
private Singleton(){
}
public static Singleton getInstance(){
return instance;
}
}
Note: the only condition for using this kind of implementation is that your constructor (the new) should not throw any exception, and should only contain simple code like variable initialisation.

The purpose of the Singleton class is that there is at most one instance of it and, hence, all threads access that same object.
Supposing there are 'n' threads trying to access the getASingletonObject method.
Case I:If we don't synchronize the getASingletonObject method the following could happen:
1) Thread1 enters getASingletonObject()
2) Thread2 enters getASingletonObject()
3) Thread1 evaluates singletonObj == null to true
4) Thread2 evaluates singletonObj == null to true
5) Thread1 assigns singletonObj and returns
6) Thread2 *re*assigns singletonObj = new Singleton() and returns.
Now the threads both have a difference instance of the Singleton class which is what should have been prevented by this pattern.
Synchronizing prevents that both Threads can access the same block of code at the same time. So synchronization is needed in a multithreaded environment when you instantiate singleton classes.
Now assuming that multple threads will attempt to access the Singletons methods at the same time synchronization might be neccessary on those methods as well. Especially if they change data instead of only reading it this is true.

You´re not implementing correctly Singleton patter look my implementation.
class MySingleton
{
private MySingleton instance; //You dont need that you instance be static, inside your class you have all the access of the Instance once you call getInstance()
public static MySingleton getInstance(){
return instance;
}
private MySingleton()
{
System.out.println("Welcome to a singleton design pattern");
System.out.println("Objects cannot be instantiated outside of this class");
}
public static synchronized MySingleton getASingletonObject()
{
if(instance==null)
{
instance=new MySingleton();
}
return instance;
}
}
//About the synchronized you have to understand that is like a lock, where every time a thread is getting inside he is closing the method so nobody else can be inside and then there´s no possible that when a thread is in the line instance=new MySingleton(); but has not being executed for the VM another thread would be in if(instance==null) asking the VM and returning true.
As soon as the first tread is out of the method the lock is open and then other threads can get in. And then they will see that the instance is already created.

The synchronized keyword protects the singleton member variable (singletonObj in this case) from multithreaded access. This ensures that even if multiple threads are trying to create an object, only one is still being used.
Check this article: http://www.javaworld.com/article/2073352/core-java/simply-singleton.html for more explanation.

Wikipedia says:
In software engineering, the singleton pattern is a design pattern
that restricts the instantiation of a class to one object.
So you create singletonObj only one-time because when you call getASingletonObject() you check is singletonObj == null and if it's null, so you create a new object, if it's not null you get 'singletonObj' created before.
public static synchronized gives you confidence that this object have been created once, because static says that singletonObj have been created once for class, but not for concrete instance of object. And synchronized provides a concurrent access to getASingletonObject() and it's give you confidence that object singletonObj couldn't be created twice when different threads call your method simultaneously.

Singleton instantiated with double-checked blocking method

I have a question about this instantiation method:
From this web site it says:
class Singleton
{
private static Singleton instance;
private Singleton()
{
System.out.println("Singleton(): Initializing Instance");
}
public static Singleton getInstance()
{
if (instance == null)
{
synchronized(Singleton.class)
{
if (instance == null)
{
System.out.println("getInstance(): First time getInstance was invoked!");
instance = new Singleton();
}
}
}
return instance;
}
public void doSomething()
{
System.out.println("doSomething(): Singleton does something!");
}
}
However from the book "Head First Design Pattern" by Elisabeth Freeman, Eric Freeman, Bert Bates, Kathy Sierra, Elisabeth Robson, they instantiate the Singleton using the same method, with the only difference that they declare the private static member as volatile and they rim the point quite a bit about declaring it volatile. Should not be enough declaring the "critical zone" synchronized in order to establish the proper "happnens-before relationship" between threads?

As per the defininition, using volatile variables reduces the risk of memory consistency errors, because any write to a volatile variable establishes a happens-before relationship with subsequent reads of that same variable.
The problem is that an out-of-order write may allow the instance reference to be returned before the Singleton constructor is executed.
Thread A notices that the value is not initialized, so it obtains the lock and begins to initialize the value.
Due to the semantics of programming languages, the code generated by the compiler is allowed to update the shared variable to point to a partially constructed object before A has finished performing the initialization. For example, in Java if a call to a constructor has been inlined then the shared variable may immediately be updated once the storage has been allocated but before the inlined constructor initializes the object.
Thread B notices that the shared variable has been initialized (or so it appears), and returns its value. Because thread B believes the value is already initialized, it does not acquire the lock. If B uses the object before all of the initialization done by A is seen by B (either because A has not finished initializing it or because some of the initialized values in the object have not yet percolated to the memory B uses (cache coherence)), the program will likely crash.
Read this wiki for a clear explanation of things: http://en.wikipedia.org/wiki/Double_checked_locking_pattern#Usage_in_Java

Singleton instantiation

Below show is the creation on the singleton object.
public class Map_en_US extends mapTree {
private static Map_en_US m_instance;
private Map_en_US() {}
static{
m_instance = new Map_en_US();
m_instance.init();
}
public static Map_en_US getInstance(){
return m_instance;
}
#Override
protected void init() {
//some code;
}
}
My question is what is the reason for using a static block for instantiating. i am familiar with below form of instantiation of the singleton.
public static Map_en_US getInstance(){
if(m_instance==null)
m_instance = new Map_en_US();
}

The reason is thread safety.
The form you said you are familiar with has the potential of initializing the singleton a large number of times. Moreover, even after it has been initialized multiple times, future calls to getInstance() by different threads might return different instances! Also, one thread might see a partially-initialized singleton instance! (let's say the constructor connects to a DB and authenticates; one thread might be able to get a reference to the singleton before the authentication happens, even if it is done in the constructor!)
There are some difficulties when dealing with threads:
Concurrency: they have to potential to execute concurrently;
Visibility: modifications to the memory made by one thread might not be visible to other threads;
Reordering: the order in which the code is executed cannot be predicted, which can lead to very strange results.
You should study about these difficulties to understand precisely why those odd behaviors are perfectly legal in the JVM, why they are actually good, and how to protect from them.
The static block is guaranteed, by the JVM, to be executed only once (unless you load and initialize the class using different ClassLoaders, but the details are beyond the scope of this question, I'd say), and by one thread only, and the results of it are guaranteed to be visible to every other thread.
That's why you should initialize the singleton on the static block.
My preferred pattern: thread-safe and lazy
The pattern above will instantiate the singleton on the first time the execution sees a reference to the class Map_en_US (actually, only a reference to the class itself will load it, but might not yet initialize it; for more details, check the reference). Maybe you don't want that. Maybe you want the singleton to be initialized only on the first call to Map_en_US.getInstance() (just as the pattern you said you are familiar with supposedly does).
If that's what you want, you can use the following pattern:
public class Singleton {
private Singleton() { ... }
private static class SingletonHolder {
private static final Singleton instance = new Singleton();
}
public static Singleton getInstance() {
return SingletonHolder.instance;
}
}
In the code above, the singleton will only be instantiated when the class SingletonHolder is initialized. This will happen only once (unless, as I said before, you are using multiple ClassLoaders), the code will be executed by only one thread, the results will have no visibility problems, and the initialization will occur only on the first reference to SingletonHolder, which happens inside the getInstance() method. This is the pattern I use most often when I need a singleton.
Another patterns...
1. synchronized getInstace()
As discussed in the comments to this answer, there's another way to implement the singleton in a thread safe manner, and which is almost the same as the (broken) one you are familiar with:
public class Singleton {
private static Singleton instance;
public static synchronized getInstance() {
if (instance == null)
instance = new Singleton();
}
}
The code above is guaranteed, by the memory model, to be thread safe. The JVM specification states the following (in a more cryptic way): let L be the lock of any object, let T1 and T2 be two threads. The release of L by T1 happens-before the acquisition of L by T2.
This means that every thing that has been done by T1 before releasing the lock will be visible to every other thread after they acquire the same lock.
So, suppose T1 is the first thread that entered the getInstance() method. Until it has finished, no other thread will be able to enter the same method (since it is synchronized). It will see that instance is null, will instantiate a Singleton and store it in the field. It will then release the lock and return the instance.
Then, T2, which was waiting for the lock, will be able to acquire it and enter the method. Since it acquired the same lock that T1 just released, T2 will see that the field instance contains the exact same instance of Singleton created by T1, and will simply return it. What is more, the initialization of the singleton, which has been done by T1, happened before the release of the lock by T1, which happened before the acquisition of the lock by T2, therefore there's no way T2 can see a partially-initialized singleton.
The code above is perfectly correct. The only problem is that the access to the singleton will be serialized. If it happens a lot, it will reduce the scalability of your application. That's why I prefer the SingletonHolder pattern I showed above: access to the singleton will be truly concurrent, without the need for synchronization!
2. Double checked locking (DCL)
Often, people are scared about the cost of lock acquisition. I've read that nowadays it is not that relevant for most applications. The real problem with lock acquisition is that it hurts scalability by serializing access to the synchronized block.
Someone devised an ingenuous way to avoid acquiring a lock, and it has been called double-checked locking. The problem is that most implementations are broken. That is, most implementations are not thread-safe (ie, are as thread-unsafe as the getInstace() method on the original question).
The correct way to implement the DCL is as follows:
public class Singleton {
private static volatile Singleton instance;
public static Singleton getInstance() {
if (instance == null) {
synchronized {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
The difference between this correct and an incorrect implementation is the volatile keyword.
To understand why, let T1 and T2 be two threads. Let's first assume that the field is not volatile.
T1 enters the getInstace() method. It's the first one to ever enter it, so the field is null. It then enters the synchronized block, then the second if. It also evaluates to true, so T1 creates a new instance of the singleton and stores it in the field. The lock is then release, and the singleton is returned. For this thread, it is guaranteed that the Singleton is completely initialized.
Now, T2 enters the getInstace() method. It is possible (although not guaranteed) that it will see that instance != null. It will then skip the if block (and so it will never acquire the lock), and will directly return the instance of the Singleton. Due to reordering, it is possible that T2 will not see all the initialization performed by the Singleton in its constructor! Revisiting the db connection singleton example, T2 might see a connected but not yet authenticated singleton!
For more information...
... I'd recommend a brilliant book, Java Concurrency in Practice, and also, the Java Language Specification.

If you initialize in the getInstance() method, you can get a racing conditions, i.e. if 2 threads execute the if(m_instance == null) check simulataneously, both might see the instance be null and thus both might call m_instance = new Map_en_US();
Since the static initializer block is executed only once (by one thread that is executing the class loader), you don't have a problem there.
Here's a good overview.

How about this approach for eradicating the static block:
private static Map_en_US s_instance = new Map_en_US() {{init();}};
It does the same thing, but is way neater.
Explanation of this syntax:
The outer set of braces creates an anonymous class.
The inner set of braces is called an "instance block" - it fires during construction.
This syntax is often incorrectly called the "double brace initializer" syntax, usually by those who don't understand what is going on.
Also, note:
m_ is a naming convention prefix for instance (ie member) fields.
s_ is a naming convention prefix for class (ie static) fields.
So I changed the name of the field to s_....

It depends on how resource-intensive the init method is. If it e.g. does a lot of work, maybe you want that work done at the startup of the application instead of on the first call. Maybe it downloads the map from Internet? I don't know...

The static block is executed when the class is first loaded by the JVM. As Bruno said, that helps with thread safety because there isn't a possibility that two threads will fight over the same getInstance() call for the first time.

With static instantiation there will be only one copy of the instance per class irrespective of how many objects being created.
Second advantage with the way is, The method is thread-safeas you are not doing anything in the method except returning the instance.

the static block instances your class and call the default contructor (if any) only one time and when the application starts and all static elements are loaded by the JVM.
Using the getInstance() method the object for the class is builded and initialized when the method is called and not on the static initialization. And is not really safe if you are running the getInstance() in diferent threads at the same time.

static block is here to allow for init invocation. Other way to code it could be eg like this (which to prefer is a matter of taste)
public class Map_en_US extends mapTree {
private static
/* thread safe without final,
see VM spec 2nd ed 2.17.15 */
Map_en_US m_instance = createAndInit();
private Map_en_US() {}
public static Map_en_US getInstance(){
return m_instance;
}
#Override
protected void init() {
//some code;
}
private static Map_en_US createAndInit() {
final Map_en_US tmp = new Map_en_US();
tmp.init();
return tmp;
}
}
update corrected per VM spec 2.17.5, details in comments

// Best way to implement the singleton class in java
package com.vsspl.test1;
class STest {
private static STest ob= null;
private STest(){
System.out.println("private constructor");
}
public static STest create(){
if(ob==null)
ob = new STest();
return ob;
}
public Object clone(){
STest obb = create();
return obb;
}
}
public class SingletonTest {
public static void main(String[] args) {
STest ob1 = STest.create();
STest ob2 = STest.create();
STest ob3 = STest.create();
System.out.println("obj1 " + ob1.hashCode());
System.out.println("obj2 " + ob2.hashCode());
System.out.println("obj3 " + ob3.hashCode());
STest ob4 = (STest) ob3.clone();
STest ob5 = (STest) ob2.clone();
System.out.println("obj4 " + ob4.hashCode());
System.out.println("obj5 " + ob5.hashCode());
}
}
-------------------------------- OUT PUT -------------------------------------
private constructor
obj1 1169863946
obj2 1169863946
obj3 1169863946
obj4 1169863946
obj5 1169863946

Interesting never seen that before. Seems largely a style preference. I suppose one difference is: the static initialisation takes place at VM startup, rather than on first request for an instance, potentially eliminating an issue with concurrent instantiations? (Which can also be handled with synchronized getInstance() method declaration)