【深入理解设计模式】单例设计模式

注意：
双重检查锁模式是一种非常好的单例实现模式，解决了单例、性能、线程安全问题，上面的双重检测锁模式看上去完美无缺，其实是存在问题，在多线程的情况下，可能会出现空指针问题，出现问题的原因是JVM在实例化对象的时候会进行优化和指令重排序操作。

要解决双重检查锁模式带来空指针异常的问题，只需要使用 volatile 关键字, volatile 关键字可以保证可见性和有序性。

添加 volatile 关键字之后的双重检查锁模式是一种比较好的单例实现模式，能够保证在多线程的情况下线程安全也不会有性能问题。

懒汉式实现4 - 静态内部类方式

静态内部类单例模式中实例由内部类创建，由于 JVM 在加载外部类的过程中, 是不会加载静态内部类的, 只有内部类的属性/方法被调用时才会被加载, 并初始化其静态属性。静态属性由于被 static 修饰，保证只被实例化一次，并且严格保证实例化顺序。

/**
 * @author OldGj 
 * @version v1.0
 * @apiNote 单例设计模式 - 懒汉式 > 静态内部类实现 <
 */
public class Singleton {
    /**
     * 静态内部类单例模式中实例由内部类创建，
     * 由于 JVM 在加载外部类的过程中, 是不会加载静态内部类的, 只有内部类的属性/方法被调用时才会被加载,
     * 并初始化其静态属性。静态属性由于被 `static` 修饰，保证只被实例化一次，并且严格保证实例化顺序。
     */


    // 1.构造器私有化
    private Singleton() {}

    // 2.创建静态内部类，并且在静态内部类中创建外部类的实例
    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }

    // 3.对外提供可以获得本类实例的静态方法
    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

说明：

​ 第一次加载Singleton类时不会去初始化INSTANCE，只有第一次调用getInstance()，虚拟机加载SingletonHolder并初始化INSTANCE，这样不仅能确保线程安全，也能保证 Singleton 类的唯一性。

小结：

​ 静态内部类单例模式是一种优秀的单例模式，是开源项目中比较常用的一种单例模式。在没有加任何锁的情况下，保证了多线程下的安全，并且没有任何性能影响和空间的浪费。

破坏单例模式

单例模式主要是通过把一个类的构造器私有化，来避免重复创建多个对象的。如果想要破坏单例模式，就要想办法执行到私有的构造方法即可！

这里有两种方式可以破坏单例模式，分别是：

1.使用反射机制
2. 序列化 / 反序列化

序列化 / 反序列化

我们先通过静态内部类的方式定义一个单例模式的类Singleton:

/**
 * @author OldGj 
 * @version v1.0
 * @apiNote 破坏单例模式 - 序列化/反序列化
 */
public class Singleton implements Serializable {

    // 1.构造器私有化
    private Singleton() {
    }

    // 2.创建静态内部类，并且在静态内部类中创建外部类的实例
    private static class SingletonHandel {
        private static final Singleton INSTANCE = new Singleton();
    }

    // 3.对外提供可以获取到本类对象的静态方法
    public static Singleton getInstance() {
        return SingletonHandel.INSTANCE;
    }
    
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

然后通过序列化 / 反序列化的方式，尝试创建该单例模式的实例：

/**
 * @author OldGj 
 * @version v1.0
 * @apiNote 测试类 - 测试序列化/反序列化会不会破坏单例模式
 */
public class Client {

    public static void main(String[] args) throws IOException, ClassNotFoundException {
//        writeObjToFile();
        readObjFromFile();
        readObjFromFile();
    }

    public static void readObjFromFile() throws IOException, ClassNotFoundException {
        // 1.创建对象输入流对象
        ObjectInputStream objectInputStream = new ObjectInputStream(new FileInputStream("C:\\Users\\HX\\Desktop\\a.txt"));
        // 2.读取对象
        Singleton singleton = (Singleton) objectInputStream.readObject();
        System.out.println(singleton); // 输出的地址不一样，说明：序列化/反序列化会破坏单例模式
        // 3.关闭资源
        objectInputStream.close();
    }

    /**
     * 序列化对象，写道磁盘文件中
     * @throws IOException io异常
     */
    public static void writeObjToFile() throws IOException {
        // 1.创建对象输出流对象
        ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("C:\\Users\\HX\\Desktop\\a.txt"));
        // 2.创建对象
        Singleton instance = Singleton.getInstance();
        // 3.对外写出对象
        oos.writeObject(instance);
        // 4.关闭资源
        oos.close();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

通过以上代码测试，我们发现控制台输出的Singleton对象的地址是不同的，也就是说通过序列化 / 反序列化方式破坏了单例模式。

反射机制

首先，我们先使用双重判断锁的方式实现一个Singleton单例模式：

/**
 * @author OldGj 
 * @version v1.0
 * @apiNote 破坏单例模式 - 反射
 */
public class Singleton {

    //1.构造器私有化
    private Singleton() {}

    //2.在成员位置声明本类的静态变量
    private static volatile Singleton instance;

    //3.对外提供可获得本类实例的静态方法
    public static Singleton getInstance() {

        /*
         * 双重检查锁
         */
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

然后我们编写测试类，测试通过反射机制是否可以破坏单例模式：

/**
 * @author OldGj 
 * @version v1.0
 * @apiNote 测试类 - 测试 反射机制是否会破坏单例模式
 */
public class Client {
    public static void main(String[] args) throws Exception {

        // 1.获取单例对象的字节码对象
        Class clazz = Singleton.class;
        // 2.获取无参构造
        Constructor constructor = clazz.getDeclaredConstructor();
        // 3.关闭访问权限
        constructor.setAccessible(true);
        // 4.创建对象
        Singleton s1 = (Singleton) constructor.newInstance();
        Singleton s2 = (Singleton) constructor.newInstance();
        // 如果返回true，说明反射不会破坏单例模式，如果返回false,说明反射会破坏单例模式
        System.out.println(s1 == s2);

    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

上面代码运行结果是false，表明反射机制已经破坏了单例设计模式

注意：通过枚举方式实现的饿汉式单例模式不会被以上两种方式破坏单例模式。

解决破坏单例模式

破坏单例模式的方式有两种，分别是序列化 / 反序列化以及反射机制，我们先来通过代码实现如何防止序列化 / 反序列化方式破坏单例模式：

序列化、反序列方式破坏单例模式的解决方法

/**
 * @author OldGj 
 * @version v1.0
 * @apiNote 破坏单例模式 - 序列化/反序列化
 */
public class Singleton implements Serializable {

    // 1.构造器私有化
    private Singleton() {
    }

    // 2.创建静态内部类，并且在静态内部类中创建外部类的实例
    private static class SingletonHandel {
        private static final Singleton INSTANCE = new Singleton();
    }

    // 3.对外提供可以获取到本类对象的静态方法
    public static Singleton getInstance() {
        return SingletonHandel.INSTANCE;
    }

    // 4.定义readResolve方法，解决由于序列化/反序列化造成的破坏单例模式
    /*
     * 如果定义了readResolve方法，在对象进行反序列化时，就会调用该方法返回对象
     * 如果没有定义，才会new新的对象
     * @return
     */
    public Object readResolve() {
        return SingletonHandel.INSTANCE;
    }

}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

想要解决因为序列化 / 反序列化方式破坏单例模式的问题，我们只需要在Singleton单例模式类中自定义一个readResolve方法，在该方法中返回我们自己创建的单例对象即可，因为在反序列化的底层，ObjectInputSteam对象会判断反序列化对象是否定义了readResolve方法，如果定义，则会执行该方法，如果没有定义才会new新的对象。
源码解析：
ObjectInputStream类

public final Object readObject() throws IOException, ClassNotFoundException{
    ...
    // if nested read, passHandle contains handle of enclosing object
    int outerHandle = passHandle;
    try {
        Object obj = readObject0(false);//重点查看readObject0方法
    .....
}
    
private Object readObject0(boolean unshared) throws IOException {
	...
    try {
		switch (tc) {
			...
			case TC_OBJECT:
				return checkResolve(readOrdinaryObject(unshared));//重点查看readOrdinaryObject方法
			...
        }
    } finally {
        depth--;
        bin.setBlockDataMode(oldMode);
    }    
}
    
private Object readOrdinaryObject(boolean unshared) throws IOException {
	...
	//isInstantiable 返回true，执行 desc.newInstance()，通过反射创建新的单例类，
    obj = desc.isInstantiable() ? desc.newInstance() : null; 
    ...
    // 在Singleton类中添加 readResolve 方法后 desc.hasReadResolveMethod() 方法执行结果为true
    if (obj != null && handles.lookupException(passHandle) == null && desc.hasReadResolveMethod()) {
    	// 通过反射调用 Singleton 类中的 readResolve 方法，将返回值赋值给rep变量
    	// 这样多次调用ObjectInputStream类中的readObject方法，继而就会调用我们定义的readResolve方法，所以返回的是同一个对象。
    	Object rep = desc.invokeReadResolve(obj);
     	...
    }
    return obj;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

反射方式破解单例的解决方法

/**
 * @author OldGj 
 * @version v1.0
 * @apiNote 破坏单例模式 - 反射
 */
public class Singleton {

    // 是否多次调用构造器
    private static boolean flag = false;

    //1.构造器私有化
    private Singleton() {
        /*
            解决通过反射破坏单例模式
         */
        synchronized (Singleton.class) {
            if (flag) {
                throw new RuntimeException("不能创建多个对象");
            }
            //在第一次调用构造器之后，flag设为true，下次调用则抛出异常
            flag = true;
        }
    }

    //2.在成员位置声明本类的静态变量
    private static volatile Singleton instance;

    //3.对外提供可获得本类实例的静态方法
    public static Singleton getInstance() {

        /*
         * 双重检查锁
         */
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

这种方式比较好理解。当通过反射方式多次调用构造方法进行创建创建时，直接抛异常。不运行此中操作。