【设计模式-1】图文并茂：单例模式的使用场景及7种代码实现

 接上一篇：【设计原则】程序设计7大原则

1.什么是单例模式

 在了解单例模式前，我们先来看一下它的定义：

确保一个类只有一个实例，而且自行实例化并且自行向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方法，单例模式是一种对象的创建型模式。

 可以看到在定义中，提到了3个要素：

1. 某一个类（单例类）只能有一实例；
2. 单例类必须自行创建这个实例；
3. 单例类必须向整个系统提供这个唯一的实例。

 OK，有了这三点，其实就把创建单例模式的步骤罗列出来了，我们先看一下单例模式的类图，有个模糊的概念。

 类图还是比较简单清晰的，自关联关系，下面我们来看下为什么要用单例模式呢？

2. 为什么用单例模式

 单例模式其实是很简单的一种模式，代码也很好实现，但是我在学习单例模式的时候，一直对它怎么使用比较模糊，这里涉及到两个疑问点，一是为什么要用单例模式，二是需在哪些场景下用单例模式呢？
 要搞清楚这两个问题，我们先从单例模式最常用的一个场景说起，就是线程池工具类，相信很多人都用过。我们看一下线程池的使用场景，在之前不使用线程池的时候，程序每次要执行一个现成任务，就会new一个新的线程，然后执行任务，再销毁线程。这个过程中，线程的创建和销毁对系统资源的开销是巨大的，如果使用线程池呢，在这个池中，始终维护一部分存活的线程，循环执行我们的任务，达到减少资源开销的目的。

ThreadPoolExecutor INSTANCE = new ThreadPoolExecutor(int corePoolSize,
                                int maximumPoolSize,
                                long keepAliveTime,
                                TimeUnit unit,
                                BlockingQueue<Runnable> workQueue,
                                ThreadFactory threadFactory,
                                RejectedExecutionHandler handler);

 在工具类中，我们会通过 ThreadPoolExecutor这个执行器创建线程池，在一个系统中，应该存在1个或者少量的线程池，多个任务复用池中的线程就可以。假设就以1个例，要复用这1个池中的多个线程，线程池必须有1份，否则每次调用工具类，都会new ThreadPoolExecutor创建1个线程池，也会伴随多个线程的创建和销毁动作，在用完里面的线程后就再也不用了，那线程池就没存在的意义了，既占用了系统的内存资源，又不符合业务场景，所以这里使用单例模式来维护唯一的线程池就很有必要了。
 看到这里，为什么要使用单例模式就比较清晰了，单个对象复用可以减少系统资源消耗，对于一些需要频繁创建和销毁的对象，使用单例模式无疑可以提高系统的整体性能。
 站在应用场景来看，一个类能不能做成单例，最容易区分的地方就在于，如果存在两个或两以上的实例会造成错误或业务场景上的歧义，也就是这个类在整个应用中，某一个时刻应该只有一个状态体现。那么除了刚才线程池工具类的例子，还有那些实际的应用场景呢？比如：操作系统中的“任务管理器”，“回收站”，网站的“计时器”，或者自定义数据库表的“自增主键计数器”等等，而且spring中的bean默认也是单例的。

3.单例模式的7种代码实现

 单例模式的代码实现有很多种，相信大家也都听过懒汉式与饿汉式，以及饿汉式下面的线程安全问题，其实真正开发中只要熟悉一到两种就可以，但是面试时经常被问到各种写法，接着就来看下这几种代码实现的写法吧。

3.1 饿汉式

• 优点：类初始化时就创建此唯一的实例，不存在并发问题，能保证实例的唯一性。
• 缺点：没有起到延迟加载的效果，如果此实例在整个应用声明周期中都不使用，会造成系统资源浪费。
• 代码：

public class Singleton {

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

    // 2.自行创建这个实例
    private static Singleton instance = new Singleton();

    // 3.提供外部可以访问的此实例的方法
    public static Singleton getInstance() {
        return instance;
    }
}

3.2 懒汉式-原始版本

• 优点：效率高，延迟加载
• 缺点：存在线程安全问题，并发场景下可能会创建多份实例，只能在单线程场景下使用
• 代码：

public class Singleton {

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

    // 2.自行创建这个实例
    private static Singleton instance = null;

    // 3.自行提供外部访问此实例的方法
    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

 在多线程场景下，如果有两个现成同时执行到了 instance == null 且都成立，会重复创建实例。

3.3 懒汉式-线程安全版本

• 优点：可以保证线程安全和实例的唯一性。
• 缺点：锁住了整个获取实例的方法，效率较低。
• 代码：

public class Singleton {

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

    // 2.自行创建这个实例
    private static Singleton instance = null;

    // 3.自行提供全局访问此实例的方法
    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

3.4 懒汉式-效率提升版本

• 优点：锁范围变小，延迟加载
• 缺点：仍然存在现成不安全的问题
• 代码：

public class Singleton {

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

    // 2.自行创建这个实例，注意用volatile修饰
    private static Singleton instance = null;

    // 3.自行给全局提供访问此实例的方法
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                instance = new Singleton();
            }
        }
        return instance;
    }
}

 这里虽然锁住了实例创建的代码片段，但是如果存在多个线程都进入到if (instance == null) {}判断里面，且等待锁释放的状态，也会造成创建多个实例的问题，是线程不安全的。

3.5 懒汉式 - 双重判断版

• 优点：延迟加载，线程安全，锁定范围小
• 缺点：代码略显复杂，可读性略低，其实可以忽略
• 代码：

public class Singleton {

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

    // 2.自行创建这个实例
    private static volatile Singleton instance = null;

    // 3.自行给全局提供访问此实例的方法
    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

 由于存在双重判断，即便后来等待的线程持有锁之后，也会再次判断此实例是否已创建，但是要需要注意用volatile修饰，volatile 的作用主要是禁止指定重排序。假设在不使用 volatile 的情况下，两个线程A、B，都是第一次调用该单例方法，线程A先执行 singleton = new Singleton()，但由于构造方法不是一个原子操作，编译后会生成多条字节码指令，由于 JAVA的 指令重排序，可能会先执行 singleton 的赋值操作，该操作实际只是在内存中开辟一片存储对象的区域后直接返回内存的引用，之后 singleton 便不为空了，但是实际的初始化操作却还没有执行。如果此时线程B进入，就会拿到一个不为空的但是没有完成初始化的singleton 对象，所以需要加入volatile关键字，禁止指令重排序优化，从而安全的实现单例。

3.6 静态内部类方式

• 优点：线程安全，利用静态内部类的初始化创建实例，实现延迟加载，效率高。
• 代码：

public class Singleton {

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

    // 2.自行创建这个唯一的实力
    private static class SingletonInstance {
        private static final Singleton INSTANCE = new Singleton();
    }

    // 3.自行给全局提供访问这个实例的方法
    public static Singleton getInstance() {
        return SingletonInstance.INSTANCE;
    }
}

3.7 枚举实现

• 代码：

public enum SingletonEnum {
    
    INSTANCE;

    public String method() {
        return "what you need!";
    }
}

 枚举类的实现方式可以说是单例模式的最佳实践，在《Effective Java》这本书中，作者就提到“单元素的枚举类型已经成为实现Singleton的最佳方法”。
 枚举类的实现方式不仅可以解决上面所述的所有问题，还可以防止通过反射和反序列化来重复创建新的实例，Java虚拟机天然可以保证枚举对象的唯一性，在很多优秀的框架中，经常可以看到通过枚举实现的单例模式。

4.总结

 单例模式作为一种目标明确、结构简单、理解容易的设计模式，在开发工作中使用的频率相当的高，写在最后，简单总结一下单例模式的优缺点。

4.1 优点

1. 单例模式提供了唯一实例的访问权限，可以限制客户端如何它；
2. 对象的唯一性可以减少频繁创建和销毁对象过程，能够节省系统资源；
3. 基于单例模式，可以扩展出指定个数的多例对象，即多例类，灵活性也很高。

4.2 缺点

1. 单例模式没有抽象层，只有实现层，因此扩展困难；
2. 在一定程度上为了单一职责，因为单例模式既提供了对象的创建职责，又提供了业务方法，导致创建过程和业务功能耦合在一块。
3. 部分垃圾回收机制会回收长时间不用的对象，这将导致单例对象有被销毁的风险，下次使用重新被实例化，违背了单例模式的初衷（此条不太理解，有待验证，摘抄自《设计模式艺术》）。

 下一遍链接：【设计模式-2】简单工厂模式的代码实现及使用场景