单例模式的定义
Ensure a class has only one instance, and provide a global point of access to it.（确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。）
单例模式的通用类图如下：
单例模式的通用代码1-1：
public class Singleton {
/**
* private final修饰防止singleton被重新赋值
*/
private static final Singleton singleton = new Singleton();
/**
* 限制创建多个实例对象
*/
private Singleton(){
}
/**
* 获得实例对象
* @return 实例对象
*/
public static Singleton getSingleton(){
return singleton;
}
}
单例模式的优点
- 由于单例模式在内存中只有一个实例，减少了内存开支，特别是一个对象需要频繁地创建、销毁时，而且创建或销毁时性能又无法优化，单例模式的优势就非常明显。
- 由于单例模式只生成一个实例，所以减少了系统的性能开销，当一个对象的产生需要比较多的资源时，如读取配置、产生其他依赖对象时，则可以通过在应用启动时直接产生一个单例对象，然后用永久驻留内存的方式来解决（在Java EE中采用单例模式时需要注意JVM垃圾回收机制）。
- 单例模式可以避免对资源的多重占用，例如一个写文件动作，由于只有一个实例存在内存中，避免对同一个资源文件的同时写操作。
- 单例模式可以在系统设置全局的访问点，优化和共享资源访问，例如可以设计一个单例类，负责所有数据表的映射处理。
单例模式的缺点
- 单例模式一般没有接口，扩展很困难，若要扩展，除了修改代码基本上没有第二种途径可以实现。单例模式为什么不能增加接口呢？因为接口对单例模式是没有任何意义的，它要求“自行实例化”，并且提供单一实例、接口或抽象类是不可能被实例化的。当然，在特殊情况下，单例模式可以实现接口、被继承等，需要在系统开发中根据环境判断。
- 单例模式对测试是不利的。在并行开发环境中，如果单例模式没有完成，是不能进行测试的，没有接口也不能使用mock的方式虚拟一个对象。
- 单例模式与单一职责原则有冲突。一个类应该只实现一个逻辑，而不关心它是否是单例的，是不是要单例取决于环境，单例模式把“要单例”和业务逻辑融合在一个类中。
单例模式的使用场景
在一个系统中，要求一个类有且仅有一个对象，如果出现多个对象就会出现“不良反应”，可以采用单例模式，具体的场景如下：
- 要求生成唯一序列号的环境；
- 在整个项目中需要一个共享访问点或共享数据，例如一个Web页面上的计数器，可以不用把每次刷新都记录到数据库中，使用单例模式保持计数器的值，并确保是线程安全的；
- 创建一个对象需要消耗的资源过多，如要访问IO和数据库等资源；
- 需要定义大量的静态常量和静态方法（如工具类）的环境，可以采用单例模式（当然，也可以直接声明为static的方式）。
单例模式的拓展：
单例模式一般分为饿汉式（类初始化的时候就加载）和懒汉式（延迟加载）两种。
上面通用代码1-1介绍的是饿汉式
下面介绍懒汉式，懒汉式又可以分为两种，线程安全和非线程安全。
非线程安全的懒汉式代码如下1-2所示：
public class Singleton {
private static Singleton instance;
private Singleton (){}
public static Singleton getInstance() {
if (instance == null) { // 关键点
instance = new Singleton();
}
return instance;
}
}
//如果在instance没有初始化的时候，同一时间有大量的线程访问if (instance == null) 这段代码，线程得到的结果将都是true，这样会导致实例化多个Singleton对象，这是线程不安全的。
线程安全的懒汉式代码如下1-3所示：
public class Singleton {
private static Singleton instance;
private Singleton (){}
public static synchronized Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
}
// 使用synchronized关键字，保证同一时间只有一个线程可以调用getInstance()方法，保证了初始化实例对象的安全性。
在并发量比较大的情况下，这段代码的性能会下降，因为getInstance()作为一个同步方法，保证了单例的需求没错，可是如果Singleton已经实例化完成，这时候大量的线程来拿取实例对象时还是只能保证一个线程一个线程的来拿。这明显是没必要的，我们只需要保证实例化的时候只有一个线程访问就可以了。获取实例对象不应该去使用同步锁。我们可以使用双重检查锁定来优化这段代码。
双重检查锁定优化线程安全的懒汉式
public class Singleton {
private volatile static Singleton instance;
private Singleton (){}
public static Singleton getInstance() {
if (instance == null){
synchronized (Singleton.class){
if (instance == null){
instance = new Singleton();
}
}
}
return instance;
}
}
在Singleton实例化完成的前提下，大量线程获取instance就不会造成阻塞了。注意这段代码中使用了volatile关键字来保证有序性。instance = new Singleton()这一段代码可以分解为以下3行伪代码：
注意以下情况是不加volatile可能会导致的结果
memory = allocate(); // 1.分配对象的内存空间
ctorInstance(memory); //2.初始化对象
instance = memory; //3.设置instance指向刚刚分配的地址
上面3行伪代码2和3在不使用volatile的情况下是可以允许重排序的（根据as-if-serial 原则，在单线程环境下执行1->2->3 和 执行1->3->2 的结果是一样的，JMM允许这种重排序），重排序之后的结果如下所示：
memory = allocate(); // 1.分配对象的内存空间
instance = memory; //3.设置instance指向刚刚分配的地址（此时对象还未初始化）
ctorInstance(memory); //2.初始化对象
假设此时有线程A获取到了锁并且执行到了instance = new Singleton();此时发生了重排序，导致先执行了3（设置instance指向刚刚分配的地址）,然后线程B执行到了if(instance == null)，因为instance已经指向了刚刚分配的地址，执行结果为false，线程B会拿到一个未初始化完成的Singleton对象，这样会影响B线程的后续执行结果。
为什么加了volatile就会没事呢？
根据volatile的原则：当第二个操作数是volatile写（这里指的是instance = memory，将memory的值写入到instance），不管第一个操作数（这里指的是ctorInstance(memory)）是什么，都禁止重排序。这里使用了StroreStore屏障。2和3禁止了重排序，问题解决。
