单例模式（Singleton Pattern）

前言

:smile: 按照 001 篇讲的，以后的每个模式都将按照：模式名称、问题、解决方案以及效果这几个主要的要素研究。

• 学习难度：:smirk::smirk::smirk::smirk::smirk:
• 使用频率：:wink::wink::wink::wink::wink:

开始吧

模式名称

中文：单例模式

English: Singleton Pattern

含义：单例对象的类必须保证只有一个实例存在。

问题

何时使用

当我们需要统一管理资源，共享资源的时候就需要使用单例模式。保障

场景：

1. Windows的Task(任务管理器) 就是很经典的单例模式。一台电脑正常情况下只能打开一个任务管理器。
2. 网站的计数器，一般也采用单例模式实现，否则难以同步。
3. 应用程序的日志应用，一般都才会用单例模式实现，这通常是由于共享的日志文件一直处于打开状态，因为只能有一个实例去操作，否则内容不好追加。
4. Web应用的配置对象的读取，一般也应用单例模式，这个是由于配置文件是共享的资源。
5. 数据库连接池的设计一般也是采用单例模式，因为数据库连接是一种数据库资源。数据库软件系统中使用数据库连接池，主要是节省打开或者关闭数据库连接所引起的效率损耗，这种效率上的损耗还是非常昂贵的，因为何用单例模式来维护，就可以大大降低这种损耗。
6. 多线程的线程池的设计一般也是采用单例模式，这是由于线程池要方便对池中的线程进行控制。
7. 操作系统的文件系统，也是大的单例模式实现的具体例子，一个操作系统只能有一个文件系统。
8. HttpApplication 也是单例的典型应用。熟悉ASP.Net(IIS)的整个请求生命周期的人应该知道HttpApplication也是单例模式，所有的HttpModule都共享一个HttpApplication实例.

存在的问题

• 优点
  • 单例模式提供了唯一实例的受控访问，因为单例模式封装了他的唯一实例，所以他可以严格控制客户怎样以及何时访问它。
  • 由于系统中只存在一个资源，对于一些需要频繁创建和销毁的对象单例模式可以提高性能。
  • 允许可变数目的实例。基于单例模式我们可以进行扩展，使用与单例模式相似的方法来来获得指定个数的对象实例，既节省系统资源，又解决了单例对象共享过多有损性能的问题。
• 缺点
  • 由于单例模式没有抽象层，因此单例类的扩展有很大的困难。
  • 单例类的职责过重，在一定程度上违背了‘单一职责的原则’。因为单例类既承担了工厂的角色，提供了工厂方法，又充当了产品的角色，包含了一些业务方法，将产品的创建和产品本身的功能融合到一起。
  • 现在很多面相对象语言的运行环境都提供了自动垃圾回收的技术，因此，如果实例化的共享对象长时间不被利用，系统会认为他是垃圾，自动销毁回收。下次使用时再重新实例化，这将导致共享的单例对象状态的丢失。

请带着问题找答案:stuck_out_tongue_winking_eye:。

解决方案

来个UML图先

Singleton UML

( Singleton UML )

科普一下：什么叫懒汉模式，什么叫饿汉模式

• 懒汉模式 --> 特点是懒，不用的时候我就睡觉（不实例化）。
• 饿汉模式 --> 特点是饿，一上来我就要吃（实例化）。

最简单的实现方法

// 懒汉，你不调用getInstance() 就不会实例化
public class Singleton {
    private static Singleton instance;
    public static Singleton getInstance() {
         if (instance == null) {
             instance = new Singleton();
         }
         return instance;
     }
}复制代码

解析：这是一个最简单的实现方法。通过 getInstance() 获取 Singleton 这个类的实例。instance == null 的情况下 new 一个实例。不为空就返回这个实例。可以说，这个方法最适合教学，一眼就能看的很明白什么是单例。

BUT , 想一想，我是不是在外面也能 通过 new Singleton() 来创建一个实例 ？那都是多个实例了。还怎么单例？

So ,我们要开始进阶了。脱离学生手法，开始进阶。

// 懒汉，你不调用getInstance() 就不会实例化
public class Singleton {
    private static Singleton instance;
    public static Singleton getInstance() {
         if (instance == null) {
             instance = new Singleton();
         }
         return instance;
     }
     // add 1.1 begin (将构造方法私有化)
     private Singleton() {
     }
     // add 1.1 end
}复制代码

经过 v1.1 版本的改造。发现在外面再也 new 不出来 Singleton 的实例。:stuck_out_tongue: 我学会了？给你个眼神:smirk:

我们再想：两个线程几乎同时调用 getInstance() 第一个进入的线程判断 instance 为空，开始走这一行 instance = new Singleton();。,注意，是开始走这一行，并未完成实例化！ 此时第二个线程也走到 if (instance == null)此时判断也为空。那么 这两个线程都会得到一个新的实例，那么就产生两个实例。那么还怎么单例？

以上为懒汉模式 -- （线程不安全）

懒汉模式 - 线程安全

为了解决 上面那个方法在多线程下使用不安全的问题。我们再次进阶。
这次吊了�这从线程安全了！

我反手就给你一段代码

// 懒汉，你不调用getInstance() 就不会实例化
public class Singleton {
    private static Singleton instance;
    // modif synchronized
    public static synchronized  Singleton getInstance() {
         if (instance == null) {
             instance = new Singleton();
         }
         return instance;
     }
     // add 1.1 begin (将构造方法私有化)
     private Singleton() {
     }
     // add 1.1 end
}复制代码

看，加一个synchronized同步，来一个要等着。等里面的代码执行完了，第二个线程再进去。第二个再进去的时候，instance就不是空了，就又能单例了。��


Too young。这样搞的话，我们每次进来都可能要同步一下。多数时候我们并不是两个或多个线程同时来访问，我们并不需要去同步。这样做其实造成了不必要的开销。有木有更好的方法呢？

Double Checked locking pattern 【 双重检验锁 】

我反手又是一串代码（关键代码）

只贴上关键代码。才好

public static Singleton getInstance() {
    if (instance == null) {               //Single Checked
        synchronized (Singleton.class) {
            if (instance == null) {       //Double Checked
                instance = new Singleton();
            }
        }
    }
    return instance ;
}复制代码

看到没，你想到这样搞了吗？ 先检测再同步。Single Checked足以应付多数检测。当一个以上的线程同时访问时就用上了Double Checked防止多线程下重复创建实例。 �即使我们这么想到这么吊的方法，还是不行。。。为啥？

为啥？ instance = new Singleton() 这个不是原子操作。当我们 new 的时候 JVM 大概做了这些事：

1. 给instance分配内存
2. 调用 Singleton的构造函数，来初始化成员变量
3. 将instance对象指向分配的内存空间（执行完这步 instance 就不为 null 了）

但是在 JVM 的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能保证的，最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是后者，则在 3 执行完毕、2 未执行之前，被线程二抢占了，这时 instance 已经是非 null 了（但却没有初始化），所以线程二会直接返回 instance，然后使用，然后顺理成章地报错。

解决方法也很简单:加上 volatile 就可以了。使用 volatile 的主要原因是其一个特性：禁止指令重排序优化

 private volatile static Singleton instance; //声明成 volatile复制代码

注意： 在 Java 5 以前的版本使用了 volatile 的双检锁还是有问题的。其原因是 Java 5 以前的 JMM （Java 内存模型）是存在缺陷的，即时将变量声明成 volatile 也不能完全避免重排序，主要是 volatile 变量前后的代码仍然存在重排序问题。这个 volatile 屏蔽重排序的问题在 Java 5 中才得以修复，所以在这之后才可以放心使用 volatile。

---

注解
原子操作： 如果这个操作所处的层(layer)的更高层不能发现其内部实现与结构，那么这个操作是一个原子(atomic)操作。
原子操作可以是一个步骤，也可以是多个操作步骤，但是其顺序不可以被打乱，也不可以被切割而只执行其中的一部分。
将整个操作视作一个整体是原子性的核心特征。

这个方法解决了上面所有的不安全因素，但是！在 Java 5 以前的版本上跑却还是会有问题，所以，这个也不是最好的方法。。。

饿汉来了

�

public class Singleton {  
    private static Singleton instance = new Singleton();
    private Singleton (){}
    public static Singleton getInstance() {
      return instance;
    }复制代码

是这样的，因为单例的实例 instance 被声明称 static 和 final 了，在第一次加载类到内存中就会被实例化。所以创建实例本身是线程安全的。一上来就加载，所以是饿汉。

缺点：太着急加载。有时候我们想加点料也不给机会。有时候我们创建实例需要依赖参数或者配置文件。这样就不能使用饿汉模式。�

怎么办？

内部静态类

先瞅代码

public class Singleton {
    private static class SingletonHolder {
        private static final Singleton INSTANCE = new Singleton();
    }
    private Singleton() {}
    public static final Singleton getInstance(int a) {
        return SingletonHolder.INSTANCE;
    }
}复制代码

由于 SingletonHolder 是私有的，除了 getInstance() 之外没有办法访问它，因此它是懒汉式的；同时读取实例的时候不会进行同步，没有性能缺陷；也不依赖 JDK 版本。能完美应对多数场景。如果你觉得写着麻烦，其实还有这一种很简单的写法。好像不太常用。就是下面这个枚举

枚举单例

《Effective Java》:单元素的枚举类型已经成为实现Singleton的最佳方法

public enum Singleton {
     //理解为 public static final Singleton INSTANCE;
     INSTANCE;
 }复制代码

实例化：Singleton.INSTANCE 就是这么简单。但是单例这样用的人我觉得还是不多。猜想是大家对枚举了解不太多吧。如果看到枚举这个方式一脸懵B，就看看枚举相关的知识。反正我一开始也是一脸**

效果

以上介绍了：

• 简单写法（入门）
• 懒汉模式线程安全
• 双重检验锁（DLC）
• 饿汉模式
• 内部静态类
• 枚举

几种方法不重要。最重要的知道什么是单例模式，为啥用单例。甚至不在代码中使用，工作、生活、学习、游戏中充满单例思想。掌握这个思想以及解决办法，生活会很精彩��

再说一下：《Effective Java》推荐 DLC 和枚举，那些明显有问题的写法就不要用了。那些写法都是用来教学理解单例的。

---

更新中：
1. 什么是设计模式
2. 单例模式
3. 简单工厂模式
GitHub汇总：这里总是最新的
看完给个star鼓励一下