Java in a single case

In Java, the singleton pattern is a common design pattern, there are several types of single-case patterns, here are two types: lazy-type single case, a hungry man type single case

The singleton mode has the following characteristics:
　　1, the Singleton class can have only one instance.
　　2, the Singleton class must create its own unique instance.
　　3. The Singleton class must provide this instance to all other objects.
Singleton mode ensures that a class has only one instance, and instantiates itself and provides this instance to the entire system. In a computer system, the driver objects of the thread pool, cache, log Object, dialog box, printer, and video card are often designed as singleton. These apps have more or less the functionality of the resource manager. Each computer can have several printers, but only one printer Spooler to prevent both print jobs from being output to the printer at the same time. Each computer can have several communication ports, and the system should centrally manage these communication ports to prevent a communication port from being called simultaneously by two requests. In short, the selection of Singleton mode is to avoid inconsistent state, to avoid long-running political.

One, lazy type single case

Lazy Singleton class. Instantiate yourself when you first call the public    class Singleton {   private Singleton () {}   private static Singleton single= null;   Static Factory method Public    static Singleton getinstance () {   if (single = null) {Single     = new Singleton ();   }      return single;    }  }  

Lazy type Singleton class. Instantiate yourself at the first call

public class Singleton {    private Singleton () {}    private static Singleton single=null;    Static Factory method Public     static Singleton getinstance () {         if (single = null) {Single               = new Singleton ();         }          return single;    }}

Singleton by restricting the construction method to private to prevent the class from being instantiated externally, the unique instance of Singleton can only be accessed through the getinstance () method within the same virtual machine scope.

(In fact, the Java reflection mechanism is the ability to instantiate a class constructed as private, which basically invalidates all Java Singleton implementations.) This issue is not discussed here, and it is deceiving to assume that the reflection mechanism does not exist. ）

However, the above-mentioned lazy singleton implementation does not take into account the thread safety problem, it is thread insecure, the concurrency environment is likely to have multiple singleton instances, to achieve thread safety, there are the following three ways, is to getinstance this method of transformation, to ensure that the lazy single-case thread safety, If you first contact the singleton mode, the thread safety is not very understanding, you can skip the following three strips, to see the A hungry man-type singleton, and then look back to consider the issue of thread safety:

1, on the GetInstance method plus synchronization

public static synchronized Singleton getinstance () {           if (single = null) {Single                = new Singleton ();         }           return single;  

public static synchronized Singleton getinstance () {         if (single = null) {Single               = new Singleton ();         }          return single;}

2. Double check Lock

public static Singleton getinstance () {          if (Singleton = = null) {                synchronized (singleton.class) {                  if (singlet on = = null) {                     singleton = new Singleton ();}}           }           return singleton;      }

public static Singleton getinstance () {        if (Singleton = = null) {              synchronized (singleton.class) {                 if (sing Leton = = null) {                    singleton = new Singleton ();}}          }          return singleton;     }

3. Static internal class

public class Singleton {        private static class Lazyholder {           private static final Singleton INSTANCE = new Singleton ();        }       Private Singleton () {} public        static final Singleton getinstance () {           return lazyholder.instance;        }   }   

public class Singleton {      private static class Lazyholder {         private static final Singleton INSTANCE = new Singlet On ();      }      Private Singleton () {} public      static final Singleton getinstance () {         return lazyholder.instance;      }  }  

This is better than the above 1, 2, both for thread safety and to avoid the performance impact of synchronization.

Two, a hungry man type single case

A hungry man type Singleton class. At class initialization, you have instantiated public   class Singleton1 {      private Singleton1 () {}      private static final Singleton1 Single = new Singleton1 ();      Static Factory method Public       static Singleton1 getinstance () {          return single;      

A hungry man type Singleton class. At class initialization, you have instantiated public class Singleton1 {    private Singleton1 () {}    private static final Singleton1 Single = new Singleton1 ();    Static Factory method Public     static Singleton1 getinstance () {        return single;    }

A hungry man in the creation of a class at the same time has created a static object for the system to use, no longer change, so it is inherently thread-safe.

A hungry man and lazy-type difference

From the name of the A hungry man and the lazy,

A hungry man is the class once loaded, the singleton initialization is completed, to ensure that the getinstance, the singleton is already exist,

And the lazy idle, only when the call getinstance, only to go back to initialize the singleton

In addition differentiates the following two ways from the following two points:

1. Thread Safety:

A hungry man is inherently thread-safe and can be used directly for multithreading without problems.

The lazy type itself is non-thread-safe, in order to achieve thread safety there are several ways to write, respectively, the above 1, 2, 3, these three implementations in the resource load and performance of some differences.

2. Resource Loading and performance:

A hungry man a static object is instantiated at the same time as the class is created, and will occupy a certain amount of memory regardless of whether the singleton will be used later, but correspondingly, the speed will be faster on the first call because its resources have been initialized,

And the lazy type as the name implies, will delay loading, in the first use of the singleton when the object will be instantiated, the first call to do the initialization, if you want to do more work, performance will be somewhat delayed, and then the same as the A Hungry man type.

Java in a single case