单例模式

 

参考资料： https://dzone.com/articles/singleton-design-pattern-1?edition=647305&utm_medium=email&utm_source=dzone&utm_content=2021%20Trends%20and%20Predictions&utm_campaign=

 

 

 

The Singleton Pattern

The singleton pattern is one of the simplest design patterns in Java. This design pattern is considered a creational pattern, as this pattern provides one of the best ways to create an object.

Sometimes it’s important for some classes to have exactly one instance. There are many times when we only need one instance of an object and if we instantiate more than one we’ll run into all sorts of problems, like incorrect program behavior, overuse of resources, or inconsistent results. You may require only one object of a class, for example, when you are creating:

• the context of an application.
• a thread manageable pool.
• registry settings.
• a driver to connect to the input or output console.
• and much more.

More than one object of that type clearly will cause inconsistency to our code.

The singleton pattern ensures that a class has only one instance and provides a global point of access to it. Although a singleton is the simplest in terms of its class diagram, because there is only one single class, its implementation is a bit trickier.

Motivation

Sometimes it's important to have only one instance for a class. For example, in a system there should be only one window manager or only one print spooler. Usually, singletons are used for centralized management of internal or external resources and they provide a global point of access to themselves.

The singleton pattern involves only one class which is required to instantiate itself and to make sure it creates no more than one instance.

At the same time, it provides a global point of access to that instance. In this case, the same instance can be accessed from anywhere, making it impossible to directly invoke the constructor each time.

How to Create a Class Using the Singleton Pattern

While there are many ways to create such a class, we will take a look the methods that have worked for me in the past.

Let’s start with a simple way. What if we provide a global variable that makes an object accessible? For example: 

Java

 

 

 

 

 

1

package com.singleton.demonstration; 

2

3

public class SingletonEager { 

4

public static SingletonEager sc = new SingletonEager(); 

5

}

 

 

As we know, there is only one copy of the static variables of a class; we can apply this. As far as the client code using this sc static variable... it's fine. But, if the client uses a new operator there would be a new instance of this class. To stop the class from getting instantiated outside the class, let’s make the constructor of the class private. 

Java

 

 

 

 

 

1

package com.singleton.demonstration;

2

3

4

public class SingletonEager {

5

public static SingletonEager sc = new SingletonEager();

6

7

8

private SingletonEager() {

9

}

10

}

 

 

Is this going to work? I believe so. By keeping the constructor private, no other class can instantiate this class. The only way to get the object of this class is by using the sc static variable, which ensures only one object is there. But, as we know, providing direct access to a class member is not a good idea. We will provide a method through which the sc variable will get access, but not directly.  

Java

 

 

 

 

 

1

package com.singleton.demonstration; 

2

3

4

public class SingletonEager {

5

private static SingletonEager sc = new SingletonEager(); 

6

private SingletonEager(){} 

7

public static SingletonEager getInstance()

8

    { 

9

    return sc;

10

    } 

11

 } 

 

 

So, this is our singleton class, which makes sure that only one object of the class gets created and, even if there are several requests, only the same instantiated object will be returned. The one problem with this approach is that the object will get created as soon as the class gets loaded into the JVM. If the object is never requested, there will be a useless object inside the memory. It’s always a good approach that an object should get created when it is required. So, we will create an object on the first call and then return the same object on successive calls.  

Java

 

 

 

 

 

 

1

package com.singleton.demonstration;

2

3

4

public class SingletonLazy {

5

private static SingletonLazy sc = null;

6

7

8

private SingletonLazy() {

9

}

10

11

12

public static SingletonLazy getInstance() {

13

if (sc == null) {

14

sc = new SingletonLazy();

15

}

16

return sc;

17

}

18

}

 

 

In the getInstance() method, we check if the static variable sc is null, then instantiate the object and return it. So, on the first call when sc would be null, the object gets created and on successive calls it will return the same object. This surely looks good, doesn’t it? But this code will fail in a multi-threaded environment. Imagine two threads concurrently accessing the class, thread t1 gives the first call to the getInstance()method, it checks if the static variable sc is null, and then gets interrupted. Another thread (t2) calls the getInstance() method, successfully passes the if check, and instantiates the object. Then, thread t1 gets awoken and it also creates the object.

At this time, we have two objects of this class. To avoid this, we will use the synchronized keyword with the getInstance() method. In this way, we force every thread to wait its turn before it can enter the method. So, no two threads will enter the method at the same time. The synchronized comes with a price, it will decrease the performance, but if the call to the getInstance() method isn’t causing a substantial overhead for your application, forget about it. The other workaround is to move to an eager instantiation approach as shown in the previous example. 

Java

 

 

 

 

 

 

1

package com.singleton.demonstration;

2

3

4

public class SingletonLazyMultithreaded {

5

private static SingletonLazyMultithreaded sc = null;

6

7

8

private SingletonLazyMultithreaded() {

9

}

10

11

12

public static synchronized SingletonLazyMultithreaded getInstance() {

13

if (sc == null) {

14

sc = new SingletonLazyMultithreaded();

15

}

16

return sc;

17

}

18

}

 

 

But if you want to use synchronization, there is another technique known as "double-checked locking" to reduce the use of synchronization. With the double-checked locking, we first check to see if an instance is created and, if not, then we synchronize it. This way, we only synchronize the first time. 

Java

 

 

 

 

 

 

1

package com.singleton.demonstration;

2

3

4

public class SingletonLazyDoubleCheck {

5

private volatile static SingletonLazyDoubleCheck sc = null;

6

7

8

private SingletonLazyDoubleCheck() {

9

}

10

11

12

public static SingletonLazyDoubleCheck getInstance() {

13

if (sc == null) {

14

synchronized (SingletonLazyDoubleCheck.class) {

15

if (sc == null) {

16

sc = new SingletonLazyDoubleCheck();

17

}

18

}

19

}

20

21

22

return sc;

23

}

24

}

 

 

Apart from this, there are some other ways to break the singleton pattern. 

• If the class is serializable.
• If it’s clonable.
• If can be broken by reflection.
• If the class is loaded by multiple class loaders.

The following example shows how you can protect your class from getting instantiated more than once. 

Java

 

 

 

 

 

 

1

package com.singleton.demonstration;

2

import java.io.ObjectStreamException;

3

import java.io.Serializable;

4

5

6

public class Singleton implements Serializable {

7

private static final long serialVersionUID = -1093810940935189395L;

8

private static Singleton sc = new Singleton();

9

10

11

private Singleton() {

12

if (sc != null) {

13

throw new IllegalStateException("Already created.");

14

}

15

}

16

17

18

public static Singleton getInstance() {

19

return sc;

20

}

21

22

23

private Object readResolve() throws ObjectStreamException {

24

return sc;

25

}

26

27

28

private Object writeReplace() throws ObjectStreamException {

29

return sc;

30

}

31

32

33

public Object clone() throws CloneNotSupportedException {

34

throw new CloneNotSupportedException("Singleton, cannot be clonned");

35

}

36

37

38

private static Class getClass(String classname) throws ClassNotFoundException {

39

ClassLoader classLoader = Thread.currentThread().getContextClassLoader();

40

if (classLoader == null)

41

classLoader = Singleton.class.getClassLoader();

42

return (classLoader.loadClass(classname));

43

}

44

}

45

46

47

}

 

 

 

• Implement the readResolve() and writeReplace() methods in your singleton class and return the same object through them.
• You should also implement the clone() method and throw an exception so that the singleton cannot be cloned.
• An "if condition" inside the constructor can prevent the singleton from getting instantiated more than once using reflection.
• To prevent the singleton from getting instantiated from different class loaders, you can implement the getClass() method. The above getClass() method associates the classloader with the current thread; if that classloader is null, the method uses the same classloader that loaded the singleton class.

Although we can use all these techniques, there is an easier way of creating a singleton class. As of JDK 1.5, you can create a singleton class using enums. The enum constants are implicitly static and final and you cannot change their values once created. 

Java

 

 

 

 

 

1

package com.singleton.demonstration;

2

3

4

public class SingletoneEnum {

5

public enum SingleEnum {

6

SINGLETON_ENUM;

7

}

8

}

 

 

You will get a compile-time error when you attempt to explicitly instantiate an enum object. As enum gets loaded statically, it is thread-safe. The clone method in enum is final, which ensures that enum constants never get cloned. Enum is inherently serializable, the serialization mechanism ensures that duplicate instances are never created as a result of deserialization. Instantiation using reflection is also prohibited. These things ensure that no instance of an enum exists beyond the one defined by the enum constants. 

When to Use Singletons

• There must be exactly one instance of a class, and it must be accessible to clients from a well-known access point.
• The sole instance is extensible by subclassing and clients can use an extended instance without modifying their code.

Pros and Cons of Using Singletons

Pros 

• You can be sure that a class has only a single instance.
• You gain a global access point to that instance.
• The singleton object is initialized only when it’s requested for the first time.

Cons 

• Violates the Single Responsibility Principle. The pattern solves two problems at a time.
• The Singleton pattern can mask bad design, for instance, when the components of the program know too much about each other.
• The pattern requires special treatment in a multithreaded environment so that multiple threads won’t create a singleton object several times.
• It may be difficult to unit test the client code of the singleton because many test frameworks rely on inheritance when producing mock objects. Since the constructor of the singleton class is private and overriding static methods is impossible in most languages, you will need to think of a creative way to mock the singleton. Otherwise, just don’t write the tests or use the Singleton pattern.

Conclusion

In the above article, we have gone into detail about the singleton pattern and how to implement the singleton pattern along with a practical demonstration. Though the singleton pattern looks like a simple implementation, we should resist using it until and unless there is a strong requirement for it. You can blame the unpredictable nature of the results on the multi-threading environment. Though we can use enum in Java 5+, sometimes it's difficult to implement your logic in an enum or there might be legacy code before Java 5 you have to contend with.