By

前言

Github：https://github.com/HealerJean

博客：http://blog.healerjean.com

1、单例模式

单例对象（ Singleton ）是一种常用的设计模式。在Java应用中， 单例对象能保证在一个 `JVM`中，该对象只有一个实例存在。

1.1、作用和使用场景

1.1.1、作用

1、某些类创建比较频繁，对于一些大型的对象，这是一笔很大的系统开销。

2、有些类如交易所的核心交易引擎，控制着交易流程，如果该类可以创建多个的话，系统完全乱了。（比如一个军队出现了多个司令员同时指挥，肯定会乱成一团），所以只有使用单例模式，才能保证核心交易服务器独立控制整个流程。

1.1.2、使用场景

1、 控制资源的使用，通过线程同步来控制资源的并发访问 （比如线程导入学籍，控制导入成功的数据）

2、 控制实例的产生，以达到节约资源的目的

3、 控制数据的共享，在不建立直接关联的条件下，让多个不相关的进程或线程之间实现通信 （启动的时候就开始，比如数据源的配置）

1.2、单例模式的7种写法

1.2.1、懒汉，线程不安全

这种写法lazy loading很明显，但是致命的是在多线程不能正常工作。

public class Singleton {
    private static Singleton instance;
    
    private Singleton (){
        
    }

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

1.2.2、懒汉，线程安全

这种写法能够在多线程中很好的工作，而且看起来它也具备很好的lazy loading，但是，遗憾的是，效率很低，99%情况下不需要同步。

但是，synchronized关键字锁住的是这个对象，这样的用法，在性能上会有所下降，因为每次调用getInstance()，都要对对象上锁，事实上，只有在第一次创建对象的时候需要加锁，之后就不需要了，所以，这个地方需要改进

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

1.2.3、饿汉，static代码

这种方式基于 classloder 机制避免了多线程的同步问题，不过，instance在 类装载时就实例化，虽然导致类装载的原因有很多种，在单例模式中大多数都是调用 getInstance方法， 但是也不能确定有其他的方式（或者其他的静态方法）导致类装载，这时候初始 化instance 显然没有达到lazy loading的效果。

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

1.2.4、饿汉，static 静态代码块

表面上看起来差别挺大，其实更第三种方式差不多，都是在类初始化即实例化 instance。

public class Singleton {
    private static Singleton instance = null;
    static {
        instance = new Singleton();
    }
    
    private Singleton (){
        
    }
    public static Singleton getInstance() {
        return this.instance;
    }
}

1.2.5、懒汉，静态内部类

这种方式同样利用了classloder的机制来保证初始化 instance 时只有一个线程，它跟第三种和第四种方式不同的是（很细微的差别）：

第三种和第四种方式是只要 Singleton 类被装载了，那么 instance 就会被实例化（没有达到 lazy loading 效果）

静态内部类这种方式是 Singleton 类被装载了，instance 不一定被初始化。因为 SingletonHolder 类没有被主动使用，只有显示通过调用 getInstance 方法时，才会显示装载 SingletonHolder 类，从而实例化 instance。

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

1.2.6、枚举

  public enum Singleton {
      INSTANCE;

      public void whateverMethod() {
      }
  }

1.2.7、懒汉，双重校验锁

1、为什么要两次校验

第一次校验：也就是第一个if（singleton==null），这个是为了代码提高代码执行效率，由于单例模式只要一次创建实例即可，所以当创建了一个实例之后，再次调用getInstance方法就不必要进入同步代码块，不用竞争锁。直接返回前面创建的实例即可。

第二次校验：也就是第二个if（singleton==null），单例模式如下，加入有多个线程同时通过了第一次的判空，有一个线程很快获取了锁，并在执行了里面的线程同步块里面方法使 得instance有了值。那么我们当前线程再进入的时候势必要判断一下啦

所以说：两次校验都必不可少。

2、volidate作用：

由于 synchronized 并不是对 instance 实例进行加锁（因为现在还并没有实例），所以线程在执行完第11行修改 instance 的值后，应该将修改后的 instance 立即写入主存，而不是暂时存在寄存器或者高速缓冲区（caches）中，以保证新的值对其它线程可见。


public class SingletonFinal {  

    /* 持有私有静态实例，防止被引用，此处赋值为null，目的是实现延迟加载 */   
    private volatile  static SingletonFinal instance = null;  

    /* 私有构造方法，防止被实例化 */  
    private SingletonFinal() {  
    }  

    /* 1、静态工程方法，创建实例 */  
    public static SingletonFinal getInstance() {  
        if (instance == null) {  
            syncInit();  
        }  
        return instance;  
    }  
    
        
    private static synchronized void syncInit() {  
        if (instance == null) {  
            instance = new SingletonFinal();  
        }  
    }  
}

1.3、普通单例模式存在的问题

3.1.1、可能存在反射攻击


public class Singleton {  

    /* 持有私有静态实例，防止被引用，此处赋值为null，目的是实现延迟加载 */   
    private volatile  static Singleton instance = null;  

    /* 私有构造方法，防止被实例化 */  
    private SingletonFinal() {  
    }  

    /* 1、静态工程方法，创建实例 */  
    public static Singleton getInstance() {  
        if (instance == null) {  
            syncInit();  
        }  
        return instance;  
    }  
    
        
    private static synchronized void syncInit() {  
        if (instance == null) {  
            instance = new Singleton();  
        }  
    }  
}  


public static void main(String[] args) throws Exception {
    Singleton singleton = Singleton.getInstance();
    Constructor<Singleton> constructor = Singleton.class.getDeclaredConstructor();
    constructor.setAccessible(true);
    Singleton newSingleton = constructor.newInstance();
    System.out.println(singleton == newSingleton); //false
}

// 这两个实例不是同一个，这就违背了单例模式的原则了。

3.1.2、可能存在反序列化攻击

public class Singleton implements Serializable {

    private static class SingletonHolder {
        private static Singleton instance = new Singleton();
    }

    private Singleton() {

    }

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

    public static void main(String[] args) {
        Singleton instance = Singleton.getInstance();
        byte[] serialize = SerializationUtils.serialize(instance);
        Singleton newInstance = SerializationUtils.deserialize(serialize);
        System.out.println(instance == newInstance); //false
        
        // 这两个实例不是同一个，这就违背了单例模式的原则了。
    }
}

1.4、单例模式缺点

1.4.2、单例不支持有参数的构造函数

单例不支持有参数的构造函数，比如创建一个连接池的单例对象，没法通过参数来指定连接池的大小。

解决方式：将参数配置化。在单例实例化时，从外部读取参数。

1.4.3、单例对代码的扩展性不友好

单例类只能有一个对象实例。如果未来某一天，需要在代码中创建两个实例或多个实例，那就要对代码有比较大的改动。

1.4、枚举类型实现的单例模式是最佳的方式

枚举方式实现的单例模式不仅能避免多线程同步的问题，也可以防止反序列化和反射的破坏。

public enum Singleton {

    INSTANCE;

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

}

1.4.1、JVM 级别的线程安全

反编译的代码中可以发现枚举中的各个枚举项都是通过 static 代码块来定义和初始化的，他们会在类被加载时完成初始化，而 Java 的类加载由 JVM 保证线程安全。

1.4.2、防止反序列化的破坏

1、在序列化时，只是将枚举对象的 name属性输出到结果中，

2、在反序列化时通过 java.lang.Enum 的 valueOf 方法根据名字查找对象，而不是新建一个新的对象，所以防止了反序列化对单例的破坏。

1.4.3、防止反射的破坏

反射在通过newInstance创建对象时会检查这个类是否是枚举类，如果是枚举类就会throw new IllegalArgumentException("Cannot reflectively create enum objects");,如下是源码java.lang.reflect.Constructor#newInstance：

​