跟我学设计模式之单例模式

一、设计模式

1.1 设计模式是什么？

设计模式是解决特定问题的一系列套路，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用。其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。
设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解。

1.2 为什么要使用设计模式？

项目的需求是永远在变的，为了应对这种变化，使得我们的代码能够轻易的实现解耦和拓展。

1.3 设计模式类型

创建型模式

创建型模式的主要关注点是怎样创建对象，它的主要特点是将对象的创建与使用分离。这样可以降低系统的耦合度，使用者不需要关注对象的创建细节。

结构型模式

结构型模式描述如何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式，前者采用继承机制来组织接口和类，后者釆用组合或聚合来组合对象。

行为型模式

行为型模式用于描述程序在运行时复杂的流程控制，即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，它涉及算法与对象间职责的分配。它分为类行为模式和对象行为模式，前者采用继承机制来在类间分派行为，后者采用组合或聚合在对象间分配行为。

创建型模式	结构型模式	行为型模式
单例模式、抽象工厂模式、建造者模式、工厂模式、原型模式	适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式	模版方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、职责链模式(责任链模式)、访问者模式

二、面向对象设计的六大设计原则

2.1 开闭原则

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭

解读

用抽象构建框架，用实现扩展细节；
不以改动原有类的方式来实现新需求，而是应该以实现事先抽象出来的接口（或具体类继承抽象类）的方式来实现。

优点

可以在不改动原有代码的前提下给程序扩展功能，增加了程序的可扩展性；
同时也降低了程序的维护成本。

2.2 单一职责原则

一个类只允许有一个职责，即只有一个导致该类变更的原因。

解读

类职责的变化往往就是导致类变化的原因：也就是说如果一个类具有多种职责，就会有多种导致这个类变化的原因，从而导致这个类的维护变得困难；
往往在软件开发中随着需求的不断增加，可能会给原来的类添加一些本来不属于它的一些职责，从而违反了单一职责原则。如果我们发现当前类的职责不仅仅有一个，就应该将本来不属于该类真正的职责分离出去；
不仅仅是类，函数（方法）也要遵循单一职责原则，即：一个函数（方法）只做一件事情。如果发现一个函数（方法）里面有不同的任务，则需要将不同的任务以另一个函数（方法）的形式分离出去。

优点

提高代码的可读性，更实际性地更降低了程序出错的风险；
有利于bug的追踪，降低了程序的维护成本。

2.3 依赖倒置原则

依赖抽象，而不是依赖实现;
抽象不应该依赖细节；细节应该依赖抽象;
高层模块不能依赖低层模块，二者都应该依赖抽象。

解读

面向接口编程，而不是面向实现编程；
尽量不要从具体的类派生，而是以继承抽象类或实现接口来实现；
关于高层模块与低层模块的划分可以按照决策能力的高低进行划分。业务层自然就处于上层模块，逻辑层和数据层自然就归类为底层。

优点

通过抽象来搭建框架，建立类和类的关联，以减少类间的耦合性；
以抽象搭建的系统要比以具体实现搭建的系统更加稳定，扩展性更高，同时也便于维护。

里氏替换原则

子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说，子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。

2.4 接口隔离原则

多个特定的客户端接口要好于一个通用性的总接口。

解读

客户端不应该依赖它不需要实现的接口；
不建立庞大臃肿的接口，应尽量细化接口，接口中的方法应该尽量少。

注意：接口的粒度也不能太小。如果过小，则会造成接口数量过多，使设计复杂化。

优点

避免同一个接口里面包含不同类职责的方法，接口责任划分更加明确，符合高内聚低耦合的思想。

2.5 迪米特法则（最少知道原则）

一个对象应该对尽可能少的对象有接触，也就是只接触那些真正需要接触的对象。

解读

一个类应该只和它的成员变量，方法的输入，返回参数中的类作交流，而不应该引入其他的类（间接交流）。

优点

可以良好地降低类与类之间的耦合，减少类与类之间的关联程度，让类与类之间的协作更加直接。

2.6 组合聚合复用原则

所有引用基类的地方必须能透明地使用其子类的对象，也就是说子类对象可以替换其父类对象，而程序执行效果不变。

-解读

在继承体系中，子类中可以增加自己特有的方法，也可以实现父类的抽象方法，但是不能重写父类的非抽象方法，否则该继承关系就不是一个正确的继承关系。

优点

可以检验继承使用的正确性，约束继承在使用上的泛滥。

三、单例模式概念

3.1 单例模式是什么？

单例模式就是在程序运行中只实例化一次，创建一个全局唯一对象。有点像 Java 的静态变量，但是单例模式要优于静态变量：

静态变量在程序启动的时候JVM就会进行加载，如果不使用，会造成大量的资源浪费；
单例模式能够实现懒加载，能够在使用实例的时候才去创建实例。

开发工具类库中的很多工具类都应用了单例模式，比例线程池、缓存、日志对象等，它们都只需要创建一个对象，如果创建多份实例，可能会带来不可预知的问题，比如资源的浪费、结果处理不一致等问题。

3.2 为什么要使用单例模式？

单例模式属于设计模式三大分类中的第一类——创建型模式，跟对象的创建相关。也就是说，这个模式在创建对象的同时，还致力于控制创建对象的数量，是的，只能创建一个实例，多的不要。

👉那么问题来了，我们为什么要控制对象创建的个数？

有些场景下，不使用单例模式，会导致系统同一时刻出现多个状态缺乏同步，用户自然无法判断当前处于什么状态；
通过控制创建对象的数量，可以节约系统资源开销（像线程、数据库连接等）；
全局数据共享。

3.3 单例的实现思路

静态化实例对象；
私有化构造方法，禁止通过构造方法创建实例；
提供一个公共的静态方法，用来返回唯一实例。

四、饿汉模式

在定义静态属性时，直接实例化了对象

4.1 示例

public class HungryMode {

    /**
     * 利用静态变量来存储唯一实例
     */
    private static final HungryMode instance = new HungryMode();

    /**
     * 私有化构造函数
     */
    private HungryMode(){
        // 里面可以有很多操作
    }

    /**
     * 提供公开获取实例接口
     * @return
     */
    public static HungryMode getInstance(){
        return instance;
    }
}

4.2 饿汉模式的优点

由于使用了static关键字，保证了在引用这个变量时，关于这个变量的所以写入操作都完成，所以保证了JVM层面的线程安全。

4.3 饿汉模式的缺点

不能实现懒加载，造成空间浪费：如果一个类比较大，我们在初始化的时就加载了这个类，但是我们长时间没有使用这个类，这就导致了内存空间的浪费。

所以，能不能只有用到 getInstance()方法，才会去初始化单例类，才会加载单例类中的数据。所以就有了：懒汉式。

五、懒汉模式

懒汉模式是一种偷懒的模式，在程序初始化时不会创建实例，只有在使用实例的时候才会创建实例，所以懒汉模式解决了饿汉模式带来的空间浪费问题。

5.1 懒汉模式的一般实现

public class LazyMode {
    /**
     * 定义静态变量时，未初始化实例
     */
    private static LazyMode instance;

    /**
     * 私有化构造函数
     */
    private LazyMode(){
        // 里面可以有很多操作
    }
    /**
     * 提供公开获取实例接口
     * @return
     */
    public static LazyMode getInstance(){
        // 使用时，先判断实例是否为空，如果实例为空，则实例化对象
        if (instance == null) {
            instance = new LazyMode();
        }
        return instance;
    }
}

但是这种实现在多线程的情况下是不安全的，有可能会出现多份实例的情况：

if (instance == null) {
    instance = new LazyMode();
}

假设有两个线程同时进入到上面这段代码，因为没有任何资源保护措施，所以两个线程可以同时判断的 instance 都为空，都将去初始化实例，所以就会出现多份实例的情况。

5.2 懒汉模式的优化

我们给getInstance()方法加上synchronized关键字，使得getInstance()方法成为受保护的资源就能够解决多份实例的问题。

public class LazyModeSynchronized {
    /**
     * 定义静态变量时，未初始化实例
     */
    private static LazyModeSynchronized instance;
    /**
     * 私有化构造函数
     */
    private LazyModeSynchronized(){
        // 里面可以有很多操作
    }
    /**
     * 提供公开获取实例接口
     * @return
     */
    public synchronized static LazyModeSynchronized getInstance(){
        /**
         * 添加class类锁，影响了性能，加锁之后将代码进行了串行化，
         * 我们的代码块绝大部分是读操作，在读操作的情况下，代码线程是安全的
         *
         */
        if (instance == null) {
            instance = new LazyModeSynchronized();
        }
        return instance;
    }
}

5.3 懒汉模式的优点

实现了懒加载，节约了内存空间。

5.4 懒汉模式的缺点

在不加锁的情况下，线程不安全，可能出现多份实例；
在加锁的情况下，会使程序串行化，使系统有严重的性能问题。

懒汉模式中加锁的问题，对于getInstance()方法来说，绝大部分的操作都是读操作，读操作是线程安全的，所以我们没必让每个线程必须持有锁才能调用该方法，我们需要调整加锁的问题。由此也产生了一种新的实现模式：双重检查锁模式。

六、双重检查锁模式

6.1 双重检查锁模式的一般实现

public class DoubleCheckLockMode {

    private static DoubleCheckLockMode instance;

    /**
     * 私有化构造函数
     */
    private DoubleCheckLockMode(){

    }
    /**
     * 提供公开获取实例接口
     * @return
     */
    public static DoubleCheckLockMode getInstance(){
        // 第一次判断，如果这里为空，不进入抢锁阶段，直接返回实例
        if (instance == null) {
            synchronized (DoubleCheckLockMode.class) {
                // 抢到锁之后再次判断是否为空
                if (instance == null) {
                    instance = new DoubleCheckLockMode();
                }
            }
        }
        return instance;
    }
}

双重检查锁模式解决了单例、性能、线程安全问题，但是这种写法同样存在问题：在多线程的情况下，可能会出现空指针问题，出现问题的原因是JVM在实例化对象的时候会进行优化和指令重排序操作。

6.2 什么是指令重排？

private SingletonObject(){
      // 第一步
     int x = 10;
      // 第二步
     int y = 30;
     // 第三步
     Object o = new Object(); 
}

上面的构造函数SingletonObject()，JVM 会对它进行指令重排序，所以执行顺序可能会乱掉，但是不管是那种执行顺序，JVM 最后都会保证所以实例都完成实例化。 如果构造函数中操作比较多时，为了提升效率，JVM 会在构造函数里面的属性未全部完成实例化时，就返回对象。双重检测锁出现空指针问题的原因就是出现在这里，当某个线程获取锁进行实例化时，其他线程就直接获取实例使用，由于JVM指令重排序的原因，其他线程获取的对象也许不是一个完整的对象，所以在使用实例的时候就会出现空指针异常问题。

6.3 双重检查锁模式优化

要解决双重检查锁模式带来空指针异常的问题，只需要使用volatile关键字，volatile关键字严格遵循happens-before原则，即：在读操作前，写操作必须全部完成。

public class DoubleCheckLockModelVolatile {
    /**
     * 添加volatile关键字，保证在读操作前，写操作必须全部完成
     */
    private static volatile DoubleCheckLockModelVolatile instance;
    /**
     * 私有化构造函数
     */
    private DoubleCheckLockModelVolatile(){

    }
    /**
     * 提供公开获取实例接口
     * @return
     */
    public static DoubleCheckLockModelVolatile getInstance(){

        if (instance == null) {
            synchronized (DoubleCheckLockModelVolatile.class) {
                if (instance == null) {
                    instance = new DoubleCheckLockModelVolatile();
                }
            }
        }
        return instance;
    }
}

七、静态内部类模式

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

public class StaticInnerClassMode {

    private StaticInnerClassMode(){

    }

    /**
     * 单例持有者
     */
    private static class InstanceHolder{
        private  final static StaticInnerClassMode instance = new StaticInnerClassMode();

    }

    /**
     * 提供公开获取实例接口
     * @return
     */
    public static StaticInnerClassMode getInstance(){
        // 调用内部类属性
        return InstanceHolder.instance;
    }
}

这种方式跟饿汉式方式采用的机制类似，但又有不同。两者都是采用了类装载的机制来保证初始化实例时只有一个线程。不同的地方：

饿汉式方式是只要Singleton类被装载就会实例化，没有Lazy-Loading的作用；
静态内部类方式在Singleton类被装载时并不会立即实例化，而是在需要实例化时，调用getInstance()方法，才会装载SingletonInstance类，从而完成Singleton的实例化。

类的静态属性只会在第一次加载类的时候初始化，所以在这里，JVM帮助我们保证了线程的安全性，在类进行初始化时，别的线程是无法进入的。

所以这种方式在没有加任何锁的情况下，保证了多线程下的安全，并且没有任何性能影响和空间的浪费。

八、枚举类实现单例模式

因为枚举类型是线程安全的，并且只会装载一次，设计者充分的利用了枚举的这个特性来实现单例模式，枚举的写法非常简单，而且枚举类型是所用单例实现中唯一一种不会被破坏的单例实现模式。

8.1 示例

public class EnumerationMode {
    
    private EnumerationMode(){
        
    }

    /**
     * 枚举类型是线程安全的，并且只会装载一次
     */
    private enum Singleton{
        INSTANCE;

        private final EnumerationMode instance;

        Singleton(){
            instance = new EnumerationMode();
        }

        private EnumerationMode getInstance(){
            return instance;
        }
    }

    public static EnumerationMode getInstance(){

        return Singleton.INSTANCE.getInstance();
    }
}

8.2 适用场合：

需要频繁的进行创建和销毁的对象；
创建对象时耗时过多或耗费资源过多，但又经常用到的对象；
工具类对象；
频繁访问数据库或文件的对象。

九、单例模式的问题及解决办法

除枚举方式外, 其他方法都会通过反射的方式破坏单例

9.1 单例模式的破坏

/**
 * 以静态内部类实现为例
 * @throws Exception
 */
@Test
public void singletonTest() throws Exception {
    Constructor constructor = StaticInnerClassMode.class.getDeclaredConstructor();
    constructor.setAccessible(true);

    StaticInnerClassMode obj1 = StaticInnerClassMode.getInstance();
    StaticInnerClassMode obj2 = StaticInnerClassMode.getInstance();
    StaticInnerClassMode obj3 = (StaticInnerClassMode) constructor.newInstance();

    System.out.println("输出结果为："+obj1.hashCode()+"," +obj2.hashCode()+","+obj3.hashCode());
}

控制台打印：

输出结果为：1454171136,1454171136,1195396074

从输出的结果我们就可以看出obj1和obj2为同一对象，obj3为新对象。obj3是我们通过反射机制，进而调用了私有的构造函数，然后产生了一个新的对象。

9.2 如何阻止单例破坏

可以在构造方法中进行判断，若已有实例, 则阻止生成新的实例，解决办法如下:

public class StaticInnerClassModeProtection {

    private static boolean flag = false;

    private StaticInnerClassModeProtection(){
        synchronized(StaticInnerClassModeProtection.class){
            if(flag == false){
                flag = true;
            }else {
                throw new RuntimeException("实例已经存在，请通过 getInstance()方法获取！");
            }
        }
    }

    /**
     * 单例持有者
     */
    private static class InstanceHolder{
        private  final static StaticInnerClassModeProtection instance = new StaticInnerClassModeProtection();
    }

    /**
     * 提供公开获取实例接口
     * @return
     */
    public static StaticInnerClassModeProtection getInstance(){
        // 调用内部类属性
        return InstanceHolder.instance;
    }
}

测试：

/**
 * 在构造方法中进行判断，若存在则抛出RuntimeException
 * @throws Exception
 */
@Test
public void destroyTest() throws Exception {
    Constructor constructor = StaticInnerClassModeProtection.class.getDeclaredConstructor();
    constructor.setAccessible(true);

    StaticInnerClassModeProtection obj1 = StaticInnerClassModeProtection.getInstance();
    StaticInnerClassModeProtection obj2 = StaticInnerClassModeProtection.getInstance();
    StaticInnerClassModeProtection obj3 = (StaticInnerClassModeProtection) constructor.newInstance();

    System.out.println("输出结果为："+obj1.hashCode()+"," +obj2.hashCode()+","+obj3.hashCode());
}