23种设计模式-单例模式

设计模式概述

设计模式是前辈们对代码开发经验的总结，是解决特定问题的一系列套路，它并不是语法规定，而是一套用来提高代码可复用性、可维护性、可读性、稳健性以及安全性的解决方案。

1995年，GoF合作出版了《设计模式：可复用面向对象软件的基础》，本书一共收录了23种设计模式，从此树立了软件模式领域的里程碑，人称GoF设计模式。

设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性、多态性以及类的关联关系和组合关系的充分理解。

正常使用设计模式具有以下优点：

• 可以提高程序员的思维能力，编程能力和设计能力
• 使得程序设计更加标准化，代码编制更加工程化，使软件开发效率大大提高，从而缩短软件的开发周期
• 使设计的代码可重用性高，可读性强，可靠性高，灵活性好，可维护性强

设计模式的基本要素：

• 模式名称
• 问题
• 解决方案
• 效果

GoF23

创建型模式：

单例模式、工厂模式、抽象工厂模式、建造者模式、原型模式

结构型模式：

适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式

行为型模式：

模板方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、职责链模式、访问者模式

OOP七大原则

开闭原则： 对扩展开放，对修改关闭

里式替换原则： 继承必须确保超类所拥有的性质在子类中仍然成立

依赖倒置原则： 要面向接口编程，不要面向实现编程

单一职责原则： 控制类的粒度大小、将对象解耦、提高其内聚性

接口隔离原则： 要为各个类建立它们需要的专用接口

迪米特法则： 只与你的“直接朋友”交谈，不跟“陌生人”讲话（A类和C类尽量避免直接沟通）

合成复用原则： 尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现

单例模式

单例模式（Singleton Pattern）是 Java 中最简单的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。

这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。

注意：

• 1、单例类只能有一个实例。
• 2、单例类必须自己创建自己的唯一实例。
• 3、单例类必须给所有其他对象提供这一实例。

饿汉式单例

这种方式比较常用，但容易产生垃圾对象。
优点：没有加锁，执行效率会提高。
缺点：类加载时就初始化，浪费内存。
它基于 classloader 机制避免了多线程的同步问题，不过，instance 在类装载时就实例化，虽然导致类装载的原因有很多种，在单例模式中大多数都是调用 getInstance 方法， 但是也不能确定有其他的方式（或者其他的静态方法）导致类装载，这时候初始化 instance 显然没有达到 lazy loading 的效果。

// 饿汉式单例
public class Hungry {
    private Hungry() {
    }
    private final static Hungry HUNGRY = new Hungry();
    private static Hungry getInstance() {
        return HUNGRY;
    }
}

懒汉式单例

这种方式具备很好的 lazy loading，能够在多线程中很好的工作，但是，效率很低，99% 情况下不需要同步。
优点：第一次调用才初始化，避免内存浪费。
缺点：必须加锁 synchronized 才能保证单例，但加锁会影响效率。
getInstance() 的性能对应用程序不是很关键（该方法使用不太频繁）。

// 懒汉式单例
public class Lazy {
    private Lazy() {
        System.out.println((Thread.currentThread().getName()) + "ok");
    }
    // volatile防止指令重排
    // 因为lazy = new Lazy();并不是一个原子性操作
    private volatile static Lazy lazy;
    public static Lazy getInstance() {
        // 双重检测模式 懒汉式单例 DLC懒汉式
        if (lazy == null) {
            synchronized (Lazy.class) {
                if (lazy == null) {
                    lazy = new Lazy();
                }
                return lazy;
            }
        }
        return lazy;
    }
    // 如果不加锁，在多线程下会出现问题
    public static void main(String[] args) {
        for (int i = 0; i < 10; i++) {
            new Thread( () -> {
                Lazy.getInstance();
            }).start();
        }
    }
}

值得注意的是，new Lazy并不是一个原子操作！假设实例化一个对象需要以下有三个各步骤，分别是分配空间内存你，执行构造方法，初始化对象，把这个对象指向内存空间。一般我们需要程序按照步骤一步一步来，但是在多线程下会有可能出现并不按照步骤行的情况，所以需要加入volatile关键字防止指令重排。

通过方法来获取单例对象，一般来说返回的都是相同的对象，但是我们可以通过反射机制来进行破坏。

由以下例子便可得出，通过反射获取的对象和单例对象并不是同一个对象。

LazyReflection instacne = LazyReflection.getInstance();
Constructor<LazyReflection> declaredConstructor = LazyReflection.class.getDeclaredConstructor(null);
declaredConstructor.setAccessible(true); // 无视私有的构造器
// 通过反射创建对象
LazyReflection lazy = declaredConstructor.newInstance();
System.out.println(instacne.hashCode());
System.out.println(lazy.hashCode());

那如何避免这样的破坏呢？我们可以看到，反射获取的构造器走的是无参构造器，我们可以在无参构造器中增加一个判断（三重检测）！

private LazyReflection() {
    synchronized (LazyReflection.class) {
        if (lazy != null) {
            throw new RuntimeException("你不能通过反射机制破坏单例！");
        }
    }
}

不过道高一尺魔高一丈，反射机制的强大仍然可以通过多种方式破坏单例，这个时候我们就可以使用枚举来反制反射！

枚举

枚举(Enumerate)是什么？其实，枚举本身也是一个Class类！在枚举中的对象默认为是单例的。在IDEA的out文件下，我们可以看到EnumSingle类是有一个无参构造器的，并且我们还可以看到，在newInstance方法中，有这样一段代码：

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

这就意味着，当通过反射去破坏单例时，会抛出一个异常，并打印异常信息"Cannot reflectively create enum objects"，了解这些之后，那我们可以尝试着通过反射去破坏单例。

public enum EnumSingle {
    INSTANCE;
    public EnumSingle getInstance() {
        return INSTANCE;
    }
}
class Test {
    public static void main(String[] args) throws Exception {
        Constructor<EnumSingle> declaredConstructor 
            = EnumSingle.class.getDeclaredConstructor(null);
        declaredConstructor.setAccessible(true);
        EnumSingle enumSingle = declaredConstructor.newInstance();
        System.out.println(enumSingle);
    }
}

但结果打印的并不是我们想要看到的异常信息，难道是EnumSingle下并没有无参构造器吗？

我们试着使用cmd工具，使用javap -p EnumSingle指令将class文件还原为java文件。

Compiled from "EnumSingle.java"
public final class com.expend.EnumSingle extends java.lang.Enum<com.expend.EnumSingle> {
  public static final com.expend.EnumSingle INSTANCE;
  private static final com.expend.EnumSingle[] $VALUES;
  public static com.expend.EnumSingle[] values();
  public static com.expend.EnumSingle valueOf(java.lang.String);
  private com.expend.EnumSingle();
  public com.expend.EnumSingle getInstance();
  static {};
}

然而，我们仍然看到了无参构造器？难道cmd也出错了？不过至少，我们已经知道了它是一个Class，并且继承Enum类。而我们要进一步得到解决，则需要更加强大的工具。

我们使用jad工具反编译文件，获取源码，这个时候我们可以清楚地看到，它确确实实继承了枚举类，但它的构造器是具有参数的！分别是String和int！

于是我们修改之前的代码，通过反射来获取带String和int参数的构造器，得到的结果便是抛出了"Cannot reflectively create enum objects"的异常信息！

Constructor<EnumSingle> declaredConstructor 
    = EnumSingle.class.getDeclaredConstructor(String.class, int.class);