转载

Java设计模式-单例模式（Singleton Pattern）

定义

单例模式是一个比较"简单"的模式，其定义如下：

保证一个类仅有一个实例，并提供一个访问它的全局访问点。

或者

确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。

请注意"简单"二字的双引号，说它简单它也简单，但是要想用好、用对其实并不那么简单，为什么这么说？

首先，单例模式的定义比较好理解，应用场景明确，实现思路比较简单；
其次，单例模式其实要考虑的因素很多，诸如延迟加载、线程安全以及破坏单例的情况等等。也正是这些因素导致单例模式的实现方式多样，且各有利弊

特点

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

基本步骤

私有的静态成员变量：在本类中创建唯一实例，使用静态成员变量保存；为保证安全性，私有化这个成员变量
私有的构造方法：避免其他类可以直接创建单例类的对象
公有的静态方法：供其他类获取本类的唯一实例

考虑的因素

延迟加载
线程安全
破坏单例的情况
- 序列化
  
  如果Singleton类是可序列化的，仅仅在生声明中加上implements Serializable是不够的。为了维护并保证Singleton，必须声明所有实例域都是瞬时（transient）的，并且提供一个readResolve方法。否则，每次反序列化一个序列化的实例时，都会创建一个新的对象。
- 反射
  
  授权的客户端可以通过反射来调用私有构造方法，借助于AccessibleObject.setAccessible方法即可做到。如果需要防范这种攻击，请修改构造函数，使其在被要求创建第二个实例时抛出异常。
```
private Singleton() { 
        System.err.println("Singleton Constructor is invoked!");
        if (singleton != null) {
            System.err.println("实例已存在，无法初始化！");
            throw new UnsupportedOperationException("实例已存在，无法初始化！");
        }
    }
}
```
- 对象复制
  
  在Java中，对象默认是不可以被复制的，若实现了Cloneable接口，并实现了clone方法，则可以直接通过对象复制方式创建一个新对象，对象复制是不用调用类的构造函数，因此即使是私有的构造函数，对象仍然可以被复制。在一般情况下，类复制的情况不需要考虑，很少会出现一个单例类会主动要求被复制的情况，解决该问题的最好方法就是单例类不要实现Cloneable接口。
- 类加载器
  
  如果单例由不同的类装载器装入，那便有可能存在多个单例类的实例。

实现方式

1、懒汉式

线程不安全（适用于单线程）

public class Singleton {
    private static Singleton singleton;

    private Singleton() {
    }

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

优点：延迟加载
缺点：线程不安全，多线程环境下有可能产生多个实例

为解决懒汉式"线程安全问题"，可以将getInstance()设置为同步方法，于是就有了第二种实现方式：

线程安全

public class Singleton {
    private static Singleton singleton;

    private Singleton() {
    }

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

优点：延迟加载，并且线程安全
缺点：效率很低，99%的情况下其实是不需要同步的

2、饿汉式

public class Singleton {
    private static Singleton singleton = new Singleton();

    private Singleton() {
    }

    public static Singleton getInstance() {
        return singleton;
    }
}

优点：线程安全，实现简单
缺点：没有延迟加载，类加载的时候即完成初始化，可能在一定程度上造成内存空间的浪费

如果不是特别需要延迟加载的场景，可以优先考虑饿汉式

3、双重检查锁

public class Singleton {
    private static volatile Singleton singleton;

    private Singleton() {
    }

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

优点：延迟加载，线程安全，并且效率也很不错
缺点：实现相对复杂一点，JDK1.5以后才支持volatile
说明
- 将同步方法改为同步代码块
- 第一个判空是为了解决效率问题，不需要每次都进入同步代码块
- synchronized (Singleton.class)是为了解决线程安全问题
- 第二个判空是避免产生多个实例
- volatile修饰符是禁止指令重排序

这里针对volatile多说两句，很多书上和网上的双重检查锁实例都没有加volatile，事实上这是不正确的

首先，volatile的两层含义：

内存可见性
禁止指令重排

这里我们用到的主要是第二个语义。那么什么是指令重排序呢，就是指编译器和处理器为了优化程序性能而对指令序列进行排序的一种手段。简单理解，就是编译器对我们的代码进行了优化，在实际执行指令的的时候可能与我们编写的顺序不同，只保证程序执行结果与源代码相同，却不保证实际指令的顺序与源代码相同。

singleton = new Singleton();

这段代码在jvm执行时实际分为三步：

在堆内存开辟一块内存空间；
在堆内存实例化Singleton
把对象（singleton）指向堆内存空间

由于"指令重排"的优化，很可能执行步骤为1-3-2，即：对象并没有实例化完成但引用已经是非空了，也就是在第二处判空的地方为false，直接返回singleton——一个未完成实例化的对象引用。

这里涉及到Java内存模型、内存屏障等知识点，本文主要介绍单例模式，因此不再赘述，有兴趣的同学可以自行百度

4、静态内部类

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

    private Singleton() {
    }

    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
}

与饿汉式的区别是，静态内部类SingletonHolder只有在getInstance()方法第一次调用的时候才会被加载（实现了延迟加载效果）。

因此静态内部类实现方式既能保证线程安全，也能保证单例的唯一性，同时也具有延迟加载特性

5、枚举

public enum  Singleton {
    INSTANCE;
    public void doSomething() {
        System.out.println("doSomething");
    }
}

优点：枚举方式具有以上所有实现方式的优点，同时还无偿地提供了序列化机制，防止多次实例化

缺点：JDK1.5以后才支持enum；普及度较前几种方式不高

优点

由于单例模式在内存中只有一个实例，减少了内存开支，特别是一个对象需要频繁地创建、销毁时，而且创建或销毁时性能又无法优化，单例模式的优势就非常明显。
由于单例模式只生成一个实例，所以减少了系统的性能开销，当一个对象的产生需要比较多的资源时，如读取配置、产生其他依赖对象时，则可以通过在应用启动时直接产生一个单例对象，然后用永久驻留内存的方式来解决（在Java EE中采用单例模式时需要注意JVM垃圾回收机制）。
单例模式可以避免对资源的多重占用，例如一个写文件动作，由于只有一个实例存在内存中，避免对同一个资源文件的同时写操作。
单例模式可以在系统设置全局的访问点，优化和共享资源访问，例如可以设计一个单例类，负责所有数据表的映射处理。

缺点

单例模式一般没有接口，扩展很困难，若要扩展，除了修改代码基本上没有第二种途径可以实现。单例模式为什么不能增加接口呢？因为接口对单例模式是没有任何意义的，它要求“自行实例化”，并且提供单一实例、接口或抽象类是不可能被实例化的。当然，在特殊情况下，单例模式可以实现接口、被继承等，需要在系统开发中根据环境判断。
单例模式对测试是不利的。在并行开发环境中，如果单例模式没有完成，是不能进行测试的，没有接口也不能使用mock的方式虚拟一个对象。
单例模式与单一职责原则有冲突。一个类应该只实现一个逻辑，而不关心它是否是单例的，是不是要单例取决于环境，单例模式把“要单例”和业务逻辑融合在一个类中。