Singleton Mode)

The first mode I encountered in my work is the singleton mode. The Singleton mode is simple and easy to use, but it is very easy to abuse, especially in small systems.

Wiki explains the singleton mode in this way. I personally think it is very accurate.

Singleton Mode, Also calledList ModeIs a common software design model. When this mode is applied, the class of the singleton object must ensure that only one instance exists. In many cases, the whole system only needs to have one global object, which is conducive to coordinating the overall behavior of the system. For example, in a server program, the configuration information of the server is stored in a file, and the configuration data is read by a singleton object in a unified manner, other objects in the service process then obtain the configuration information through the singleton object. This method simplifies Configuration Management in complex environments.

The idea of implementing the singleton mode is: A class can return a reference (always the same) to an object and a method to obtain the instance (must be a static method, the getinstance name is usually used). When we call this method, if the reference held by the class is not empty, this reference is returned, if the reference of the class persistence is null, create an instance of the class and assign the instance reference to the reference of the class persistence. At the same time, we also define the constructor of the class as a private method, in this way, the code in other places cannot instantiate the object of this class by calling the constructor of this class. Only the static method provided by this class can be used to obtain the unique instance of this class.

The Singleton mode must be used with caution when multiple threads are used. If two threads call the creation method at the same time when the unique instance has not yet been created, they do not detect the existence of the unique instance at the same time, thus creating an instance at the same time, in this way, two instances are constructed, which violates the unique instance principle in the singleton mode.
The solution to this problem is to provide a mutex lock for the variables that indicate whether the class has been instantiated (although this will reduce the efficiency ).

In actual projects, I do this:

Implement a singleton template:

Template <typename T>
Class usingletontemplate
{
Public:
// Get the object.
Static T & getinstance ()
{
If (_ instance = NULL)
{

Project: Tools: scoped_lock <project: Tools: mutex> lock (mutex );
If (_ instance = NULL)
{
_ Instance = new T ();
Atexit (destroy );
}
}

Return * _ instance;
}

Protected:
Usingletontemplate (){};
// Destructor
~ Usingletontemplate (){};
PRIVATE:
// Constructor

Usingletontemplate (const usingletontemplate &);
Usingletontemplate & operator = (const usingletontemplate &);

Static void destroy ()
{
If (_ instance! = NULL)
{
Delete _ instance;
_ Instance = NULL;
}
}
// Data members
Static project: Tools: mutex;
Static T * volatile _ instance;
};

Template <typename T>
Project: Tools: mutex usingletontemplate <t >:: mutex;

Template <typename T>
T * volatile usingletontemplate <t>: _ instance = NULL;

Mutex self-encapsulated mutex semaphores. scopelock is a local automatic lock. It is locked during construction and released during schema analysis.

When defining a single class of a new template, you only need to inherit

Class A: Public usingletontemplate <A>

{

.......

}

In this case, Class A is the default Singleton.

The core implementation of Singleton is in the getsintance function. Many people have introduced the details in this article, mainly

This example uses the double yoke mechanism to ensure thread security.

For more details, see:

Http://calmness.iteye.com/blog/60179

I personally recommend that you do not need this mode. The main reasons are as follows:

1. The class creation and destructor time cannot be guaranteed, and you cannot guarantee the execution time of the destructor. This is a big challenge for the release of some resources.

2. multithreading can be avoided,

3. Easy to cause system design confusion. I personally think that the abuse of Singleton mode is an anti-pattern. Singleton classes are isolated from each other, which will affect

The relationship between classes in the system.