the singleton pattern is a design pattern that restricts the instantiation of a class to one object. This useful when exactly one object is needed to coordinate action across the system. (Singleton_pattern)
So How can we implement it?
For the simple implement:
public class Singleton { private static Singleton _instance = null; private Singleton() { } public static Singleton getInstance() { if (_instance == null) { _instance = new Singleton(); } return _instance; } }
if every time invoke the Singleton.getInstance() method, we always get the _instance in the all system, but this implementation has the problems? It's not the thread safe..
why?
So let show you:
when the TA(Thread A) enter getInstance(), because of _instance == null, So the _instance = new Singleton(), But when the TB(Thread B) also enter the getInstance() method at the same time, it also check the _instance == null (it's the null, because the TB and TA at the same time), so the _instance was created again.
The singleton pattern must be carefully constructed in multi-thread applications.
And I will provide the Java solutions for the thread safe:
1. Eager initialization
public class Singleton { private static Singleton _instance = new Singleton(); private Singleton() {} public static Singleton getInstance() { return _instance; } }
Why this is thread safe?
Because the _instance is the static variable, and Java guarantees that the initialization will be run before the code is accessed by ANY class.
Popular point that the _instance is constructed at the building time, so when the caller invoke getInstance() method, the _instance just at here, return is OK. NO multi-Thread problem.
But it has the "cost", if the cost of creating the instance is not too large in terms of time/resources, you can do, IF not, you may want to switch to lazy initialization.
2. Lazy initialization
why called the lazy? Because the instance will be created at the needed time, not like the Eager initialization, the instance created at building even if you not call the getInstance().
The Lazy initialization will avoid above situation(creating the instance is not too large in terms of time/resources)
public class Singleton { private static Singleton _instance = null; private Singleton() { } public static synchronized Singleton getInstance() { if (_instance == null) { _instance = new Singleton(); } return _instance; } }
Because the getInstance() is the synchronized, So anytime only one thread can enter this function. But it also has a problem: For the thread unsafe situation, just the first creation.
at if _instance != null, we are not needed to lock this function, if we add the synchronized in the method, we lock this function anytime.
So the double-checked locking is coming. it is a software design pattern used to reduce the overhead of acquiring a lock at the first testing the locking criterion without actually acquiring the lock.
So maybe you redesign this function:
public class Singleton { private static Singleton _instance = null; private Singleton() { } public static Singleton getInstance() {
if(_instance == null){
synchronized(this) {
if (_instance == null) { _instance = new Singleton(); }
}
} return _instance; } }
why the Double-check happened? Because when the Thread acquired the lock, but the another has done the initialization of the instance. So the Double-check happened.
But the subtle problems happened.
1. Thread A enter this function, notice the _instance is not initialized, so it obtains the lock and begins to initialize the _instance.
2.Due to the semantics of some programming languages, the code generated by the compiler is allowed to update the shared variable to point to partially constructed object.
Popular point that Before A as finished performing the initialization, the thread B enter this function, it check _instance != null(because java call the constructor, it will updated the _instance when the memory allocate, but it not call the construct function, just has the space. ) SO if thread B use the instance, maybe the program will crash.
the problem has been fixed, the volatile keyword now ensure that multiple threads handle the singleton instance correctly.
ublic class Singleton { private static volatile Singleton _instance = null; private Singleton() { } public static Singleton getInstance() {
if(_instance == null){
synchronized(this) {
if (_instance == null) { _instance = new Singleton(); }
}
} return _instance; } }
3. Initialization-on-demand holder idiom
First let us see the implemention
public class Singleton { // Private constructor prevents instantiation from other classes private Singleton() { } /** * SingletonHolder is loaded on the first execution of Singleton.getInstance() * or the first access to SingletonHolder.INSTANCE, not before. */ private static class SingletonHolder { public static final Singleton instance = new Singleton(); } public static Singleton getInstance() { return SingletonHolder.instance; } }
You may look this familiar, it looks like the eager initialization, but how this avoid the construct the large object.
Because it takes advantage of language guarantees about class initialization, so java don't construct the static inner class SingletonHodler at the building time. So the construction happen in the getInstance() function.
Since the class initialization phase is guaranteed by the JLS to be serial, and the initialization phase writes the static variable INSTANCE in a serial operation, so the JVM ensure SingletonHolder.instance is serial, is thread safe.
4. The Enum way
public enum Singleton { INSTANCE; public void execute (String arg) { //... perform operation here ... } }
the second edition of his book "Effective Java" Joshua Bloch claims that "a single-element enum type is the best way to implement a singleton"[10] for any Java that supports enums. The use of an enum is very easy to implement and has no drawbacks regarding serializable objects, which have to be circumvented in the other ways.
This approach implements the singleton by taking advantage of Java's guarantee that any enum value is instantiated only once in a Java program.Since Java enum values are globally accessible, so is the singleton. The drawback is that the enum type is somewhat inflexible. for examole, it dose not allow lazy initialization.
References Links:
http://regrecall.blogspot.com/2012/05/java-singleton-pattern-thread-safe.html
No comments:
Post a Comment