关于设计模式:02创建型单例设计模式2

创立型：单例设计模式 2

目录介绍

• 01. 如何实现一个单例
• 02. 饿汉式实现形式
• 03. 懒汉式实现形式
• 04. 双重 DCL 校验模式
• 05. 动态外部类形式
• 06. 枚举形式单例
• 07. 容器实现单例模式

01. 如何实现一个单例

• 介绍如何实现一个单例模式的文章曾经有很多了，但为了保障内容的完整性，这里还是简略介绍一下几种经典实现形式。概括起来，要实现一个单例，咱们须要关注的点无外乎上面几个：

  • 构造函数须要是 private 拜访权限的，这样能力防止内部通过 new 创立实例；
  • 思考对象创立时的线程平安问题；
  • 思考是否反对提早加载；
  • 思考 getInstance() 性能是否高（是否加锁）。

02. 饿汉式实现形式

• 饿汉式的实现形式比较简单。在类加载的时候，instance 动态实例就曾经创立并初始化好了，所以，instance 实例的创立过程是线程平安的。不过，这样的实现形式不反对提早加载，从名字中咱们也能够看出这一点。具体的代码实现如下所示：

  // 饿汉式单例类. 在类初始化时，曾经自行实例化   
  public class Singleton { 
      //static 润饰的动态变量在内存中一旦创立，便永恒存在
      private static Singleton instance = new Singleton(); 
      private Singleton (){} 
      public static Singleton getInstance() {return instance;} 
  }

• 代码剖析

  • 饿汉式在类创立的同时就曾经创立好一个动态的对象供零碎应用，当前不再扭转，所以天生是线程平安的。其中 instance = new Singleton() 能够写成：

    static {instance = new Singleton(); 
    }

• 有人感觉这种实现形式不好

  • 因为不反对提早加载，如果实例占用资源多（比方占用内存多）或初始化耗时长（比方须要加载各种配置文件），提前初始化实例是一种浪费资源的行为。最好的办法应该在用到的时候再去初始化。
  • 不过，我集体并不认同这样的观点。如果初始化耗时长，那咱们最好不要等到真正要用它的时候，才去执行这个耗时长的初始化过程，这会影响到零碎的性能（比方，在响应客户端接口申请的时候，做这个初始化操作，会导致此申请的响应工夫变长，甚至超时）。采纳饿汉式实现形式，将耗时的初始化操作，提前到程序启动的时候实现，这样就能防止在程序运行的时候，再去初始化导致的性能问题。
  • 如果实例占用资源多，依照 fail-fast 的设计准则（有问题及早裸露），那咱们也心愿在程序启动时就将这个实例初始化好。如果资源不够，就会在程序启动的时候触发报错（比方 Java 中的 PermGen Space OOM），咱们能够立刻去修复。这样也能防止在程序运行一段时间后，忽然因为初始化这个实例占用资源过多，导致系统解体，影响零碎的可用性。

03. 懒汉式实现形式

• 有饿汉式，对应地，就有懒汉式。懒汉式绝对于饿汉式的劣势是反对提早加载。具体的代码实现如下所示：

  // 懒汉式单例类. 在第一次调用的时候实例化本人  
  public class Singleton { 
      // 公有的构造函数
      private Singleton() {}
      // 公有的动态变量
      private static Singleton single=null; 
      // 裸露的私有静态方法 
      public static Singleton getInstance() {if (single == null) {single = new Singleton(); 
          }   
          return single; 
      } 
  }

  • 代码剖析

    • 懒汉式（线程不平安）的单例模式分为三个局部：公有的构造方法，公有的全局动态变量，私有的静态方法。
    • 起到重要作用的是动态修饰符 static 关键字，咱们晓得在程序中，任何变量或者代码都是在编译时由零碎主动分配内存来存储的，而所谓动态就是指在编译后所调配的内存会始终存在，直到程序退出内存才会开释这个空间，因而也就保障了单例类的实例一旦创立，便不会被零碎回收，除非手动设置为 null。

  • 优缺点

    • 长处：提早加载（须要的时候才去加载）
    • 毛病：线程不平安，在多线程中很容易呈现不同步的状况，如在数据库对象进行的频繁读写操作时。

• 下面这个能够看到是线程不平安的，其实还能够演变一下：

  public class Singleton { 
      // 公有的动态变量
      private static Singleton instance; 
      // 公有的构造方法
      private Singleton (){}；// 私有的同步静态方法
      public static synchronized Singleton getInstance() {if (instance == null) {instance = new Singleton(); 
          } 
          return instance; 
      } 
  } 

  • 代码剖析

    • 这种单例实现形式的 getInstance（）办法中增加了 synchronized 关键字，也就是通知 Java（JVM）getInstance 是一个同步办法。
    • 同步的意思是当两个并发线程拜访同一个类中的这个 synchronized 同步办法时，一个工夫内只能有一个线程失去执行，另一个线程必须期待以后线程执行完能力执行，因而同步办法使得线程平安，保障了单例只有惟一个实例。

  • 优缺点

    • 长处：解决了线程不平安的问题。
    • 毛病：效率有点低，每次调用实例都要判断同步锁，它的毛病在于每次调用 getInstance（）都进行同步，造成了不必要的同步开销。这种模式个别不倡议应用。

• 不过懒汉式的毛病也很显著

  • 给 getInstance() 这个办法加了一把大锁（synchronzed），导致这个函数的并发度很低。量化一下的话，并发度是 1，也就相当于串行操作了。而这个函数是在单例应用期间，始终会被调用。如果这个单例类偶然会被用到，那这种实现形式还能够承受。然而，如果频繁地用到，那频繁加锁、开释锁及并发度低等问题，会导致性能瓶颈，这种实现形式就不可取了。

04. 双重 DCL 校验模式

• 饿汉式不反对提早加载，懒汉式有性能问题，不反对高并发。那咱们再来看一种既反对提早加载、又反对高并发的单例实现形式，也就是双重检测实现形式。

• 在这种实现形式中，只有 instance 被创立之后，即使再调用 getInstance() 函数也不会再进入到加锁逻辑中了。所以，这种实现形式解决了懒汉式并发度低的问题。具体的代码实现如下所示：

  public class Singleton {
      private static Singleton singleton;  // 动态变量
      private Singleton (){}  // 公有构造函数
      public static Singleton getInstance() {if (singleton == null) {  // 第一层校验
              synchronized (Singleton.class) {if (singleton == null) {  // 第二层校验
                      singleton = new Singleton();}
              }
          }
          return singleton;
      }
  }

• 代码剖析

  • 这种模式的亮点在于 getInstance（）办法上，其中对 singleton 进行了两次判断是否空，第一层判断是为了防止不必要的同步，第二层的判断是为了在 null 的状况下才创立实例。

• 优缺点

  • 长处：在并发量不多，安全性不高的状况下或者能很完满运行单例模式
  • 毛病：不同平台编译过程中可能会存在重大安全隐患。

• 模仿剖析

  • 假如线程 A 执行到了 singleton = new Singleton(); 语句，这里看起来是一句代码，然而它并不是一个原子操作，这句代码最终会被编译成多条汇编指令，它大抵会做三件事件：

    • （a）给 Singleton 的实例分配内存
    • （b）调用 Singleton（）的构造函数，初始化成员字段；
    • （c）将 singleton 对象指向调配的内存空间（即 singleton 不为空了）；
  • 然而因为 Java 编译器容许处理器乱序执行，以及在 jdk1.5 之前，JMM（Java Memory Model：java 内存模型）中 Cache、寄存器、到主内存的回写程序规定，下面的步骤 b 步骤 c 的执行程序是不保障了。也就是说执行程序可能是 a -b-c，也可能是 a -c-b, 如果是后者的指向程序，并且恰好在 c 执行结束，b 尚未执行时，被切换到线程 B 中，这时候因为 singleton 在线程 A 中执行了步骤 c 了，曾经非空了，所以，线程 B 间接就取走了 singleton，再应用时就会出错。这就是 DCL 生效问题。
  • 然而在 JDK1.5 之后，官网给出了 volatile 关键字，将 singleton 定义的代码改成：private volatile static Singleton singleton; // 应用 volatile 关键字

• 网上有人说，这种实现形式有些问题。

  • 因为指令重排序，可能会导致 singleton 对象被 new 进去，并且赋值给 instance 之后，还没来得及初始化（执行构造函数中的代码逻辑），就被另一个线程应用了。要解决这个问题，咱们须要给 instance 成员变量加上 volatile 关键字，禁止指令重排序才行。实际上，只有很低版本的 Java 才会有这个问题。咱们当初用的高版本的 Java 曾经在 JDK 外部实现中解决了这个问题（解决的办法很简略，只有把对象 new 操作和初始化操作设计为原子操作，就天然能禁止重排序）。

05. 动态外部类形式

• 再来看一种比双重检测更加简略的实现办法，那就是利用 Java 的动态外部类。它有点相似饿汉式，但又能做到了提早加载。

  public class Singleton {private Singleton (){} ;// 公有的构造函数
      public static final Singleton getInstance() {return SingletonHolder.INSTANCE;}
      // 定义的动态外部类
      private static class SingletonHolder {private static final Singleton INSTANCE = new Singleton();  // 创立实例的中央
      }
  }

• 优缺点

  • 长处：提早加载，线程平安（java 中 class 加载时互斥的），也缩小了内存耗费

• 代码剖析

  • 当第一次加载 Singleton 类的时候并不会初始化 INSTANCE，只有第一次调用 Singleton 的 getInstance（）办法时才会导致 INSTANCE 被初始化。
  • 因而，第一次调用 getInstance（）办法会导致虚拟机加载 SingletonHolder 类，这种形式不仅可能确保单例对象的唯一性，同时也提早了单例的实例化。

06. 枚举形式单例

• 介绍一种最简略的实现形式，基于枚举类型的单例实现。这种实现形式通过 Java 枚举类型自身的个性，保障了实例创立的线程安全性和实例的唯一性。具体的代码如下所示：

  public enum Singleton {  //enum 枚举类
      INSTANCE; 
      public void whateverMethod() {} 
  }

• 代码剖析

  • 枚举单例模式最大的长处就是写法简略，枚举在 java 中与一般的类是一样的，不仅可能有字段，还可能有本人的办法，最重要的是默认枚举实例是线程平安的，并且在任何状况下，它都是一个单例。即便是在反序列化的过程，枚举单例也不会从新生成新的实例。而其余几种形式，必须退出如下办法：能力保障反序列化时不会生成新的对象。

    private Object readResolve()  throws ObjectStreamException{return INSTANCE;}

07. 容器实现单例模式

• 这一种比拟少见，间接上代码，如下所示：

  public class SingletonManager {private static Map<String, Object> objMap = new HashMap<String,Object>();// 应用 HashMap 作为缓存容器
      private Singleton() {}
    public static void registerService(String key, Object instance) {if (!objMap.containsKey(key) ) {objMap.put(key, instance) ;// 第一次是存入 Map
      }
    }
    public static ObjectgetService(String key) {return objMap.get(key) ;// 返回与 key 绝对应的对象
    }
  }

• 代码剖析

  • 在程序的初始，将多种单例模式注入到一个对立的治理类中，在应用时依据 key 获取对应类型的对象。

5. 单例模式总结

• 总结：不论以哪种模式实现单例模式，它们的外围原理是将构造函数私有化，并且通过动态私有办法获取一个惟一的实例，在这个获取的过程中必须保障线程的平安，同时也要避免反序列化导致从新生成实例对象。
• 一般来说，单例模式有五种写法：懒汉、饿汉、双重测验锁、动态外部类、枚举。上述所说都是线程平安的实现，上文中第一种形式线程不平安，排除。

• 综合思考：

  • 举荐应用 4.4 DCL 双重校验模式，4.5 动态外部类单例模式等等
  • 个别状况下间接应用饿汉式就好了，如果明确要求要懒加载（lazy initialization）偏向于应用动态外部类。如果波及到反序列化创建对象时会试着应用枚举的形式来实现单例。
• 单例对象如果持有 Context，那么很容易引发内存透露，此时要留神传递给单例对象的 Context 最好是 Application Context

更多内容

• GitHub：https://github.com/yangchong211
• 博客：https://juejin.cn/user/197877…
• 博客汇总：https://github.com/yangchong2…