Single-Case mode

Concept:
In Java, the singleton pattern is a common design pattern, there are several types of single-instance pattern, here are three kinds: lazy type single case, a hungry man type single case, registration 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 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;
}

2. Double check Lock

public static Singleton getinstance () {
if (singleton = = null) {
Synchronized (Singleton.class) {
if (singleton = = 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;
}
}
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 Singleton class. When class is initialized, it is self-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.

Three, registration of single case (can be ignored)
Similar to the method in spring, the class name is registered, the next time from the inside to get directly.
public class Singleton3 {
private static map<string,singleton3> Map = new hashmap<string,singleton3> ();
static{
Singleton3 single = new Singleton3 ();
Map.put (Single.getclass (). GetName (), single);
}
Default construction child for protection
Protected Singleton3 () {}
Static Factory method to return the unique instance of this type
public static Singleton3 getinstance (String name) {
if (name = = null) {
Name = Singleton3.class.getName ();
System.out.println ("name = = NULL" + "--->name=" +name);
}
if (map.get (name) = = null) {
try {
Map.put (name, (Singleton3) class.forname (name). newinstance ());
} catch (Instantiationexception e) {
E.printstacktrace ();
} catch (Illegalaccessexception e) {
E.printstacktrace ();
} catch (ClassNotFoundException e) {
E.printstacktrace ();
}
}
return Map.get (name);
}
A schematic business approach
Public String about () {
Return "Hello, I am Regsingleton.";
}
public static void Main (string[] args) {
Singleton3 single3 = singleton3.getinstance (null);
System.out.println (Single3.about ());
}
}
A registered singleton actually maintains an instance of a set of singleton classes that are stored in a map (the register), returned directly from the map for an instance that has already been registered, and then registered and returned, if not registered.
Here I marked the registration of the single example can be ignored, my understanding, first it uses less, in fact, the internal implementation is also used in the A Hungry man-type singleton, because of the static method block, its singleton is instantiated when the class is loaded.

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 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.
There are some differences between the three implementations of 1, 2 and 3,
1th, in the method call added synchronization, although thread security, but each time to synchronize, will affect performance, after all, 99% of the case is not required to synchronize,
2nd, two null checks were made in getinstance to ensure that only the first invocation of the singleton will be synchronized, which is also thread-safe, while avoiding the performance loss of each synchronization
3rd, using the ClassLoader mechanism to ensure that there is only one thread when initializing instance, so it is thread-safe, and there is no performance loss, so I tend to use this one.

What is thread safety?
If your code is in a process where multiple threads are running at the same time, these threads may run the code at the same time. If the result of each run is the same as the single-threaded run, and the value of the other variable is the same as expected, it is thread-safe.
Or, the interface provided by a class or program is atomic to the thread, or the switch between multiple threads does not result in ambiguity in the execution of the interface, that is, we do not have to consider the problem of synchronization, which is thread-safe.

Application
Here is an example of a singleton class using a lazy-like example, where a double-check lock is used to ensure thread safety:
public class Testsingleton {
String name = NULL;

Private Testsingleton () {
}

Private static volatile Testsingleton instance = null;

public static Testsingleton getinstance () {
if (instance = = null) {
Synchronized (Testsingleton.class) {
if (instance = = null) {
Instance = new Testsingleton ();
}
}
}
return instance;
}

Public String GetName () {
return name;
}

public void SetName (String name) {
THIS.name = name;
}

public void Printinfo () {
System.out.println ("The name is" + name);
}

}
You can see that the volatile keyword is added to declare a singleton object, since synchronized has played the role of atomic, ordered, and visible in multi-threaded, why should add volatile, for reasons already mentioned in the following comments,
There are questions to refer to http://www.iteye.com/topic/652440
and http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
public class Tmain {
public static void Main (string[] args) {
Teststream ts1 = Testsingleton.getinstance ();
Ts1.setname ("Jason");
Teststream ts2 = Testsingleton.getinstance ();
Ts2.setname ("0539");

Ts1.printinfo ();
Ts2.printinfo ();

if (ts1 = = ts2) {
System.out.println ("Created is the same instance");
}else{
System.out.println ("Not the same instance created");
}
}
}
Operation Result:

Conclusion: The result shows that the singleton pattern provides an object-only access point for an object-oriented application, and the entire application can enjoy an instance object regardless of the function it implements.
For a few implementations of the singleton pattern, know the difference between a hungry man and lazy, thread safety, the timing of resource loading, and the subtle differences in the 3 ways that the lazy type can be implemented for thread safety.

Single-Case mode