学点架构设计—单例模式

Posted 2021-05-01 51Testing软件测试网

　　写在前面

　　写代码久了不想只是做一个写if else的初级码农，随着coding经验的积累以及对这份职业的更高期望，越来越认识到被设计过的代码是那么的优美而性感。凡事皆有道，coding的道就是程序员前辈们发现和总结出来的各种模式，为了深刻地理解前人写的优秀的代码，也为了在工作中写出更具水平的更高质量的代码来，有必要学一学设计模式。其实我在工作学习中很早就在学习和使用设计模式了，但一直没有系统地学习总结，所以用过就忘掉了，对每种模式的内涵知之甚浅，惭愧！！现在我想系统地再学一学这些，并用文字记录下自己所学的内容，以加深理解并方便以后查阅。

　　定义及特点

　　单例模式确保一个类只有一个实例，并提供一个全局访问点。其类结构图如下：

　　单例模式是对象创建型模式，要实现一个单例类需满足以下几个要素：

　　（1） 一个私有的构造方法

　　（2） 一个指向自己实例的私有的静态引用

　　（3） 一个返回自己实例的公有的静态方法

　　所以一个单例类应类似下面的伪代码：

　　public class Singleton{

　　private Singleton(){} //私有的构造方法

　　private static Singleton singleton; //指向自己实例的私有静态引用

　　public static Singleton getInstance(){ //返回自己实例的公有静态方法

　　…… //创建本单例类的唯一实例，并赋值给私有静态引用

　　return singleton;

　　}

　　}

　　另外，如果要考虑单例类的防攻击，在实现时还需要做到防止反序列化、防止反射、防止克隆。

　　//readResolve method to preserve Singleton property

　　private Object readResolve() throws ObjectStreamException {

　　return INSTANCE;

　　}

　　//防止反射调用后创建新的Singleton实例

　　private static boolean flag = false;

　　private Singleton(){

　　synchronized(Singleton.class)

　　{

　　if(flag == false){

　　flag = !flag;

　　} else{

　　throw new RuntimeException("单例模式被侵犯！");

　　}

　　}

　　}

　　//防止克隆产生新的实例

　　@Override

　　protected Object clone() throws CloneNotSupportedException {

　　throw new CloneNotSupportedException("Cannot clone instance of this class");

　　}

　　因为单例类对象的生命周期是从实例被创建到应用程序结束，所以一个高质量的单例类还需要满足以下特点：

　　√ 懒加载 —— 在需要时才创建单例类的实例

　　√ 线程安全 —— 应保证在多线程环境下访问单例类不会创建多个实例

　　√ 高性能 —— 获取单例对象的过程中应减少同步的消耗

　　适用场景

　　由于单例类保证一个类只有一个实例，并且由此表现出了一些其他优点，使得单例模式是在开发中比较常用的一种设计模式。根据单例类的优点，单例模式通常适用于以下场景的类创建：

　　● 需要频繁实例化然后销毁的对象

　　● 创建对象时耗时过多或者耗资源过多，但又经常用到的对象

　　● 有状态的工具类对象

　　● 频繁访问数据库或文件的对象

　　● 需要保证数据一致性的配置文件类或工具类对象

　　实现方式

　　根据单例模式的思想内容以及单例类能解决的问题，单例模式的实现方式有多种，不同的实现方式可能在单例对象的实例化时机、线程安全性和访问性能方面有所不同。下面分别整理各种实现方式及其优缺点。

　　饿汉式单例

　　public class Singleton {

　　private static Singleton instance=new Singleton();

　　private Singleton(){}

　　public static Singleton getInstance(){

　　return instance;

　　}

　　}

　　这种单例实现方法之所以被称为饿汉式是因为它利用JVM机制在单例类被加载时实例化。其实例化时机比较早，所以没有实现懒加载（Lazy Loading），即使这个实例在应用的生命周期内没有被使用到，也会因为已经被加载而占用一定的内存空间；另外这种实现方式也无法给单例的实例化过程传入必须的参数。饿汉式的实现方式比较简单，在单例类被加载到内存时就完成了实例化，避免了线程同步的问题；另外因为实例没有被使用而造成的内存浪费问题可以忽略，饿汉式单例的实现方式是被推荐使用的。

　　饿汉式单例的实例化过程还有一种写法，不过本质上也是利用JVM的类加载机制，只是语法的应用而已，如下：

　　private static Singleton instance = null;

　　static {

　　instance = new Singleton();

　　}

　　懒汉式单例

　　懒汉式单例的实现目的就是为了达到单例类的懒加载，即在单例类第一次被使用到的时候实例化该单例类，对应到单例类实现的基本要素就是在返回单例类实例的公有静态方法中去实例化单例对象。懒汉式单例的最直接最简单的实现如下：

　　public class Singleton {

　　private static Singleton instance=null;

　　private Singleton() {}

　　public static Singleton getInstance(){

　　if(instance==null) {

　　instance=new Singleton();

　　}

　　return instance;

　　}

　　}

　　上述实现方式在实际项目中并不可取，因为它存在线程安全问题，当有多个线程去调用getInstance()方法获取Singleton的实例时，有可能得到的不是同一个对象，即有可能每个线程访问getInstance()方法时各自创建一个Singleton实例。要解决这种实现方式的线程安全问题，可以考虑加锁进行同步。

　　public class Singleton {

　　private static Singleton instance=null;

　　private Singleton() {};

　　public static synchronized Singleton getInstance(){

　　if(instance==null){

　　instance=new Singleton();

　　}

　　return instance;

　　}

　　}

　　上面的改进是在getInstance()方法上加锁进行同步，这样虽然解决了线程安全的问题，但又带来了访问效率低下的问题。每个线程在访问getInstance()方法获得类实例的时候，都要进行同步操作，而其实这个方法只需执行一次实例化代码就够了，只要单例对象还存在就可以直接return给访问者。对懒汉式单例进一步优化得到了既能保证线程安全又能有较高的访问效率的双重检查锁(Double Checked Locking)实现。

　　public class Singleton {

　　private static volatile Singleton instance=null;

　　private Singleton() {}

　　public static Singleton getInstance(){

　　if (instance == null) {

　　synchronized (Singleton.class) {

　　if (instance == null) {

　　instance = new Singleton();

　　}

　　}

　　}

　　return instance;

　　}

　　}

　　双重检查锁的实现方式是比较健壮的懒汉式单例实现，有两个问题需要理解：

　　1、双重检查有什么意义

　　双重检查就是在getInstance()方法中有两次检查 instance == null，一次是在同步块外，一次是在同步块内。为什么在同步块内还要再检查一次？因为可能会有多个线程一起进入同步块外的 if，如果在同步块内不进行二次检查的话就会生成多个实例了。

　　2、静态引用instance前的volatile关键字有何作用

　　主要在于instance = new Singleton()这句并非是一个原子操作，在JVM中这句话大概做了下面 3 件事情：

　　① 给 instance 分配内存

　　② 调用 Singleton 的构造函数来初始化成员变量

　　③ 将instance对象指向分配的内存空间（执行完这步 instance 就为非 null 了）

　　但是在JVM的即时编译器中存在指令重排序的优化，也就是说上面的第二步和第三步的顺序是不能保证的，最终的执行顺序可能是 ①-②-③ 也可能是 ①-③-②。如果是后者，则在 ③ 执行完毕、② 未执行之前，被线程二抢占了，这时 instance 已经是非 null 了（但却没有初始化），所以线程二会直接返回 instance，然后使用，然后就会报错。

　　在Java1.5以后的版本中volatile修饰符具有禁止指令重排序优化的特性，也就是说在 volatile 变量的赋值操作后面会有一个内存屏障（生成的汇编代码上），读操作不会被重排序到内存屏障之前。比如上面的例子，取操作必须在执行完 ①-②-③ 或者 ①-③-② 之后，不存在执行到 ①-③ 然后取到值的情况。从「先行发生原则」的角度理解的话，就是对于一个 volatile 变量的写操作都先行发生于后面对这个变量的读操作（这里的“后面”是时间上的先后顺序）。

　　静态内部类实现单例

　　public class Singleton{

　　private Singleton() {}

　　private static class SingletonHolder{

　　private static Singleton instance=new Singleton();

　　}

　　public static Singleton getInstance(){

　　return SingletonHolder.instance;

　　}

　　}

　　通过在类中创建一个静态内部类来实现单例模式也是利用了JVM的类加载机制保证只创建一份实例，同时与饿汉式单例一样具有线程安全性，而且客户在获取这个单例类实例的时候不会进行同步，没有性能缺陷，也不依赖 JDK 版本。静态内部类方式在Singleton类被装载时并不会立即实例化，而是在需要实例化时调getInstance()方法，才会装载SingletonHolder类实例化Singleton，这样就实现了单例类的懒加载。

　　由于使用静态内部类实现单例避免了线程不安全的问题，并且有较高的访问效率以及实现了延迟加载，这种方式是值得推荐的单例实现方式，当然这种方式与饿汉式单例一样不能传入参数。

　　枚举实现单例

　　public enum Singleton {

　　INSTANCE;

　　private Singleton() {}

　　public void method() {

　　}

　　}

　　从Java1.5版本起，创建单例可以使用简洁的枚举类型。我们直接通过Singleton.INSTANCE来访问实例，创建枚举默认就是线程安全的，所以不需要考虑double checked locking，而且枚举还能防止反序列化或者反射攻击导致创建新的实例。《Effective Java》中更是说明单元素的枚举类型已经成为实现Singleton的最佳方法。

　　单例模式小结

　　单例模式是类结构和模式思想最简单的一种设计模式，也是实际项目在被使用最多的一种模式，android SDK的许多类以及许多第三方开源库都提供了很多有单例行为的类。单例模式的实现方式有多种，但在实际使用时需要认真考量单例类的线程安全性、访问效率和懒加载属性，所有的限制和设计都要保证Singleton类仅仅被实例化一次。

 

推荐阅读

点击阅读☞

点击阅读☞

点击阅读☞

点击阅读☞

点击阅读☞

点击左下角“阅读原文”查看更多内容！