23种设计模式（1）：单例模式

23种设计模式（1）：单例模式【创建型模式】

在23种设计模式中，我认为单例模式是最简单的一种。然而，有时候越是简单的东西就越容易出现问题。下面就单例设计模式详细探讨一下，如有不对之处，请大家指正。

定义

• 数学与逻辑学中，singleton定义为“有且仅有一个元素的集合”。
• 单例模式最初的定义出现于《设计模式》（艾迪生维斯理, 1994）：“保证一个类仅有一个实例，并提供一个访问它的全局访问点。”
• Java中单例模式的定义：“一个类有且仅有一个实例，并且自行实例化向整个系统提供。”

特点

• 单例类只能有一个实例
• 单例类必须自行创建自身实例的唯一对象
• 单例类必须自行向整个系统提供这个对象

单例模式的几种实现方式探讨

单例模式基本实现思路：
（1）构造器私有化，防止外界通过调用构造方法实例化对象；
（2）提供一个公有的静态方法，只有通过该类提供的静态方法才能得到该类的唯一实例。
注意事项：
单例模式在多线程的应用场合下必须小心使用。

1、饿汉式【可用】

public class Singleton {    private final static Singleton instance = new Singleton();    private Singleton(){}    public static Singleton getInstance(){        return instance ;    }}

优点：这种写法比较简单，就是在类装载的时候就完成实例化。避免了线程同步问题。
缺点：在类装载的时候就完成实例化，没有达到懒加载（延时加载）的效果。如果从始至终从未使用过这个实例，则会造成内存的浪费。

2、懒汉式（线程不安全）【不推荐】

public class Singleton {    private static Singleton singleton;    private Singleton() {}    public static Singleton getInstance() {        if (singleton == null) {            singleton = new Singleton();        }        return singleton;    }}

这种实现方法与上一种实现比较，起到了懒加载（延时加载）的效果，但存在局限性，这种实现只能在单线程的环境下使用。如果在多线程下，一个线程进入了if (singleton == null)判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，这时便会产生多个实例。所以在多线程环境下不可使用这种方式，也不推荐大家使用。

3、懒汉式（线程安全，同步方法）【不推荐】

public class Singleton {    private static Singleton singleton;    private Singleton() {}    public static synchronized Singleton getInstance() {        if (singleton == null) {            singleton = new Singleton();        }        return singleton;    }}

为解决上一种实现方案线程不安全的问题，解决方案就是做个线程同步就可以了，于是就对getInstance()方法进行了线程同步，即对getInstance()方法加同步锁，这就保证了单例的唯一性。
缺点：效率太低了，每个线程在想获得类的实例时候，执行getInstance()方法都要进行同步。

4、双重校验锁【不推荐】

public class Singleton {    private static Singleton singleton;    private Singleton() {}    public static Singleton getInstance() {        if (singleton == null) {            synchronized (Singleton.class) {                if (singleton == null) {                    singleton = new Singleton();                }            }        }        return singleton;    }}

Double-Check概念对于多线程开发者来说并不陌生，如代码中所示，我们进行了两次if (singleton == null)检查，这样就可以保证线程安全了。这样，实例化代码只用执行一次，后面再次访问时，判断if (singleton == null)，直接return实例化对象。这样即保证了线程的安全性，也大大提高了效率，还实现了懒加载的效果。
就这样，我们用一种很聪明的方式实现了单例模式。到此，一切看上去很完美。

5、双重校验锁（改进）【推荐】

在进行改进之前，我们先来聊聊编译原理。什么是编译？编译就是将源代码翻译成目标代码（大多数是机器码）的过程。针对Java来说，是将源代码翻译成Java虚拟机可以识别的代码（即Java字节码）。在编译原理中有一个很重要的内容——编译器优化。所谓编译器优化是指，在不改变原来语义的情况下，通过调整语句顺序，来让程序运行的更快。

我们都知道，JVM是一种用于计算设备的规范，而并非是一种实现。在JVM中并没有规定有关编译器优化的内容，也就是说，JVM可以由不同的厂商来实现，可以自由的进行编译器优化。

接下来我们来思考下，创建变量需要哪些步骤呢？申请一块内存，调用构造方法进行初始化，分配一个指针指向这块内存。这些操作是否存在先后顺序呢？在JVM中其实并没有规定。那么我们是否可以这样假设：JVM是先开辟出一块内存，然后把指针指向这块内存，最后调用构造方法进行初始化。

接下来根据假设来探究以下上一种单例的实现方案：线程A开始创建Singleton的实例，此时线程B调用了getInstance()方法，首先判断singleton是否为null。按照我们上面所说的内存模型，A已经把singleton指向了那块内存，只是还没有调用构造方法，因此B检测到singleton不为null，于是直接把singleton返回了——问题出现了，尽管singleton不为null，但它并没有构造完成。此时，如果B在A将singleton构造完成之前就是用了这个实例，程序就会出现对象未初始化错误了！

public class Singleton {    private static Singleton singleton;    private Singleton() {}    public static Singleton getInstance() {        if (singleton == null) {            //B线程检测到singleton不为空            synchronized (Singleton.class) {                if (singleton == null) {                    singleton = new Singleton();                    //A线程被指令重排了，刚好先赋值了；但还没执行完构造函数。                }            }        }        return singleton;//后面B线程执行时将引发：对象尚未初始化错误。    }}

具体来说就是synchronized虽然保证了原子性，但却没有保证指令重排序的正确性。换句话说，我们的线程虽然可以保证原子性，但程序可能是在多核CPU上执行，从而可能导致这种情况的发生。

在JDK 1.5之后，Java使用了新的内存模型。volatile关键字有了明确的语义（在JDK1.5之前，volatile是个关键字，但是并没有明确的规定其用途），被volatile修饰的写变量不能和之前的读写代码调整，读变量不能和之后的读写代码调整！因此，只要我们简单的把singleton加上volatile关键字就可以了，这样就完美解决问题了。具体实现代码如下：

public class Singleton {    private volatile static Singleton singleton;    private Singleton() {}    public static Singleton getInstance() {        if (singleton == null) {            synchronized (Singleton.class) {                if (singleton == null) {                    singleton = new Singleton();                }            }        }        return singleton;    }}

6、静态内部类/登记式【推荐】

上面我们提到了volatile是在JDK 1.5之后定义的，然而在此之前又是如何实现的呢？其实就是接下来我们所要说的一种解决方案——静态内部类，这种方案并不会受JDK版本的影响。实现如下：

public class Singleton {    private Singleton() {}    private static class SingletonHolder {        private static final Singleton INSTANCE = new Singleton();    }    public static Singleton getInstance() {        return SingletonHolder.INSTANCE;    }}

静态内部类方式在Singleton类被装载时并不会立即实例化，而是在需要实例化时，调用getInstance方法，才会装载SingletonHolder类，从而完成Singleton的实例化。
类的静态属性只会在第一次加载类的时候初始化，所以在这里，JVM帮助我们保证了线程的安全性，在类进行初始化时，别的线程是无法进入的。这一技术是被JVM明确说明了的，因此不存在任何二义性。这种单例模式也是我使用最多的一种实现，也推荐大家使用。

优点：避免了线程不安全，延迟加载，效率高。

7、枚举法【推荐】

public enum Singleton {    INSTANCE;}

采用枚举法实现单例模式，我认为这是一个非常好的想法，上面你这段用enum实现单例模式的代码是我见到的一段十分经典的单例实现。

这么简单的一点代码就实现了一个线程安全的单例，真是将enum的性质运用得淋漓尽致。

enum是由class实现的。enum可以象一般的类一样添加方法和属性,你可以为它添加静态和非静态的属性或方法,这一切都象你在一般的类中做的那样，这也是我们可以用enum作为一个类来实现单例的基础。此外，enum类也不能够被继承，在反编译中，我们会发现该类是final的。

enum有且仅有private的构造器，防止外部的额外构造，这恰好和单例模式吻合。

对于序列化和反序列化，因为每一个枚举类型和枚举变量在JVM中都是唯一的，即Java在序列化和反序列化枚举时做了特殊的规定，枚举的writeObject、readObject、readObjectNoData、writeReplace和readResolve等方法是被编译器禁用的，因此也不存在实现序列化接口后调用readObject会破坏单例的问题。

因此，选择枚举作为Singleton的实现方式，是一种很好的方案，也可以防止反序列化重新创建新的对象。虽然现实中却很少见到这种实现方式，但是我推荐大家使用。

---

常见应用场景

好多没怎么使用过单例模式的人可能会想，单例模式感觉不怎么用到，实际的应用场景有哪些呢？下面，我将列出一些我知道的就在咱们周边和很有意义的单例应用场景。

1. Windows的Task Manager（任务管理器）就是很典型的单例模式（这个很熟悉吧），你可以想想，我们能打开两个任务管理器吗？不信你可以去试试。
2. 网站的计数器，一般也是采用单例模式实现，否则难以同步。
3. windows的回收站也是典型的单例应用。在整个系统运行过程中，回收站一直维护着仅有的一个实例
4. 数据库连接池的设计一般也是采用单例模式，因为数据库连接是一种数据库资源。数据库软件系统中使用数据库连接池，主要是节省打开或者关闭数据库连接所引起的效率损耗，这种效率上的损耗还是非常昂贵的，因为何用单例模式来维护，就可以大大降低这种损耗。
5. 多线程的线程池的设计一般也是采用单例模式，这是由于线程池要方便对池中的线程进行控制。
6. Web应用的配置对象的读取，一般也应用单例模式，这个是由于配置文件是共享的资源。
7. 操作系统的文件系统，也是大的单例模式实现的具体例子，一个操作系统只能有一个文件系统。
8. HttpApplication 也是单例的典型应用。
9. 显卡的驱动程序对象也常被设计成单例等。

单例模式应用的场景一般发现在以下条件下：
　　（1）需要频繁的进行创建和销毁的对象；
　　（2）创建对象时耗时过多或耗费资源过多，但又经常用到的对象；
　　（3）工具类对象；
　　（4）频繁访问数据库或文件的对象等。

总结

这篇文章是我在学习了单例模式，借鉴别人的一些观点后总结写下的，希望对大家有些帮助。文章中如有不正确、或需要补充的地方，请大家留言指正，也可以给我发邮件【[e-mail]】。