Singleton mode ensures that a class will have only one instance, and will provide a global access point, especially for resource-sensitive objects. In the implementation of the multi-threaded environment to consider, you need to synchronize. In the Singleton4 implementation with double check lock, reduce the synchronization granularity, so that only the first (not more than two times) to request the instance will be synchronized, here, the reason for
double check is : Assume the thread P1, P2 all executed to the Pointa place, at this time P1 obtains the object lock, entered the synchronization block, then found that at this time uniqueinstance is indeed empty, so constructs an instance, exits the synchronization block, releases the lock, then P2 obtains the lock to enter the synchronization area, At this point, if you do not judge uniqueinstance non-empty again, you will build an instance again, thus no more singleton.
The code is as follows:
Package singleton;//Classic implementation, but in the multi-threaded environment will be problematic,//may even a thread at the same time into the Uniqueinstance==null control path public class Singleton {private Static Singleton uniqueinstance;private Singleton () {}//public static Singleton getinstance () {if (uniqueinstance = = NULL ) {//deferred instantiation, lazy uniqueinstance = new Singleton ();} return uniqueinstance;}}
Lock the method, synchronize the thread's call to it//But only the first execution of the getinstance, the real need to synchronize, the other is the loss of performance public class Singleton2 {private static Singleton2 Uniqueinstance;private Singleton2 () {}//need to synchronize public static synchronized Singleton2 getinstance () {if (uniqueinstance = = null) {uniqueinstance = new Singleton2 ();} return uniqueinstance;}}
Using "eager" to create an instance (a Hungry man), the JVM will always create this instance before it accesses the static variable, so it is thread safe. The disadvantage is not to create an instance when needed. public class Singleton3 {private static Singleton3 uniqueinstance = new Singleton3 ();p rivate Singleton3 () {}//directly uses public static Singleton3 getinstance () {return uniqueinstance;}}
Using double check lock, reduce the use of synchronization in the GetInstance method, only the first step public class Singleton4 {private static volatile Singleton4 uniqueinstance; Private Singleton4 () {}//reduced synchronization range public static synchronized Singleton4 getinstance () {if (uniqueinstance = = null) {//pointa Synchronized (Singleton4.class) {if (uniqueinstance = = null)//pointbuniqueinstance = new Singleton4 ();}} return uniqueinstance;}}
the singleton scenarios in the JDK are:(1) The GetRuntime in Java.lang.Runtime ();
public class Runtime { private static runtime currentruntime = new Runtime (); public static Runtime GetRuntime () { return currentruntime; } /** Don ' t let anyone else instantiate this class * /Private Runtime () {} ...).
(2) The Getdesktop in Java.awt.Desktop ();
public class Desktop { private desktoppeer peer; /** * Suppresses default constructor for Noninstantiability. */ Private Desktop () { peer = Toolkit.getdefaulttoolkit (). Createdesktoppeer (this); } public static synchronized Desktop Getdesktop () { if (graphicsenvironment.isheadless ()) throw new Headlessexception (); if (! Desktop.isdesktopsupported ()) { throw new Unsupportedoperationexception ("Desktop API is not" + "supported on The current platform "); } Sun.awt.AppContext context = Sun.awt.AppContext.getAppContext (); Desktop desktop = (desktop) context.get (desktop.class); if (desktop = = null) { desktop = new Desktop (); Context.put (Desktop.class, Desktop); } return desktop; }
Singleton mode (Singleton pattern)