Java Common design pattern-Singleton mode

A singleton pattern for the Java Design Pattern series

Singleton pattern Definition

A class has and has only one instance, and self-instantiation is provided to the system as a whole.

Single-Case Mode action

Simply put, in the lifetime of the entire program, there is only one instance of the Singleton class at any one time (and of course you can have none).

How to guarantee the uniqueness of an object

Thought: (1) do not allow other programs to create such objects;

(2) Create the class object in this class;

(3) Create an externally available method that allows other classes to make calls.

Steps: (1) because the constructor is initialized when the object is created, the constructor of the class is privatized, and no other program can create the class object;

(2) The creation of such objects in this class;

(3) Define a method that returns the class object so that other classes can call this method (function: Controllable, the object is determined by itself, not who wants new on new).

We create an object ourselves directly in the class, and the Getsingle method is only responsible for returning the object to the caller, enabling the singleton to be controlled (you can get my method, but I can get the object I created myself)

The code reflects the way:

(1) Privatisation constructor (2) creates a private and static object of this class (3) creates a public static calling method that returns the object

There are two main ways of code implementation: a hungry man mode and full-han mode

A hungry man mode: When a class is loaded, the object is already in memory, is thread-safe, and when the class is created, it has created a static object for the system to use, and no longer changes. (Why is thread-safe, explained later)

Lazy mode: When the class is loaded, the object does not exist, it is called the lazy loading mode, when necessary to create the object, this mode if the object is created without synchronized will cause access to the object is not thread-safe (why is not thread-safe, explained later)

As explained below, the lazy thread is unsafe, usually we recommend writing a hungry man because it is thread-safe

When a thread accesses a lazy type, the lazy method will do multiple statements on the common data.

Two threads, thread 1 and thread 2, when thread 1 executes to sin null, the object is not created, thread 2 also executes to sin null and creates the object, at which point two threads create two objects, violating the principle of the singleton pattern.

Thread safety issues, in order to solve this problem, join the synchronization mechanism (not familiar with the synchronization mechanism Baidu): Static synchronization function lock is a class of bytecode file objects

Such a design can guarantee that only one instance is generated, and the synchronization lock will only be added at the time of initialization, but it can cause another problem, which is caused by the order reordering. (This part is from: http://blog.csdn.net/zhangzeyuaaa/article/details/42673245)

Order reordering is to optimize the command, improve the efficiency of program operation. Command reordering includes compiler reordering and run-time reordering. The JVM specification stipulates that order reordering can be performed without affecting the execution of single-threaded threads. For example instance = new Singleton () can be decomposed into the following pseudo-code:

Memory = allocate ();   1: Allocating the object's memory space ctorinstance;  2: Initialize object instance = memory;     3: Set instance to point to the memory address just allocated

However, after reordering, the following are:

Memory = allocate ();   1: Allocating the object's memory space instance = Memories;     3: Set instance to point to the memory address just allocated                       //Note that the object has not been initialized at this time! Ctorinstance (memory);  2: Initializing objects

The order of the 2nd and 3rd steps will not affect the results of the program execution in single-threaded cases, but it is not the same in multithreaded situations. Thread A executes instance = memory (which is visible to another thread B), at which point thread B executes the outer if (instance = = = null), finds that instance is not empty, and then returns, but gets an instance that is not fully initialized. There must be a risk when using it, which is the problem of double check lock!

After JDK1.5, you can use volatile variables to suppress command reordering:

Code implementation:

The reprint of this blog: http://www.cnblogs.com/ysw-go/

Java Common design pattern-Singleton mode