关于设计模式:单例模式的几种实现And反射对其的破坏

单例模式属于 创立型模式 之一，它提供了一种创建对象的最佳形式

在软件工程中，创立型模式是解决对象创立的设计模式，试图依据理论状况应用适合的形式创建对象。根本的对象创立形式可能会导致设计上的问题，或减少设计的复杂度。创立型模式通过以某种形式管制对象的创立来解决问题。

因为咱们平时尽管能够定义一个全局变量使一个对象被拜访，然而它并不能保障你屡次实例化对象，最直观的，屡次创建对象的代价就是耗费性能，导致效率会低一些。单例模式就是用来解决这些问题

顺便提一个很常见的例子：例如在 Win 系的电脑下咱们永远只能关上一个工作管理器，这样能够避免出现一些资源节约，以及多窗口显示数据不统一的问题

定义：单例模式，保障一个类仅有一个实例，并且提供一个拜访它的全局拜访点

① 单例类只能有一个实例对象
② 单例类必须本人创立本人的惟一实例
③ 单例类必须对外提供一个拜访该实例的办法

提供了对惟一实例的受控拜访
保障了内存中只有惟一实例，缩小了内存的开销
- 尤其体现在一些须要屡次创立销毁实例的状况下
防止对资源的多重占用
- 比方对文件的写操作

单例模式中没有形象层，没有接口，不能继承，扩大艰难，扩大须要批改原来的代码，违反了 “开闭准则”
单例类的代码个别写在同一个类中，肯定水平上职责过重，违反了 “繁多职责准则”

先说几个大家常见单例的例子：

Windows 下的工作管理器和回收站，都是典型的单例模式，你能够试一下，没法同时关上两个的哈
数据库连接池的设计个别也是单例模式，因为频繁的关上敞开与数据库的连贯，会有不小的效率损耗
- 然而滥用单例也可能带来一些问题，例如导致共享连接池对象的程序过多而呈现连接池溢出
网站计数器，通过单例解决同步问题
操作系统的文件系统
Web 利用的配置对象读取，因为配置文件属于共享的资源
程序的日志利用，个别也是单例，否则追加内容时，容易出问题

所以，依据一些常见的例子，简略总结一下，什么时候用单例模式呢？

① 须要频繁创立销毁实例的
② 实例创立时，耗费资源过多，或者耗时较多的，例如数据连贯或者 IO
③ 某个类只要求生成一个类的状况，例如生成惟一序列号，或者人的身份证
④ 对象须要共享的状况，如 Web 中配置对象

依据单例模式的定义和特点，咱们能够分为三步来实现最根本的单例模式

① 构造函数私有化
② 在类的外部创立实例
③ 提供本类实例的惟一全局拜访点，即提供获取惟一实例的办法

咱们就依照最根本的这三点来写

public class Hungry {
    // 结构器公有，静止内部 new
    private Hungry(){}

    // 在类的外部创立本人的实例
    private static Hungry hungry = new Hungry();

    // 获取本类实例的惟一全局拜访点
    public static Hungry getHungry(){return hungry;}
}

这种做法一开始就间接创立这个实例，咱们也称为饿汉式单例，然而如果 这个实例始终没有被调用，会造成内存的节约，显然这样做是不适合的

饿汉式的次要问题在于，一开始就创立实例导致的内存节约问题，那么咱们将创建对象的步骤，挪到具体应用的时候

public class Lazy1 {
    // 结构器公有，静止内部 new
    private Lazy1(){System.out.println(Thread.currentThread().getName() + "拜访到了");
    }
    
    // 定义即可，不真正创立
    private static Lazy1 lazy1 = null;

    // 获取本类实例的惟一全局拜访点
    public static Lazy1 getLazy1(){
        // 如果实例不存在则 new 一个新的实例，否则返回现有的实例
        if (lazy1 == null) {lazy1 = new Lazy1();
        }
        return lazy1;
    }

    public static void main(String[] args) {
        // 多线程拜访，看看会有什么问题
        for (int i = 0; i < 10; i++) {new Thread(()->{Lazy1.getLazy1();
            }).start();}
    }
}

例如上述代码，咱们只在刚开始做了一个定义，真正的实例化是在调用 getLazy1() 时被执行

单线程环境下是没有问题的，然而多线程的状况下就会呈现问题，例如上面是我运行后果中的一次：

Thread-0 拜访到了
Thread-4 拜访到了
Thread-1 拜访到了
Thread-3 拜访到了
Thread-2 拜访到了

很显然，多线程下的一般懒汉式呈现了问题，这个时候，咱们只须要加一层锁就能够解决

简略的做法就是在办法前加上 synchronized 关键字

public static synchronized Lazy1 getLazy1(){if (lazy1 == null) {lazy1 = new Lazy1();
    }
    return lazy1;
}

然而咱们又想放大锁的范畴，毕竟办法上加锁，多线程中效率会低一些，所以只把锁加到须要的代码上

咱们直观的可能会这样写

public static Lazy1 getLazy1(){if (lazy1 == null) {synchronized(Lazy1.class){lazy1 = new Lazy1();
        }
       }
    return lazy1;
}

然而这样还是有问题的

当线程 A 和 B 同时拜访 getLazy1()，执行到到 if (lazy1 == null) 这句的时候，同时判断出 lazy1 == null，也就同时进入了 if 代码块中，前面因为加了锁，只有一个能先执行实例化的操作，例如 A 先进入，然而前面的 B 进入后同样也能够创立新的实例，就达不到单例的目标了，不信能够本人试一下

解决的形式就是再进行第二次的判断

// 获取本类实例的惟一全局拜访点
public static Lazy1 getLazy1(){
    // 如果实例不存在则 new 一个新的实例，否则返回现有的实例
    if (lazy1 == null) {
        // 加锁
        synchronized(Lazy1.class){
            // 第二次判断是否为 null
            if (lazy1 == null){lazy1 = new Lazy1();
            }
        }
    }
    return lazy1;
}

这种在适当地位加锁的形式，尽可能的升高了加锁对于性能的影响，也能达到预期成果

然而这段代码，在肯定条件下还是会有问题，那就是指令重排问题

指令重排序是 JVM 为了优化指令，进步程序运行效率，在不影响单线程程序执行后果的前提下，尽可能地进步并行度。

什么意思呢？

首先要晓得 lazy1 = new Lazy1(); 这一步并不是一个原子性操作，也就是说这个操作会分成很多步

① 调配对象的内存空间
② 执行构造函数，初始化对象
③ 指向对象到刚调配的内存空间

然而 JVM 为了效率对这个步骤进行了重排序，例如这样：

① 调配对象的内存空间
③ 指向对象到刚调配的内存空间，对象还没被初始化
② 执行构造函数，初始化对象

依照 ① ③ ② 的程序，当 A 线程执行到 ② 后，B 线程判断 lazy1 != null，然而此时的 lazy1 还没有被初始化，所以会出问题，并且这个过程中 B 基本执行到锁那里，配个表格阐明一下：

Time	ThreadA	ThreadB
t1	A：① 调配对象的内存空间
t2	A：③ 指向对象到刚调配的内存空间，对象还没被初始化
t3		B：判断 lazy1 是否为 null
t4		B：判断到 lazy1 != null，返回了一个没被初始化的对象
t5	A：② 初始化对象

解决的办法很简略——在定义时减少 volatile 关键字，防止指令重排

最终代码如下：

public class Lazy1 {
    // 结构器公有，静止内部 new
    private Lazy1(){System.out.println(Thread.currentThread().getName() + "拜访到了");
    }

    // 定义即可，不真正创立
    private static volatile Lazy1 lazy1 = null;

    // 获取本类实例的惟一全局拜访点
    public static Lazy1 getLazy1(){
        // 如果实例不存在则 new 一个新的实例，否则返回现有的实例
        if (lazy1 == null) {
            // 加锁
            synchronized(Lazy1.class){
                // 第二次判断是否为 null
                if (lazy1 == null){lazy1 = new Lazy1();
                }
            }
        }
        return lazy1;
    }

    public static void main(String[] args) {
        // 多线程拜访，看看会有什么问题
        for (int i = 0; i < 10; i++) {new Thread(()->{Lazy1.getLazy1();
            }).start();}
    }
}

双重锁定算是一种可行不错的形式，而动态外部类就是一种更加好的办法，不仅速度较快，还保障了线程平安，先看代码

public class Lazy2 {
    // 结构器公有，静止内部 new
    private Lazy2(){System.out.println(Thread.currentThread().getName() + "拜访到了");
    }

    // 用来获取对象
    public static Lazy2 getLazy2(){return InnerClass.lazy2;}

    // 创立外部类
    public static class InnerClass {
        // 创立单例对象
        private static Lazy2 lazy2 = new Lazy2();}

    public static void main(String[] args) {
        // 多线程拜访，看看会有什么问题
        for (int i = 0; i < 10; i++) {new Thread(()->{Lazy2.getLazy2();
            }).start();}
    }
}

下面的代码，首先 InnerClass 是一个外部类，其在初始化时是不会被加载的，当用户执行了 getLazy2() 办法才会加载，同时创立单例对象，所以他也是懒汉式的办法，因为 InnerClass 是一个动态外部类，所以只会被实例化一次，从而达到线程平安，因为并没有加锁，所以性能上也会很快，所以个别是举荐的

最初举荐一个十分好的形式，那就是枚举单例形式，其不仅简略，且保障了平安，先看一下《Effective Java》中作者的阐明：

这种办法在性能上与私有域办法类似，但更加简洁无偿地提供了序列化机制，相对避免屡次实例化。即便是在面对简单的序列化或者反射攻打的时候。尽管这种办法还没有宽泛采纳，然而单元素的枚举类型常常成为实现 Singleton 的最佳办法，留神，如果 Singleton 必须扩大一个超类，而不是扩大 enum 时则不宜应用这个办法，（尽管能够申明枚举去实现接口）。

节选自《Effective Java》第 3 条：用公有结构器或者枚举类型强化 Singleton 属性

原著：Item3: Enforce the singleton property with a private constructor or an enum

代码就这样，几乎不要太简略，拜访通过 EnumSingle.IDEAL 就能够拜访了

public enum EnumSingle {IDEAL;}

咱们接下来就要给大家演示为什么枚举是一种比拟平安的形式

上面用双重锁定的懒汉式单例演示一下，这是咱们原来的写法，new 两个实例进去，输入一下

public class Lazy1 {
    // 结构器公有，静止内部 new
    private Lazy1(){System.out.println(Thread.currentThread().getName() + "拜访到了");
    }

    // 定义即可，不真正创立
    private static volatile Lazy1 lazy1 = null;

    // 获取本类实例的惟一全局拜访点
    public static Lazy1 getLazy1(){
        // 如果实例不存在则 new 一个新的实例，否则返回现有的实例
        if (lazy1 == null) {
            // 加锁
            synchronized(Lazy1.class){
                // 第二次判断是否为 null
                if (lazy1 == null){lazy1 = new Lazy1();
                }
            }
        }
        return lazy1;
    }

    public static void main(String[] args) {Lazy1 lazy1 = getLazy1();
        Lazy1 lazy2 = getLazy1();
        System.out.println(lazy1);
        System.out.println(lazy2);

    }
}

运行后果：
main 拜访到了
cn.ideal.single.Lazy1@1b6d3586
cn.ideal.single.Lazy1@1b6d3586

能够看到，后果是单例没有问题

然而咱们如果通过反射的形式进行实例化类，会有什么问题呢？

public static void main(String[] args) throws Exception {Lazy1 lazy1 = getLazy1();
    // 取得其空参结构器
    Constructor<Lazy1>  declaredConstructor = Lazy1.class.getDeclaredConstructor(null);
    // 使得可操作性该 declaredConstructor 对象
    declaredConstructor.setAccessible(true);
    // 反射实例化
    Lazy1 lazy2 = declaredConstructor.newInstance();
    System.out.println(lazy1);
    System.out.println(lazy2);
}

getDeclaredConstructor() 办法阐明

办法返回一个 Constructor 对象，它反映此 Class 对象所示意的类或接口指定的构造函数。parameterTypesparameter 是确定构造函数的形参类型，在 Class 对象申明程序的数组。

public Constructor<T> getDeclaredConstructor(Class<?>… parameterTypes) throws NoSuchMethodException, SecurityException

运行后果：

main 拜访到了
main 拜访到了
cn.ideal.single.Lazy1@1b6d3586
cn.ideal.single.Lazy1@4554617c

能够看到，单例被毁坏了

解决办法：因为咱们反射走的其无参结构，所以在无参结构中再次进行非 null 判断，加上原来的双重锁定，当初也就有三次判断了

// 结构器公有，静止内部 new
private Lazy1(){synchronized (Lazy1.class){if(lazy1 != null) {throw new RuntimeException("反射毁坏单例异样");
        } 
    }
}

不过后果也没让人悲观，这种测试下，第二次实例化会间接报异样

如果两个都是反射实例化进去的，也就是说，基本就不去调用 getLazy1() 办法，那可怎么办？

如下：

public static void main(String[] args) throws Exception {

    // 取得其空参结构器
    Constructor<Lazy1> declaredConstructor = Lazy1.class.getDeclaredConstructor(null);
    // 使得可操作性该 declaredConstructor 对象
    declaredConstructor.setAccessible(true);
     // 反射实例化
    Lazy1 lazy1 = declaredConstructor.newInstance();
    Lazy1 lazy2 = declaredConstructor.newInstance();

    System.out.println(lazy1);
    System.out.println(lazy2);
}

运行后果：

main 拜访到了
main 拜访到了
cn.ideal.single.Lazy1@1b6d3586
cn.ideal.single.Lazy1@4554617c

单例又被毁坏了

解决方案：减少一个标识位，例如下文通过减少一个布尔类型的 ideal 标识，保障只会执行一次，更平安的做法，能够进行加密解决，保障其安全性

// 结构器公有，静止内部 new
private Lazy1(){synchronized (Lazy1.class){if (ideal == false){ideal = true;} else {throw new RuntimeException("反射毁坏单例异样");
        }
    }
    System.out.println(Thread.currentThread().getName() + "拜访到了");
}

这样就没问题了吗，并不是，一旦他人通过一些伎俩失去了这个标识内容，那么他就能够通过批改这个标识持续毁坏单例，代码如下（这个把代码贴全一点，后面都是节选要害的，都能够参考这个）

public class Lazy1 {

    private static boolean ideal = false;

    // 结构器公有，静止内部 new
    private Lazy1(){synchronized (Lazy1.class){if (ideal == false){ideal = true;} else {throw new RuntimeException("反射毁坏单例异样");
            }
        }
        System.out.println(Thread.currentThread().getName() + "拜访到了");
    }

    // 定义即可，不真正创立
    private static volatile Lazy1 lazy1 = null;

    // 获取本类实例的惟一全局拜访点
    public static Lazy1 getLazy1(){
        // 如果实例不存在则 new 一个新的实例，否则返回现有的实例
        if (lazy1 == null) {
            // 加锁
            synchronized(Lazy1.class){
                // 第二次判断是否为 null
                if (lazy1 == null){lazy1 = new Lazy1();
                }
            }
        }
        return lazy1;
    }

    public static void main(String[] args) throws Exception {Field ideal = Lazy1.class.getDeclaredField("ideal");
        ideal.setAccessible(true);

        // 取得其空参结构器
        Constructor<Lazy1> declaredConstructor = Lazy1.class.getDeclaredConstructor(null);
        // 使得可操作性该 declaredConstructor 对象
        declaredConstructor.setAccessible(true);
        // 反射实例化
        Lazy1 lazy1 = declaredConstructor.newInstance();
        ideal.set(lazy1,false);
        Lazy1 lazy2 = declaredConstructor.newInstance();

        System.out.println(lazy1);
        System.out.println(lazy2);

    }
}

运行后果：

main 拜访到了
main 拜访到了
cn.ideal.single.Lazy1@4554617c
cn.ideal.single.Lazy1@74a14482

实例化 lazy1 后，其执行了批改 ideal 这个布尔值为 false，从而绕过了判断，再次毁坏了单例

所以，能够得出，这几种形式都是不平安的，都有着被反射毁坏的危险

下面在解说枚举单例形式的时候就提过《Effective Java》中提到，即便是在面对简单的序列化或者反射攻打的时候，（枚举单例形式）相对避免屡次实例化，上面来看一下是不是这样：

首先说一个前提条件：这是 Constructor 下的 newInstance 办法节选，也就是说遇到枚举时，会报异样，也就是不容许通过反射创立枚举

if ((clazz.getModifiers() & Modifier.ENUM) != 0)
    throw new IllegalArgumentException("Cannot reflectively create enum objects");

看一下咱们枚举单例类 EnumSingle 生成的字节码文件，能够看到其中有一个无参结构，也就是说，咱们还是只须要拿到 getDeclaredConstructor(null) 就行了

代码如下：

public enum EnumSingle {
    IDEAL;

    public static void main(String[] args) throws Exception {
        EnumSingle ideal1 = EnumSingle.IDEAL;
        // 取得其空参结构器
        Constructor<EnumSingle> declaredConstructor = EnumSingle.class.getDeclaredConstructor(null);
        // 使得可操作性该 declaredConstructor 对象
        declaredConstructor.setAccessible(true);
        // 反射实例化
        EnumSingle ideal2 = declaredConstructor.newInstance();
        System.out.println(ideal1);
        System.out.println(ideal2);
    }
}

运行后果却是出乎意料：

提醒居然是找不到这个空参？？？字节码中可是却是存在的啊

Exception in thread "main" java.lang.NoSuchMethodException: cn.ideal.single.EnumSingle.<init>()

本人 javap 反编译一下，能够看到还是有这个空参

换成 jad 再看看（将 jad.exe 放在字节码文件同目录下）

执行：jad -sjava EnumSingle.class

提醒曾经反编译完结：Parsing EnumSingle.class… Generating EnumSingle.java

关上生成的 java 文件，终于发现，原来它是一个带参结构，同时有两个参数，String 和 int

所以上面，咱们只须要批改原来的无参为有参即可：

public enum EnumSingle {
    IDEAL;

    public static void main(String[] args) throws Exception {
        EnumSingle ideal1 = EnumSingle.IDEAL;
        Constructor<EnumSingle> declaredConstructor = EnumSingle.class.getDeclaredConstructor(String.class, int.class);
        // 使得可操作性该 declaredConstructor 对象
        declaredConstructor.setAccessible(true);
        // 反射实例化
        EnumSingle ideal2 = declaredConstructor.newInstance();
        System.out.println(ideal1);
        System.out.println(ideal2);
    }
}

这样就没问题了，提醒了咱们想要的谬误：Cannot reflectively create enum objects

这也阐明，枚举类的单例模式写法的确不会被反射毁坏！

关于设计模式:单例模式的几种实现And反射对其的破坏

一单例模式概述

(一) 什么是单例模式

(二) 特点

(三) 优缺点以及应用场景

(1) 长处

(2) 毛病

(3) 利用场景

二实现单例模式

(一) 饿汉式

(二) 懒汉式

(三) DCL 懒汉式

(1) 办法上间接加锁

(2) 放大锁的范畴

(3) 双重锁定

(4) 指令重排问题

(5) 最终代码

(四) 动态外部类懒汉式

(五) 枚举形式

三反射毁坏单例模式

(一) 单例是如何被毁坏的

(1) 一个一般实例化，一个反射实例化

(2) 两个都是反射实例化

(二) 枚举类不会被毁坏

一 单例模式概述

(一) 什么是单例模式

(二) 特点

(三) 优缺点以及应用场景

(1) 长处

(2) 毛病

(3) 利用场景

二 实现单例模式

(一) 饿汉式

(二) 懒汉式

(三) DCL 懒汉式

(1) 办法上间接加锁

(2) 放大锁的范畴

(3) 双重锁定

(4) 指令重排问题

(5) 最终代码

(四) 动态外部类懒汉式

(五) 枚举形式

三 反射毁坏单例模式

(一) 单例是如何被毁坏的

(1) 一个一般实例化，一个反射实例化

(2) 两个都是反射实例化

(二) 枚举类不会被毁坏

一单例模式概述

二实现单例模式

三反射毁坏单例模式