Singleton in Design Mode)

Single-state Definition:
The Singleton mode ensures that only one instance of a Class exists in a Java application.

In many operations, such as creating a directory database connection, such single-threaded operations are required.

In addition, singleton can be stateful. In this way, multiple single-State classes can serve as a status warehouse together. For example, if you want a Post Counter in the Forum, you need to count every time you browse. Can single-State classes maintain this count and automatically add 1 to synchronize's security? If you want to save this number to the database permanently, you can easily do this without modifying the single-State interface.

In addition, Singleton can also be stateless. Provides tool functions,

The Singleton mode provides us with the possibility of such implementation. Singleton also saves memory because it limits the number of instances and facilitates Java garbage collection ).

We often see that the class loader in the factory mode is also implemented in the Singleton mode, because the loaded class actually belongs to resources.

How to use it?
Generally, Singleton mode has several forms:

Public class Singleton { Private Singleton (){} // Define your own instance internally. Isn't it strange? // Note that this is private for internal calls only Private static Singleton instance = new Singleton (); // Here is a static method for external access to this class, which can be accessed directly. Public static Singleton getInstance (){ Return instance; } }

Second form:

Public class Singleton { Private static Singleton instance = null; Public static synchronized Singleton getInstance (){ // This method is better than above. You don't need to generate objects every time. It's just the first time. // Generate instances during use, improving efficiency! If (instance = null) Instance = new Singleton (); Return instance ;} }

Use Singleton. getInstance () to access the single-State class.

The second form above is lazy initialization. That is to say, the initial Singleton will not be regenerated in the first call.

Note that synchronized in the form of lazy initialization is important. If synchronized is not available, you may obtain multiple Singleton instances by using getInstance. There are many discussions about Singleton of lazy initialization involving double-checked locking (DCL), which will be further studied by interested parties.

It is generally considered that the first form is more secure.

Considerations for using Singleton:
In some cases, Singleton cannot be used for Singleton. If multiple Singleton objects are simultaneously loaded by different class loaders; in distributed systems such as ejbs, you should also pay attention to this situation because ejbs are cross-server and cross-JVM.

Take ServiceLocator of Pet Store source code (Pet Store 1.3.1) of SUN as an example to analyze it a little:

In Pet Store, ServiceLocator has two types: one is under the EJB directory and the other is under the WEB directory. When we check the two ServiceLocator files, we will find that the content is similar, and they all provide the query and positioning service for EJB, but why should we separate them? After careful research on the two ServiceLocator methods, we can find the difference: ServiceLocator in the WEB adopts the Singleton mode, and ServiceLocator is a resource location. Naturally, we should use the Singleton mode. However, in EJB, the Singleton mode has no effect, so ServiceLocator is divided into two types: WEB Services and EJB services.

The Singleton mode looks simple and easy to use, but it is not easy to use well. You need to have a good understanding of Java's class thread memory and other concepts.

In short: If your application is based on containers, the Singleton mode is rarely used or not used. You can use alternative technologies.

For more information, see