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

定义

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

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

或者数据库

Ensure a class has only one instance, and provide a global point of access to it.设计模式

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

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

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

特色

单例类只能有一个实例；
单例类必须本身建立本身的惟一实例；
单例类必须给全部其余对象提供这一实例。

基本步骤

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

考虑的因素

延迟加载多线程
线程安全jvm
破坏单例的状况ide
- 序列化函数
  
  若是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接口。
- 类加载器
  
  若是单例由不一样的类装载器装入，那便有可能存在多个单例类的实例。

实现方式

一、懒汉式

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

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%的状况下实际上是不须要同步的

二、饿汉式

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

    private Singleton() {
    }

    public static Singleton getInstance() {
        return singleton;
    }
}
复制代码

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

若是不是特别须要延迟加载的场景，能够优先考虑饿汉式

三、双重检查锁

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的两层含义：
1. 内存可见性
2. 禁止指令重排
这里咱们用到的主要是第二个语义。那么什么是指令重排序呢，就是指编译器和处理器为了优化程序性能而对指令序列进行排序的一种手段。简单理解，就是编译器对咱们的代码进行了优化，在实际执行指令的的时候可能与咱们编写的顺序不一样，只保证程序执行结果与源代码相同，却不保证明际指令的顺序与源代码相同。

singleton = new Singleton();

这段代码在jvm执行时实际分为三步：
1. 在堆内存开辟一块内存空间；
2. 在堆内存实例化Singleton
3. 把对象（singleton）指向堆内存空间
因为"指令重排"的优化，极可能执行步骤为1-3-2，即：对象并无实例化完成但引用已是非空了，也就是在第二处判空的地方为false，直接返回singleton——一个未完成实例化的对象引用。

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

四、静态内部类

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()方法第一次调用的时候才会被加载（实现了延迟加载效果）。

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

五、枚举

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

优势：枚举方式具备以上全部实现方式的优势，同时还无偿地提供了序列化机制，防止屡次实例化

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

优势

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

缺点

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

使用场景

在一个系统中，要求一个类有且仅有一个对象，若是出现多个对象就会出现“不良反应”，能够采用单例模式，具体的场景以下：

要求生成惟一序列号的环境；
在整个项目中须要一个共享访问点或共享数据，例如一个Web页面上的计数器，能够不用把每次刷新都记录到数据库中，使用单例模式保持计数器的值，并确保是线程安全的；
建立一个对象须要消耗的资源过多，如要访问IO和数据库等资源；
须要定义大量的静态常量和静态方法（如工具类）的环境，能够采用单例模式（固然，也能够直接声明为static的方式）。

源码地址：gitee.com/tianranll/j…

参考文献：《设计模式之禅》、《Effective Java》