这两种单例实现之间有什么区别？

Question

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;
    }

Answer 1

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();

Answer 2

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()

Answer 3

There are two main differences:

1. 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.

2. 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.

Answer 4

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 _instance should be volatile?Let's see the following situation with no volatile ,there is two thread called thread1 and thread2 ,and they all call the method instance()`:

1. thread1 run at point 0 in above code
2. thread1 check the _instance is null and no one acquire the lock,so it can run at point 3
3. with the code _instance= new GameManager (); //3 _instance= new GameManager (); //3 ,because of the instruction reorder in Java Memory Model ,the JVM can break up the instruction order in 'interpreter or jit .Let's see what happened with that code.The instance has been constructed,the constructing instance is just be allocated memory(like the instruction new in JVM ,not in JAVA ),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);
4. 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