其他分享
首页 > 其他分享> > 设计模式 01 单例模式

设计模式 01 单例模式

作者：互联网

参考源

https://www.bilibili.com/video/BV1u3411P7Na?spm_id_from=333.999.0.0&vd_source=299f4bc123b19e7d6f66fefd8f124a03

单例模式（Singleton Pattern）属于创建型模式

顾名思义，单例就是只有一个实例对象。在整个程序中，同一个类始终只会有一个对象来进行操作。

比如数据库连接类，实际上只需要创建一个对象或是直接使用静态方法就可以了，没必要去创建多个对象。

这种模式提供了一种创建对象的最佳方式，涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。

这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。

注意点：

经过多年的演进，单例模式有诸多实现方式，下面逐个介绍。

饿汉式

是否 Lazy 初始化：否

是否多线程安全：是

实现难度：易

本质：以空间换时间

优点：没有加锁，执行效率较高。

缺点：类加载时就初始化，浪费内存。

饿汉式是最简单的单例模式的写法，由于在类创建时就加载，保证了线程的安全。

这种方式比较常用，但容易产生垃圾对象，对空间的消耗较大。

public class Singleton {
    /**
     * 单例模式的核心，构造方法私有化
     */
    private Singleton() {

    }

    /**
     * 用于引用全局唯一的单例对象，在一开始就创建好
     */
    private final static Singleton INSTANCE = new Singleton();

    /**
     * 获取全局唯一的单例对象
     * @return 实例对象
     */
    public static Singleton getInstance() {
        return INSTANCE;
    }
}

这种方式最大的问题就是浪费内存，因为创建的对象程序不一定用得到，如果创建了没用到，就是一种浪费。

想要避免这种浪费，自然就想到在使用的时候才创建对象，这样就诞生了懒汉式。

懒汉式

普通懒汉式

是否 Lazy 初始化：是

是否多线程安全：否

实现难度：易

本质：以时间换空间

优点：需要时才创建，不会浪费内存。

缺点：多线程情况下是不安全的，且不是类创建时就加载，效率较饿汉式要低一些。

public class Singleton {
    /**
     * 单例模式的核心，构造方法私有化
     */
    private Singleton() {

    }
    
    /**
     * 在一开始先不进行对象创建
     */
    private static Singleton INSTANCE;

    /**
     * 获取全局唯一的单例对象
     * @return 实例对象
     */
    public static Singleton getInstance() {
        // 如果实例为空，那么就进行创建，不为空说明已经创建过了，就直接返回，保证单例
        if (INSTANCE == null) {    
            INSTANCE = new Singleton();
        }
        return INSTANCE;
    }
}

这种方式最大的问题就是在多线程情况下不安全，比如下面这样调用：

for (int i = 0; i < 10; i++) {
    new Thread(()->{
        LazyMan.getLazyMan();
    }).start();
}

多线程环境下，非空判断容易失效，造成创建多个实例，违背了单例的初衷。

为了避免线程安全问题，还得进行一些改进：

// 方法添加 synchronized 关键字加锁
public static synchronized Singleton getInstance(){   
    if(INSTANCE == null) {
        INSTANCE = new Singleton();
    }
    return INSTANCE;
}

既然多个线程要调用，那么就直接加一把锁，在方法上添加 synchronized 关键字即可，这样同一时间只能有一个线程进入了。

虽然这样简单粗暴，但是在高并发的情况下，效率肯定是比较低的，可以再进行优化：

public static Singleton getInstance(){
    // 规避多线程情况
    if(INSTANCE == null) {
        // 只对赋值这一步进行加锁，提升效率
        synchronized (Singleton.class) {    
            INSTANCE = new Singleton();   
        }
    }
    return INSTANCE;
}

不过这样还不完美，因为这样还是有可能多个线程同时判断为 null 而进入等锁的状态。

所以，还得加一层内层判断：

public static Singleton getInstance(){
    if(INSTANCE == null) {
        synchronized (Singleton.class) {
            // 内层检测以实现单例
            if(INSTANCE == null) {
                INSTANCE = new Singleton();
            }
        }
    }
    return INSTANCE;
}

这样外层的检测用于规避多线程情况，内层的检测用于单例的实现，比较完善的均衡了安全和性能。

但是这种写法在极端情况还是可能会有一定的问题，因为 INSTANCE = new Singleton(); 不是原子性操作，它会经过三个步骤：

1、分配对象内存空间。

2、执行构造方法初始化对象。

3、设置 instance 指向刚分配的内存地址，此时 instance != null。

由于指令重排，导致 A 线程执行 INSTANCE = new Singleton(); 的时候，可能先执行了第 3 步。

此时线程 B 又进来了，发现 INSTANCE 已经不为空了，直接返回，并且后面使用了返回的 INSTANCE。

由于线程 A 还没有执行第 2 步，导致此时 INSTANCE 还不完整，可能会有一些意想不到的错误。

所以需要增加 volatile 关键字来避免指令重排：

private volatile static Singleton INSTANCE;

这样就实现了完整的双重检测锁（DCL，即 double-checked locking）懒汉式单例模式。

双重检测锁懒汉式

public class Singleton {
    /**
     * 单例模式的核心，构造方法私有化
     */
    private Singleton() {

    }
    
    /**
     * 在一开始先不进行对象创建
     */
    private volatile static Singleton INSTANCE;

    /**
     * 获取全局唯一的单例对象
     * @return 实例对象
     */
    public static Singleton getInstance(){
        // 外层检测规避多线程情况
        if(INSTANCE == null) {
            // 只对赋值这一步进行加锁，提升效率
            synchronized (Singleton.class) {
                // 内层检测以实现单例
                if(INSTANCE == null) {
                    INSTANCE = new Singleton();
                }
            }
        }
        return INSTANCE;
    }
}

双重校验锁模式虽然严谨，但终究需要加锁，效率始终会受到影响。

那么，有没有一种更好的，不用加锁的方式也能实现延迟加载的写法呢？

答案是有的，可以使用静态内部类实现。

静态内部类实现

public class Singleton {
    private Singleton() {
        
    }

    // 由静态内部类持有单例对象。根据类加载特性，我们仅使用 Singleton 类时，不会对静态内部类进行初始化
    private static class Holder {   
        private final static Singleton INSTANCE = new Singleton();
    }

    // 只有真正使用内部类时，才会进行类初始化
    public static Singleton getInstance(){   
         // 直接获取内部类中的对象
        return Holder.INSTANCE;
    }
}

这种方式显然是最完美的懒汉式解决方案：没有进行任何的加锁操作，也能保证线程安全，还能实现懒加载。

不过要实现这种写法，跟语言本身也有一定的关联，并不是所有的语言都支持这种写法的。

而且它也不是绝对安全的，因为 Java 还有一个十分霸道的东西：反射。

万恶的反射

前面的写法尽管已经考虑得很完善，还是忽略了反射

反射是很霸道的，无视 private 修饰的构造方法，可以直接在外面 newInstance，破坏单例。

Singleton singleton = Singleton.getInstance();
// 获取无参构造器
Constructor<Singleton> declaredConstructor = Singleton.class.getDeclaredConstructor(null);
// 取消无参构造器私有属性
declaredConstructor.setAccessible(true);
// 使用反射获取的无参构造器实例化对象
Singleton singleton2 = declaredConstructor.newInstance();
// 比较实例化的两个对象
System.out.println(singleton == singleton2);

输出结果为 false，同一个类实例化的两个对象不相等，单例被破坏了。

那么，怎么解决这种问题呢？

可以在构造方法中加上对象的非空判断：

private Singleton() {
    synchronized (Singleton.class) {
        if (INSTANCE != null) {
        	throw new RuntimeException("不要试图用反射破坏单例");
        }
    }
}

但是这种写法还是有问题：

前面是先正常的调用了 getInstance 方法，创建了 Singleton 对象，然后第二次用反射创建对象，私有构造函数里面的判断起作用了，反射破坏单例模式失败。

但如果先用反射创建对象，判断就不生效了：

// 获取无参构造器
Constructor<Singleton> declaredConstructor = Singleton.class.getDeclaredConstructor(null);
// 取消无参构造器私有属性
declaredConstructor.setAccessible(true);
// 使用反射获取的无参构造器实例化对象
Singleton singleton1 = declaredConstructor.newInstance();
Singleton singleton2 = declaredConstructor.newInstance();
// 比较实例化的两个对象
System.out.println(singleton == singleton2);

输出结果为 false，同一个类实例化的两个对象不相等，单例又被破坏了！

那么如何防止这种反射破坏呢？

可以使用标志位来避免重复创建：

private static boolean flag = false;

private Singleton() {
    synchronized (Singleton.class) {
        if (flag == false) {
            // 第一次创建后，标志位设为 true
        	flag = true;
        } else {
            // 后续再使用构造方法创建则直接报错
        	throw new RuntimeException("不要试图用反射破坏单例模式");
        }
    }
}

这样看起来很完美了，但是还是不能完全防止反射破坏单例，因为可以利用反射修改 flag 的值。

// 获取无参构造器
Constructor<Singleton> declaredConstructor = Singleton.class.getDeclaredConstructor(null);
// 取消无参构造器私有属性
declaredConstructor.setAccessible(true);
// 使用反射获取的无参构造器实例化对象
Singleton singleton1 = declaredConstructor.newInstance();
// 获取 flag 属性
Field field = LazyMan.class.getDeclaredField("flag");
// 取消 flag 属性的私有属性
field.setAccessible(true);
// 通过反射，修改属性的值
field.set(singleton1, false);
// 使用反射获取的无参构造器实例化对象
Singleton singleton2 = declaredConstructor.newInstance();
// 比较实例化的两个对象
System.out.println(singleton == singleton2);

输出结果为 false，同一个类实例化的两个对象不相等，单例又又被破坏了！

正所谓道高一尺魔高一丈，懒汉式单例不管怎么挣扎，在反射面前都无计可施。

那么，就没有办法完美的实现单例这么一个最简单的设计模式了吗？

答案是有的，但不是外界，而是 Java 自己给出的解决方案。

由于反射是 Java 的语言特性，只能 Java 自身来解决这个问题

在 JDK 1.5 中推出的枚举可以完美解决这个问题。

枚举实现

枚举类型是 JDK 1.5 中新增特性的一部分，它是一种特殊的数据类型，之所以特殊是因为它既是一种类（class）却又比类多了些特殊的约束。

正是这些约束的存在造就了枚举类型的简洁性、安全性以及便捷性。

先来看下枚举是怎么实现单例的：

public enum Singleton {
    
    INSTANCE;
    
}

你没有看错，就是这么简单，这也正所谓大道至简！

尝试用反射进行破坏：

Singleton instance1 = Singleton.INSTANCE;
Constructor<Singleton> declaredConstructor = Singleton.class.getDeclaredConstructor(null);
declaredConstructor.setAccessible(true);
Singleton instance2 = declaredConstructor.newInstance();
System.out.println(instance1 == instance2);

意料之外的是，运行报错了：

Exception in thread "main" java.lang.NoSuchMethodException: cn.sail.singleton.enums.Singleton.<init>()
	at java.lang.Class.getConstructor0(Class.java:3082)
	at java.lang.Class.getDeclaredConstructor(Class.java:2178)

从报错可以看出，是因为没有找到无参构造方法。

在 IDEA 中查看编译后的 Singleton.class 文件：

public enum Singleton {
    
    INSTANCE;

    private Singleton() {
    }
}

从编译后的文件可以看到，是存在无参构造的，这就奇怪了！

再用 java 命令编译试试：

D:\Project\MY\learn\gof-23\target\classes\cn\sail\singleton\enums> javap -p Singleton.class
Compiled from "Singleton.java"
public final class cn.sail.singleton.enums.Singleton extends java.lang.Enum<cn.sail.singleton.enums.Singleton> {
  public static final cn.sail.singleton.enums.Singleton INSTANCE;
  private static final cn.sail.singleton.enums.Singleton[] $VALUES;
  public static cn.sail.singleton.enums.Singleton[] values();
  public static cn.sail.singleton.enums.Singleton valueOf(java.lang.String);
  private cn.sail.singleton.enums.Singleton();
  static {};
}

从输出结果可以看到，枚举本质还是一个类，只是继承了枚举类。

不过这里还是输出了无参构造：

private cn.sail.singleton.enums.Singleton();

再使用更专业的工具 jad 进行反编译：

D:\Project\MY\learn\gof-23\target\classes\cn\sail\singleton\enums>jad -sjava Singleton.class
Parsing Singleton.class... Generating Singleton.java

执行该命令后，会在该目录下生成反编译的 .java 文件：

public final class Singleton extends Enum
{

    public static Singleton[] values()
    {
        return (Singleton[])$VALUES.clone();
    }

    public static Singleton valueOf(String name)
    {
        return (Singleton)Enum.valueOf(cn/sail/singleton/enums/Singleton, name);
    }

    private Singleton(String s, int i)
    {
        super(s, i);
    }

    public static final Singleton INSTANCE;
    private static final Singleton $VALUES[];

    static 
    {
        INSTANCE = new Singleton("INSTANCE", 0);
        $VALUES = (new Singleton[] {
            INSTANCE
        });
    }
}

从这里可以看到，确实是没有无参构造，而是存在一个有参构造：

private Singleton(String s, int i) {
    super(s, i);
}

按照有参构造再使用反射创建：

Singleton instance1 = Singleton.INSTANCE;
Constructor<Singleton> declaredConstructor = Singleton.class.getDeclaredConstructor(String.class, int.class);
declaredConstructor.setAccessible(true);
Singleton instance2 = declaredConstructor.newInstance();
System.out.println(instance1 == instance2);

此时运行也报错，但报的错不一样了：

Exception in thread "main" java.lang.IllegalArgumentException: Cannot reflectively create enum objects

这就是希望得到的结果：不能用反射破坏枚举。

那么这个报错是怎么实现的呢，其实很简单。

来看下反射中 Constructor 的 newInstance() 源码：

@CallerSensitive
public T newInstance(Object ... initargs) throws InstantiationException, IllegalAccessException, IllegalArgumentException, InvocationTargetException {
    if (!override) {
        if (!Reflection.quickCheckMemberAccess(clazz, modifiers)) {
            Class<?> caller = Reflection.getCallerClass();
            checkAccess(caller, clazz, null, modifiers);
        }
    }
    if ((clazz.getModifiers() & Modifier.ENUM) != 0)
        throw new IllegalArgumentException("Cannot reflectively create enum objects");
    ConstructorAccessor ca = constructorAccessor;
    if (ca == null) {
        ca = acquireConstructorAccessor();
    }
    @SuppressWarnings("unchecked")
    T inst = (T) ca.newInstance(initargs);
    return inst;
}

可以看到，如果类为反射类，就会直接报错。

这就从底层就避免了反射对枚举实现单例的破坏，是最直接也是最有效的手段。

所以，枚举实现是最完美的单例模式。

它极致简洁，自动支持序列化机制，绝对防止多次实例化。

它不仅能避免多线程同步问题，而且还自动支持序列化机制，防止反序列化重新创建新的对象，避免多次实例化。

最让人感动的是，它不会被反射破坏！

这种方式也是 《Effective Java》 作者 Josh Bloch 提倡的方式。

但因为必须 JDK 1.5 及之后的版本才支持这种方式，所以还没有被广泛采用，但这确实是实现单例模式的最佳方法。

标签：Singleton,01,public,INSTANCE,static,单例,设计模式,class
来源： https://www.cnblogs.com/codesail/p/16460384.html