写出你所知道的单例模式（Singleton）的几种实现
文章目录
- 写出你所知道的单例模式（Singleton）的几种实现
- 什么是单例？
- 1）实现方式一：**饿汉模式【立即加载】**
- 2）实现方式二：枚举实现单例
- 3）实现方式三：静态代码块实现单例
- 4）实现方式四：非线程安全的懒汉式
- 5）实现方式五：实现线程安全的懒汉单例从sychronized的到DCL双检查锁机制
- 6）实现方式六：静态内部类实现线程安全的单例
- 静态内部类实现单例的原理分析
- 单例模式的实际应用：
- 题外话
写出你所知道的单例模式（Singleton）的几种实现
什么是单例？
Singleton：在java中即指单例设计模式，它是软件开发中最常用的设计模式之一。单例设计模式，就是指某个类在整个系统中只能有一个实例对象可被获取和使用的代码模式。比如：jdk中的Runtime类，代表JVM运行时的环境。
单：唯一
例：实例
怎么实现呢？要点如下：
-
一保证某一个类只能有一个实例：构造器私有化
-
二必须自行创建这个实例：用一个该类的静态变量来保存这个唯一的实例。
-
此类必须自行向整个系统提供这个实例的：对外提供获取该实例的方式。
（1）直接暴露（2）用静态变量的get方法获取
简而言之，一句话来说就是：私有构造，公有实现。确保某一个类只有一个实例，并且提供一个全局访问点。单例模式具备典型的3个特点：1、只有一个实例。 2、自我实例化。 3、提供全局访问点。
具体实现 需要：
（1）将构造方法私有化，使其不能在类的外部通过new关键字实例化该类对象。
（2）在该类内部产生一个唯一的实例化对象，并且将其封装为private static类型。
（3）定义一个静态方法返回这个唯一对象。
实现单例应该遵循的原则：
1.构造私有。
2.以静态方法或者枚举返回实例。
3.确保实例只有一个，尤其是多线程环境。
4.确保反序列换时不会重新构建对象。
我们常用的单例模式有： 饿汉模式、懒汉模式、双重锁懒汉模式、静态内部类模式、枚举模式，
我们来逐一分析下这些模式的区别。
- 饿汉式：直接创建对象，不存在线程安全问题
- 直接实例化饿汉式（简单直观）
- 枚举式（最简洁）
- 静态代码块饿汉式（适合复杂实例化）
- 懒汉式：延迟创建对象
- 线程不安全（适用于单线程）
- 线程安全（使用于多线程）
- 静态内部类实现（适用于多线程）
1）实现方式一：饿汉模式【立即加载】
/**饿汉模式在类被初始化时就已经在内存中创建了对象，以空间换时间，故不存在线程安全问题。
* 立即加载就是使用类的时候已经将对象创建完毕（不管以后会不会使用到该实例化对象，先创建了再说。很着急的样子,故又被称为“饿汉模式”）,常见的实现办法就是直接new实例化。
*
* 何为饿？饿者，饥不择食，但凡有食，必急食之。
*
* “饿汉模式”的优缺点：
* 优点：实现起来简单，没有多线程同步问题。
* 缺点：当类SingletonTest被加载的时候，会初始化static的instance，静态变量被创建并分配内存空间,从这以后，这个static的instance对象便一直占着这段内存（即便你还没有用到这个实例），当类被卸载时,静态变量被摧毁,并释放所占有的内存,因此在某些特定条件下会耗费内存。
*/
public class Singleton1_1 {
//1.构造器私有化
private Singleton1_1() {}
//2.公有实现
public static final Singleton1_1 INSTANCE = new Singleton1_1();
}
public class Singleton1_1 {
//1.将自身实例化对象设置为一个属性，并用private、static、final修饰
private static final Singleton1_1 INSTANCE = new Singleton1_1();
//2.构造方法私有化
private Singleton1_1() {}
//3.公有静态方法返回该实例
public static final Singleton1_1 getInstance(){
return INSTANCE;
}
}
2）实现方式二：枚举实现单例
在jdk1.5以后单例可以使用枚举更简洁地实现。如下：
/**使用枚举来实现单实例控制会更加简洁，而且无偿地提供了序列化机制，并由JVM从根本上提供保障，绝对防止多次实例化，是更简洁、高效、安全的实现单例的方式。
* 枚举在java中与普通类一样，都能拥有字段与方法，而且枚举实例创建是线程安全的，
* 在任何情况下，它都是一个单例。我们可直接以 SingleTon.INSTANCE的方式调用.
*/
public enum Singleton1_2 {
INSTANCE;
public void method(){}
}
3）实现方式三：静态代码块实现单例
import java.io.IOException;
import java.util.Properties;
public class Singleton1_3 {
public static final Singleton1_3 INSTANCE;
static {
INSTANCE = new Singleton1_3(name);
}
private Singleton1_3() {}
}
什么时候会使用静态代码块实现单例呢？当我们创建某一个类的实例需要一些属性参数时，就体现出来了静态代码块创建单例的好处了，可以利用静态代码块加载资源配置文件，然后再创建实例对象。如下：
import java.io.IOException;
import java.util.Properties;
public class Singleton1_3 {
// 静态代码块实现单例
/**
* 什么时候会使用到静态代码块实现单例呢？ 当我们创建某一个类需要一些属性参数时，就体现出来了静态代码块创建单例的好处了，可以利用静态代码块加载资源配置文件，然后再创建实例对象
*/
public static final Singleton1_3 INSTANCE;
private String name;
static {
try {
Properties properties = new Properties();
properties.load(Singleton1_3.class.getClassLoader().getResourceAsStream("Singleton.properties"));
String name = (String) properties.get("name");
INSTANCE = new Singleton1_3(name);
} catch (IOException e) {
throw new RuntimeException();
}
}
private Singleton1_3(String name) {
this.setName(name);
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
4）实现方式四：非线程安全的懒汉式
此种实现在单线程环境下是安全的，但是在多线程环境下是非安全。根本不能保证该实例对象是单例的。
//实现方式：懒汉模式【延迟加载】
/**懒汉模式在方法被调用后才创建对象，以时间换空间，在多线程环境下存在风险。
* 延迟加载就是调用get()方法时实例才被创建（先不急着实例化出对象，等要用的时候才给你创建出来。
* 不着急，故又称为“懒汉模式”），常见的实现方法就是在get方法中进行new实例化。
*
* “懒汉模式”的优缺点：
* 优点：实现起来比较简单，当类SingletonTest被加载的时候，静态变量static的instance未被创建并分配内存空间，
* 当getInstance方法第一次被调用时，初始化instance变量，并分配内存，因此在某些特定条件下会节约了内存。
* 缺点：在多线程环境中，这种实现方法是完全错误的，根本不能保证单例的状态。
*/
public class Singleton2_1 {
// 将自身实例化对象设置为一个属性，并用static修饰
private static Singleton2_1 singleton2_1;
// 构造方法私有化
private Singleton2_1() {}
//公有静态方法返回该实例
public static Singleton2_1 getInstance(){
if(singleton2_1 == null){
//为了模拟AB线程都到此处时出现创建两个实例的场景，让线程休眠一会儿
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
singleton2_1 = new Singleton2_1();
}
return singleton2_1;
}
}
测试单线程下：
@Test
public void test(){
Singleton2_1 s1 = Singleton2_1.getInstance();
Singleton2_1 s2 = Singleton2_1.getInstance();
System.out.println(s1 == s2);//true
System.out.println(s1);//Singleton2_1@6659c656
System.out.println(s2);//Singleton2_1@6659c656
}
测试多线程下：
@Test
public void test01() throws InterruptedException, ExecutionException{
Callable<Singleton2_1> callable = new Callable<Singleton2_1>() {
@Override
public Singleton2_1 call() throws Exception {
return Singleton2_1.getInstance();
}
};
ExecutorService executorService = Executors.newFixedThreadPool(2);
Future<Singleton2_1> future1 = executorService.submit(callable);
Future<Singleton2_1> future2 = executorService.submit(callable);
Singleton2_1 singleton1 = future1.get();
Singleton2_1 singleton2 = future2.get();
//输出结果不确定
System.out.println(singleton1 == singleton2);//false
System.out.println(singleton1);//Singleton2_1@bebdb06
System.out.println(singleton2);//Singleton2_1@7a4f0f29
executorService.shutdown();
}
5）实现方式五：实现线程安全的懒汉单例从sychronized的到DCL双检查锁机制
/**
*优点：在多线程情形下，保证了“懒汉模式”的线程安全。
*缺点：众所周知在多线程情形下，synchronized方法通常效率低，显然这不是最佳的实现方案。
*/
public class Singleton2_2 {
// 将自身实例化对象设置为一个属性，并用static修饰
private static Singleton2_2 singleton;
// 构造方法私有化
private Singleton2_2() {}
//公有静态方法返回该实例,加synchronized关键字实现同步
public static synchronized Singleton2_2 getInstance(){
if(singleton == null){
singleton = new Singleton2_2();
}
return singleton;
}
public static Singleton2_2 getInstance2(){
synchronized(Singleton2_2.class){
if(singleton == null){
singleton = new Singleton2_2();
}
}
return singleton;
}
/**DCL双检查锁机制(DCL：double checked locking)
* DCL模式的优点就是，只有在对象需要被使用时才创建，第一次判断 INSTANCE == null为了避免非必要加锁，
* 当第一次加载时才对实例进行加锁再实例化。这样既可以节约内存空间，又可以保证线程安全。
* 但是，由于jvm存在"乱序执行"功能，DCL也会出现线程不安全的情况。
* 具体分析：
* singleton = new Singleton2_2();
* 这个步骤，其实在jvm里面的执行分为三步：
* 1.在堆内存开辟内存空间。
* 2.在堆内存中实例化SingleTon里面的各个参数。
* 3.把对象指向堆内存空间。
* 由于jvm存在乱序执行功能，所以可能在2还没执行时就先执行了3，如果此时再被切换到线程B上，
* 由于执行了3，INSTANCE 已经非空了，会被直接拿出来用，这样的话，就会出现异常。
* 这个就是著名的DCL失效问题。
*
* 不过在JDK1.5之后，官方也发现了这个问题，故而具体化了volatile，即在JDK1.6及以后，
* 只要定义为private volatile static SingleTon INSTANCE = null;
* 就可解决DCL失效问题。volatile确保INSTANCE每次均在主内存中读取，这样虽然会牺牲一点效率，但也无伤大雅。
*
* “双重检查加锁”机制的实现会使用关键字volatile，它的意思是：被volatile修饰的变量的值，将不会被本地线程缓存，所有对该变量的读写都是直接操作共享内存，从而确保多个线程能正确的处理该变量。Volatile是轻量级的synchronized，它在多处理器开发中保证了共享变量的“可见性”。可见性的意思是当一个线程修改一个共享变量时，另外一个线程能读到这个修改的值。它在某些情况下比synchronized的开销更小
*/
public static Singleton2_2 getInstance4(){
if(singleton ==null){
synchronized(Singleton2_2.class){
if(singleton == null){
singleton = new Singleton2_2();
}
}
}
return singleton;
}
所以上面第三种实现机制应该改为： private volatile static Singleton2_2 singleton;
public class Singleton2_2 {
// 将自身实例化对象设置为一个属性，并用static修饰
private volatile static Singleton2_2 singleton;
// 构造方法私有化
private Singleton2_2() {}
public static Singleton2_2 getInstance3(){
if(singleton ==null){
synchronized(Singleton2_2.class){
if(singleton == null){
singleton = new Singleton2_2();
}
}
}
return singleton;
}
}
6）实现方式六：静态内部类实现线程安全的单例
使用java内部类机制实现线程安全的单例模式，这个解决方案被称为Lazy initialization holder class 模式，这个模式综合使用了java的类级内部类和多线程缺省同步锁的知识，很巧妙的同时实现了延迟加载和线程安全。
/**
* 在内部类被加载和初始化时，才创建INSTANCE实例对象
* 静态内部类不会自动随着外部类的加载和初始化而初始化，它是要单独去加载和实例化的
* 因为是在内部类加载和初始化时被创建的，所以是线程安全的
*/
public class Singleton2_3 {
private Singleton2_3(){}
private static class Inner{
private static final Singleton2_3 INSTANCE = new Singleton2_3();
}
public static Singleton2_3 getInstance(){
return Inner.INSTANCE;
}
}
静态内部类实现单例的原理分析
1、 相应的基础知识
（1）什么是类级内部类？简单点说，类级内部类指的是，有static修饰的成员内部类。如果没有static修饰的成员式内部类被称为对象级内部类。
（2）类级内部类相当于其外部类的static成分，它的对象与外部类对象间不存在依赖关系，因此可以直接创建。而对象级内部类的实例，是绑定在外部对象实例中的。
（3）类级内部类中，可以定义静态的方法。在静态方法中只能引用外部类中的静态成员方法或变量。
（4）类级内部类相当于其外部类的成员，只有在第一次被使用的时候才会被装载。
多线程缺省同步锁的知识：
大家都知道，在多线程开发中，为了解决并发问题，主要是通过使用synchronized来加互斥锁进行同步控制，但是在某些情况下，JVM已经隐含的为您执行了同步，这些情况下就不用自己再来进行同步控制了。这些情况包括：
（1）由静态初始化器（在静态字段上或static{}块中的初始化器）初始化数据时
（2）访问final字段时
（3）在创建线程之前创建对象时
（4）线程可以看见它将要处理的对象时
2、解决方案的思路
要想很简单的实现线程安全，可以采用静态初始化器的方式，它可以由JVM来保证线程的安全性。比如前面的饿汉式实现方式。但是这样一来，不是会浪费一定的空间吗？因为这种实现方式，会在类装载的时候就初始化对象，不管你需不需要。 如果现在有一种方法能够让类装载的时候不去初始化对象，那不就解决问题了？一种可行的方式就是采用类级内部类，在这个类级内部类里面去创建对象实例。这样一来，只要不使用到这个类级内部类，
那就不会创建对象实例，从而同步实现延迟加载和线程安全。
单例模式实现方式有好多种，但大部分都会有多线程环境下的问题；使用内部类可以避免这个问题，
因为在多线程环境下，jvm对一个类的初始化会做限制，同一时间只会允许一个线程去初始化一个类，
这样就从虚拟机层面避免了大部分单例实现的问题.
静态内部类的优点是：外部类加载时并不需要立即加载内部类，内部类不被加载则不去初始化INSTANCE，故而不占内存。即当SingleTon第一次被加载时，并不需要去加载SingleTonHoler，只有当getInstance()方法第一次被调用时，才会去初始化INSTANCE,第一次调用getInstance()方法会导致虚拟机加载SingleTonHoler类，这种方法不仅能确保线程安全，也能保证单例的唯一性，同时也延迟了单例的实例化。
那么，静态内部类又是如何实现线程安全的呢？首先，我们先了解下类的加载时机。类加载时机：JAVA虚拟机在有且仅有的5种场景下会对类进行初始化。
1.遇到new、getstatic、setstatic或者invikestatic这4个字节码指令时，对应的java代码场景为：new一个关键字或者一个实例化对象时、读取或设置一个静态字段时(final修饰、已在编译期把结果放入常量池的除外)、调用一个类的静态方法时。
2.使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没进行初始化，需要先调用其初始化方法进行初始化。
3.当初始化一个类时，如果其父类还未进行初始化，会先触发其父类的初始化。
4.当虚拟机启动时，用户需要指定一个要执行的主类(包含main()方法的类)，虚拟机会先初始化这个类。
5.当使用JDK 1.7等动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。
这5种情况被称为是类的主动引用，注意，这里《虚拟机规范》中使用的限定词是"有且仅有"，那么，除此之外的所有引用类都不会对类进行初始化，称为被动引用。静态内部类就属于被动引用的行列
我们再回头看下getInstance()方法，调用的是SingleTonHoler.INSTANCE，取的是SingleTonHoler里的INSTANCE对象，跟上面那个DCL方法不同的是，getInstance()方法并没有多次去new对象，故不管多少个线程去调用getInstance()方法，取的都是同一个INSTANCE对象，而不用去重新创建。当getInstance()方法被调用时，SingleTonHoler才在SingleTon的运行时常量池里，把符号引用替换为直接引用，这时静态对象INSTANCE也真正被创建，然后再被getInstance()方法返回出去，这点同饿汉模式。那么INSTANCE在创建过程中又是如何保证线程安全的呢？在《深入理解JAVA虚拟机》中，有这么一句话:
虚拟机会保证一个类的()方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的()方法，其他线程都需要阻塞等待，直到活动线程执行()方法完毕。如果在一个类的()方法中有耗时很长的操作，就可能造成多个进程阻塞(需要注意的是，其他线程虽然会被阻塞，但如果执行()方法后，其他线程唤醒之后不会再次进入()方法。同一个加载器下，一个类型只会初始化一次。)，在实际应用中，这种阻塞往往是很隐蔽的。
故而，可以看出INSTANCE在创建过程中是线程安全的，所以说静态内部类形式的单例可保证线程安全，也能保证单例的唯一性，同时也延迟了单例的实例化。
那么，是不是可以说静态内部类单例就是最完美的单例模式了呢？其实不然，静态内部类也有着一个致命的缺点，就是传参的问题，由于是静态内部类的形式去创建单例的，故外部无法传递参数进去，例如Context这种参数，所以，我们创建单例时，可以在静态内部类与DCL模式里自己斟酌。
单例模式的实际应用：
1.Spring中的Bean，默认就是单例模式 spring中通过IOC反射机制获取bean默认就是单例模式的。包括 controller、service、dao、…
spring的controller默认是单例，原因有二：
（1）为了性能：单例不用每次都创建
（2）不需要多例：只要controller中不定义属性，那么单例完全是安全可用的，如果定义了，那单例肯定会出现竞争访问；非要定义，则通过注解@Scope(“prototype”)，将其设置为多例模式。
Spring的依赖注入（包括lazy-init方式）都是发生在 AbstractBeanFactory 的 getBean 里。 getBean 的 doGetBean 方法调用 getSingleton 进行bean的创建。lazy-init方式(lazy-init=“true”)，在用户向容器第一次索要bean时进行调用；非lazy-init方式(lazy-init=“false”)，在容器初始化时候进行调用。
spring依赖注入时，使用了 双重判断加锁 的单例模式。
在这里Spring并没有使用私有构造方法来创建bean，而是通过 singletonFactory.getObject() 返回具体beanName对应的ObjectFactory来创建bean。我们一路跟踪下去，发现实际上是调用了 AbstractAutowireCapableBeanFactory 的 doCreateBean 方法，返回了BeanWrapper包装并创建的bean实例。（ObjectFactory主要检查是否有用户定义的BeanPostProcessor后处理内容，并在创建bean时进行处理，如果没有，就直接返回bean本身）
2.JDK中体现：
（1）Runtime
java.lang.Runtime类封装了Java运行时的环境。每一个java程序实际上都是启动了一个JVM进程，那么每个JVM进程都是对应这一个Runtime实例，此实例是由JVM为其实例化的。每个 Java 应用程序都有一个 Runtime 类实例，使应用程序能够与其运行的环境相连接。由于Java是单进程多线程的，所以，在一个JVM中，Runtime的实例应该只有一个。所以应该使用单例来实现。
（2）NumberFormat
（3）除了Runtime是典型的单例以外。JDK中还有几个类是单例的，他们都是GUI中的类。这几个单例的类和Runtime最大的区别就在于他们并不是饿汉模式，也就是他们都是惰性初始化的懒汉单例。
（4）java.lang.reflect.Proxy类
总结：
当一个类的对象只需要或者只可能有一个时，应该考虑单例模式。
如果一个类的实例应该在JVM初始化时被创建出来，应该考虑使用饿汉式单例。
如果一个类的实例不需要预先被创建，也许这个类的实例并不一定能用得上，也许这个类的实例创建过程比较耗费时间，也许就是真的没必须提前创建。那么应该考虑懒汉式单例。
在使用懒汉式单例的时候，应该考虑到线程的安全性问题。
题外话
/**
* Q：你如何阻止使用clone()方法创建单例实例的另一个实例？
*
* A：在JAVA里要注意的是，所有的类都默认的继承自Object，所以都有一个clone方法。为保证只有一个实例，要把这个口堵上。
* 有两个方面，一个是单例类一定要是final的，这样用户就不能继承它了。另外，如果单例类是继承于其它类的，还要override它的clone方法，让它抛出异常。
*
* Q：如何阻止通过使用反射来创建单例类的另一个实例？
*
* A：开放的问题。在我的理解中，从构造方法中抛出异常可能是一个选项。
* 如果借助AccessibleObject.setAccessible方法，通过反射机制调用私有构造器，反射攻击：
*/
/**
spring的Bean默认的是单例的，Bean的作用域可以通过Bean标签的scope属性进行设置，Bean的作用域包括：
默认情况下scope="singleton"，那么该Bean是单例，任何人获取该Bean实例的都为同一个实例；
scope="prototype"，任何一个实例都是新的实例；
scope="request"，在WEB应用程序中，每一个实例的作用域都为request范围；
scope="session",在WEB应用程序中，每一个实例的作用域都为session范围；
注意：在默认情况下，Bean实例在被Spring容器初始化的时候，就会被实例化，默认调用无参数的构造方法。在其它情况下，Bean将会在获取实例的时候才会被实例化。
在Spring中，bean可以被定义为两种模式：prototype（多例）和singleton（单例）
singleton（单例）：只有一个共享的实例存在，所有对这个bean的请求都会返回这个唯一的实例。
单例模式分为饿汉模式和懒汉模式:
饿汉模式 spring singleton的缺省是饿汉模式:启动容器时(即实例化容器时),为所有spring配置文件中定义的bean都生成一个实例
懒汉模式 在第一个请求时才生成一个实例,以后的请求都调用这个实例
spring singleton设置为懒汉模式:
prototype（多例）：对这个bean的每次请求都会创建一个新的bean实例，类似于new。
Spring中说的单例是相对于容器的，既在ApplicationContext中是单例的。而平常说的单例是相对于JVM的。
另一个JVM可以有多个Spring容器，而且Spring中的单例也只是按bean的id来区分的。
*/