设计模式-单例模式☞10种不一样的艳遇让你精通单例

1.引言

单例设计模式（Singleton Pattern）是最简单且常见的设计模式之一，在它的核心结构中只包含一个被称为单例的特殊类。通过单例模式可以保证系统中一个类只有一个实例而且该实例易于外界访问，从而方便对实例个数的控制并节约系统资源。如果希望在系统中某个类的对象只能存在一个，避免多实例对象的情况下引起逻辑性错误（实例化数量可控）单例模式是最好的解决方案。

1、单例类只能有一个实例。
2、单例类必须自己创建自己的唯一实例。
3、单例类必须给所有其他对象提供这一实例。

2.概述

Java中，单例模式主要分四种：懒汉式单例、饿汉式单例、登记式单例、ThreadLocal单例模式四种。

懒汉：非线程安全，需要用一定的风骚操作控制，装逼失败有可能导致看一周的海绵宝宝
饿汉：天生线程安全，ClassLoad的时候就已经实例化好，该操作过于风骚会造成资源浪费
单例注册表：Spring初始化Bean的时候，默认单例用的就是该方式
单例模式有饿汉模式、懒汉模式、静态内部类、枚举等方式实现，这些模式的构造方法是私有的，不可继承
登记式单例使得单例对继承开放
ThreadLocal 是线程副本形式,可以保证局部单例，即在各自的线程中是单例的，但是线程与线程之间不保证单例。

$\color{#4285f4}{1.特点}$

1. 私有构造方法，只能有一个实例。
2. 私有静态引用指向自己实例，必须是自己在内部创建的唯一实例。
3. 单例类给其它对象提供的都是自己创建的唯一实例

$\color{#4285f4}{2.案例}$

1. 在计算机系统中，内存、线程、CPU等使用情况都可以再任务管理器中看到，但始终只能打开一个任务管理器，它在Windows操作系统中是具备唯一性的，因为弹多个框多次采集数据浪费性能不说，采集数据存在误差那就有点逗比了不是么…
2. 每台电脑只有一个打印机后台处理程序
3. 线程池的设计一般也是采用单例模式，方便对池中的线程进行控制

$\color{#4285f4}{3.注意事项}$

 1. 实现方式种类较多，有的非线程安全方式的创建需要特别注意，且在使用的时候尽量根据场景选取较优的，线程安全了还需要去考虑性能问题。
 2. 不适用于变化的对象，如果同一类型的对象总是要在不同的用例场景发生变化，单例就会引起数据的错误，不能保存彼此的状态。
 3. 没有抽象层，扩展有困难。
 4. 职责过重，在一定程度上违背了单一职责原则。
 5. 使用时不能用反射模式创建单例，否则会实例化一个新的对象

3.开启艳遇

$\color{#9932CC}{第一种艳遇:}\color{#34a853}{单一检查（懒汉）非线程安全}$

public class LazyLoadBalancer {

    private static LazyLoadBalancer loadBalancer;
    private List<String> servers = null;

    private LazyLoadBalancer() {
        servers = new ArrayList<>();
    }

    public void addServer(String server) {
        servers.add(server);
    }

    public String getServer() {
        Random random = new Random();
        int i = random.nextInt(servers.size());
        return servers.get(i);
    }

    public static LazyLoadBalancer getInstance() {
        // 第一步：假设T1,T2两个线程同时进来且满足 loadBalancer == null
        if (loadBalancer == null) {
            // 第二步：那么 loadBalancer 即会被实例化2次
            loadBalancer = new LazyLoadBalancer();
        }
        return loadBalancer;
    }

    public static void main(String[] args) {
        LazyLoadBalancer balancer1 = LazyLoadBalancer.getInstance();
        LazyLoadBalancer balancer2 = LazyLoadBalancer.getInstance();
        System.out.println("hashCode："+balancer1.hashCode());
        System.out.println("hashCode："+balancer2.hashCode());
        balancer1.addServer("Server 1");
        balancer2.addServer("Server 2");
        IntStream.range(0, 5).forEach(i -> System.out.println("转发至：" + balancer1.getServer()));
    }
}

分析：在单线程环境一切正常，balancer1和balancer2两个对象的hashCode一模一样，由此可以判断出堆栈中只有一份内容，不过该代码块中存在线程安全隐患，因为缺乏竞争条件，多线程环境资源竞争的时候就显得不太乐观了，请看上文代码注释内容

$\color{#9932CC}{第二种艳遇：}\color{#34a853}{无脑上锁（懒汉）线程安全，性能较差，第一种升级版}$

public synchronized static LazyLoadBalancer getInstance() {
    if (loadBalancer == null) {
        loadBalancer = new LazyLoadBalancer();
    }
    return loadBalancer;
}

分析： 毫无疑问，知道synchronized关键字的都知道，同步方法在锁没释放之前，其它线程都在排队候着呢，想不安全都不行啊，但在安全的同时，性能方面就显得短板了，我就初始化一次，你丫的每次来都上个锁，不累的吗（没关系，它是为了第三种做铺垫的）..

$\color{#9932CC}{第三种艳遇：}\color{#34a853}{双重检查锁（DCL），完全就是前两种的结合体啊，有木有，只是将同步方法升级成了同步代码块}$

//划重点了 **volatile**
private volatile static LazyLoadBalancer loadBalancer;

public static LazyLoadBalancer getInstance() {
    if (loadBalancer == null) {
        synchronized (LazyLoadBalancer.class) {
            if (loadBalancer == null) {
                loadBalancer = new LazyLoadBalancer();
            }
        }
    }
    return loadBalancer;
}

分析：

假设new LazyLoadBalancer()加载内容过多
因重排而导致loadBalancer提前不为空
正好被其它线程观察到对象非空直接返回使用一种罕见的单例空指针突然来袭

存在问题： 首先我们一定要清楚，DCL是不能保证线程安全的，稍微了解过JVM的就清楚，对比C/C++它始终缺少一个正式的内存模型，所以为了提升性能，它还会做一次指令重排操作，这个时候就会导致loadBalancer提前不为空，正好被其它线程观察到对象非空直接返回使用（但实际还有部分内容没加载完成）
解决方案： 用volatile修饰loadBalancer，因为volatile修饰的成员变量可以确保多个线程都能够顺序处理，它会屏蔽JVM指令重排带来的性能优化。

$\color{#9932CC}{第四种艳遇：}\color{#34a853}{Demand Holder，静态内部类（懒汉）线程安全，推荐使用}$

private LazyLoadBalancer() {}

private static class LoadBalancerHolder {
    //在JVM中 final 对象只会被实例化一次,无法修改
    private final static LazyLoadBalancer INSTANCE = new LazyLoadBalancer();
}

public static LazyLoadBalancer getInstance() {
    return LoadBalancerHolder.INSTANCE;
}

分析： 在Demand Holder中，我们在LazyLoadBalancer里增加一个静态(static)内部类，在该内部类中创建单例对象，再将
该单例对象通过getInstance()方法返回给外部使用，由于静态单例对象没有作为LazyLoadBalancer的成员变量直接实例化，类加载时并不会实例化LoadBalancerHolder，因此既可以实现延迟加载，又可以保证线程安全，不影响系统性能（居家旅行必备良药啊）

双重校验锁版，不管性能再如何优越，还是使用了synchronized修饰符，既然使用了该修饰符，那么对性能多多少少都会造成一些影响，于是乎Demand Holder诞生,涉及内部类的加载机制，复习一下,代码如下:

package test;

public class OuterTest {

    static {
        System.out.println("load outer class...");
    }

    // 静态内部类
    static class StaticInnerTest {
        static {
            System.out.println("load static inner class...");
        }

        static void staticInnerMethod() {
            System.out.println("static inner method...");
        }
    }

    public static void main(String[] args) {
        OuterTest outerTest = new OuterTest(); // 此刻其内部类是否也会被加载？
        System.out.println("===========分割线===========");
        OuterTest.StaticInnerTest.staticInnerMethod(); // 调用内部类的静态方法
    }

}

输出如下:

load outer class...
===========分割线===========
load static inner class...
static inner method

因此，我们有如下结论:

1. 加载一个类时，其内部类不会同时被加载。
2. 一个类被加载，当且仅当其某个静态成员（静态域、构造器、静态方法等）被调用时发生。

$\color{#9932CC}{第五种艳遇：}\color{#34a853}{懒汉式，防止反射|序列化|反序列化}$

package singleton;

import java.io.Serializable;

public class LazySingleton4 implements Serializable {

    private static boolean initialized = false;

    private LazySingleton4() {
        synchronized (LazySingleton4.class) {
            if (initialized == false) {
                initialized = !initialized;
            } else {
                throw new RuntimeException("单例已被破坏");
            }
        }
    }

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

    public static LazySingleton4 getInstance() {
        return SingletonHolder.instance;
    }
    
    
    //序列化 防止序列化被破坏单例
    private Object readResolve() {
        return getInstance();
    }
}

分析： 1. 我们知道反射可以创建对象,那我们由反射的原理即防止反射破坏了单例，因此诞生了如上文的单例

2.在分布式系统中，有些情况下你需要在单例类中实现 Serializable 接口。这样你可以在文件系统中存储它的状态并且在稍后的某一时间点取出,为了避免此问题，我们需要提供 readResolve() 方法的实现。readResolve()代替了从流中读取对象。这就确保了在序列化和反序列化的过程中没人可以创建新的实例

为什么反序列化可以破坏呢?我们一起来看下ois.readObject()的源码：

private Object readObject0(boolean unshared) throws IOException {
    ...省略
    case TC_OBJECT:
      return checkResolve(readOrdinaryObject(unshared));
}
-------------------------------------------------------------------
private Object readOrdinaryObject(boolean unshared){
    if (bin.readByte() != TC_OBJECT) {
            throw new InternalError();
        }

        ObjectStreamClass desc = readClassDesc(false);
        desc.checkDeserialize();

        Class<?> cl = desc.forClass();
        if (cl == String.class || cl == Class.class
                || cl == ObjectStreamClass.class) {
            throw new InvalidClassException("invalid class descriptor");
        }

        Object obj;
        try {
    //重点！！！
    //首先isInstantiable()判断是否可以初始化
    //如果为true，则调用newInstance()方法创建对象，这时创建的对象是不走构造函数的，是一个新的对象
            obj = desc.isInstantiable() ? desc.newInstance() : null;
        } catch (Exception ex) {
            throw (IOException) new InvalidClassException(
                desc.forClass().getName(),
                "unable to create instance").initCause(ex);
        }

        passHandle = handles.assign(unshared ? unsharedMarker : obj);
        ClassNotFoundException resolveEx = desc.getResolveException();
        if (resolveEx != null) {
            handles.markException(passHandle, resolveEx);
        }

        if (desc.isExternalizable()) {
            readExternalData((Externalizable) obj, desc);
        } else {
            readSerialData(obj, desc);
        }

        handles.finish(passHandle);
    
    //重点！！！
    //hasReadResolveMethod()会去判断，我们的InnerClassSingleton对象中是否有readResolve()方法
        if (obj != null &&
            handles.lookupException(passHandle) == null &&
            desc.hasReadResolveMethod())
        {
    //如果为true，则执行readResolve()方法，而我们在自己的readResolve()方法中 直接retrun INSTANCE，所以还是返回的同一个对象，保证了单例
            Object rep = desc.invokeReadResolve(obj);
            if (unshared && rep.getClass().isArray()) {
                rep = cloneArray(rep);
            }
            if (rep != obj) {
                // Filter the replacement object
                if (rep != null) {
                    if (rep.getClass().isArray()) {
                        filterCheck(rep.getClass(), Array.getLength(rep));
                    } else {
                        filterCheck(rep.getClass(), -1);
                    }
                }
                handles.setObject(passHandle, obj = rep);
            }
        }

        return obj;
}

$\color{#9932CC}{第六种艳遇：}\color{#34a853}{枚举特性（懒汉）线程安全，推荐使用}$

enum Lazy {
    INSTANCE;
    private LazyLoadBalancer loadBalancer;

    //枚举的特性,在JVM中只会被实例化一次
    Lazy() {
        loadBalancer = new LazyLoadBalancer();
    }

    public LazyLoadBalancer getInstance() {
        return loadBalancer;
    }
}

分析： 相比上一种，该方式同样是用到了JAVA特性：枚举类保证只有一个实例（即使使用反射机制也无法多次实例化一个枚举量）

$\color{#9932CC}{第七种艳遇:}\color{#34a853}{饿汉单例（天生线程安全）}$

public class EagerLoadBalancer {
    private final static EagerLoadBalancer INSTANCE = new EagerLoadBalancer();

    private EagerLoadBalancer() {}

    public static EagerLoadBalancer getInstance() {
        return INSTANCE;
    }
}

分析： 利用ClassLoad机制，在加载时进行实例化，同时静态方法只在编译期间执行一次初始化，也就只有一个对象。使用的时候已被初始化完毕可以直接调用，但是相比懒汉模式，它在使用的时候速度最快，但这玩意就像自己挖的坑哭着也得跳，你不用也得初始化一份在内存中占个坑… 但是写着简单_啊~

$\color{#9932CC}{第八种艳遇:}\color{#34a853}{登记式单例}$


public class RegistSingleton {
    //用ConcurrentHashMap来维护映射关系，这是线程安全的
    public static final Map<String,Object> REGIST=new ConcurrentHashMap<String, Object>();
    static {
        //把RegistSingleton自己也纳入容器管理
        RegistSingleton registSingleton=new RegistSingleton();
        REGIST.put(registSingleton.getClass().getName(),registSingleton);
    }
    private RegistSingleton(){}
    public static Object getInstance(String className){
        //如果传入的类名为空，就返回RegistSingleton实例
        if(className==null)
            className=RegistSingleton.class.getName();
            //如果没有登记就用反射new一个
        if (!REGIST.containsKey(className)){
            //没有登记就进入同步块
            synchronized (RegistSingleton.class){
            //再次检测是否登记
                if (!REGIST.containsKey(className)){
                    try {
                    //实例化对象
                        REGIST.put(className,Class.forName(className).newInstance());
                    } catch (InstantiationException e) {
                        e.printStackTrace();
                    } catch (IllegalAccessException e) {
                        e.printStackTrace();
                    } catch (ClassNotFoundException e) {
                        e.printStackTrace();
                    }
                }
            }
        }
        //返回单例
        return REGIST.get(className);
    }
}

来一把测试:

public class Main {
    static CyclicBarrier cyclicBarrier=new CyclicBarrier(1000);
    public static void main(String[] args) {
        for (int i = 0; i <1000 ; i++) {
            int n = i;
            new Thread(()->{
                System.out.println("线程"+ n +"准备就绪");
                try {
                    cyclicBarrier.await();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } catch (BrokenBarrierException e) {
                    e.printStackTrace();
                }
                System.out.println(RegistSingleton.getInstance("singletonpattern.regist.ClassA"));
            }).start();
        }
    }
}

输出结果:是线程安全的（ClassA是一个空类，里面什么也没有）

来来领略一下 Spring的源码:

public abstract class AbstractBeanFactory implements ConfigurableBeanFactory{    
   /**  
    * 充当了Bean实例的缓存，实现方式和单例注册表相同  
    */    
   private final Map singletonCache=new HashMap();    
   public Object getBean(String name)throws BeansException{    
       return getBean(name,null,null);    
   }    
...    
   public Object getBean(String name,Class requiredType,Object[] args)throws BeansException{    
      //对传入的Bean name稍做处理，防止传入的Bean name名有非法字符(或则做转码)    
      String beanName=transformedBeanName(name);    
      Object bean=null;    
      //手工检测单例注册表    
      Object sharedInstance=null;    
      //使用了代码锁定同步块，原理和同步方法相似，但是这种写法效率更高    
      synchronized(this.singletonCache){    
         sharedInstance=this.singletonCache.get(beanName);    
       }    
      if(sharedInstance!=null){    
         ...    
         //返回合适的缓存Bean实例    
         bean=getObjectForSharedInstance(name,sharedInstance);    
      }else{    
        ...    
        //取得Bean的定义    
        RootBeanDefinition mergedBeanDefinition=getMergedBeanDefinition(beanName,false);    
         ...    
        //根据Bean定义判断，此判断依据通常来自于组件配置文件的单例属性开关    
        //<bean id="date" class="java.util.Date" scope="singleton"/>    
        //如果是单例，做如下处理    
        if(mergedBeanDefinition.isSingleton()){    
           synchronized(this.singletonCache){    
            //再次检测单例注册表    
             sharedInstance=this.singletonCache.get(beanName);    
             if(sharedInstance==null){    
                ...    
               try {    
                  //真正创建Bean实例    
                  sharedInstance=createBean(beanName,mergedBeanDefinition,args);    
                  //向单例注册表注册Bean实例    
                   addSingleton(beanName,sharedInstance);    
               }catch (Exception ex) {    
                  ...    
               }finally{    
                  ...    
              }    
             }    
           }    
          bean=getObjectForSharedInstance(name,sharedInstance);    
        }    
       //如果是非单例，即prototpye，每次都要新创建一个Bean实例    
       //<bean id="date" class="java.util.Date" scope="prototype"/>    
       else{    
          bean=createBean(beanName,mergedBeanDefinition,args);    
       }    
}    
...    
   return bean;    
}    
}

分析： 登记式单例实际上维护的是一组单例类的实例，将这些实例存储到一个Map(登记簿)中，对于已经登记过的单例，则从工厂直接返回，对于没有登记的，则先登记，而后返回

使用map实现注册表；
使用protect修饰构造方法；

有的时候，我们不希望在一开始的时候就把一个类写成单例模式，但是在运用的时候，我们却可以像单例一样使用他

最典型的例子就是spring，他的默认类型就是单例，spring是如何做到把不是单例的类变成单例呢？

这就用到了登记式单例

其实登记式单例并没有去改变类，他所做的就是起到一个登记的作用，如果没有登记，他就给你登记，并把生成的实例保存起来，下次你要用的时候直接给你。

IOC容器就是做的这个事，你需要就找他去拿，他就可以很方便的实现Bean的管理。

$\color{#9932CC}{第九种艳遇:}\color{#34a853}{ ThreadLocal 局部单例}$

public class Singleton {
    
    private Singleton(){}
    
    private static final ThreadLocal<Singleton> threadLocal = 
            new ThreadLocal<Singleton>(){
                @Override
                protected Singleton initialValue(){
                    return new Singleton();
                }
            };
    
    public static Singleton getInstance(){
        return threadLocal.get();
    }
    
}

分析： 这种写法利用了ThreadLocal的特性，可以保证局部单例，即在各自的线程中是单例的，但是线程与线程之间不保证单例。

initialValue()一般是用来在使用时进行重写的，如果在没有set的时候就调用get，会调用initialValue方法初始化内容。

ThreadLocal会为每一个线程提供一个独立的变量副本，从而隔离了多个线程对数据的访问冲突。对于多线程资源共享的问题，同步机制采用了“以时间换空间”的方式，而ThreadLocal采用了“以空间换时间”的方式。前者仅提供一份变量，让不同的线程排队访问，而后者为每一个线程都提供了一份变量，即线程隔离，因此可以同时访问而互不影响。

$\color{#9932CC}{第十种艳遇:}\color{#34a853}{ 使用CAS锁实现（线程安全）}$

/**
 * 更加优美的Singleton, 线程安全的
 */
public class Singleton {
 /** 利用AtomicReference */
 private static final AtomicReference<Singleton> INSTANCE = new AtomicReference<Singleton>();
 /**
  * 私有化
  */
 private Singleton(){
 }
 /**
  * 用CAS确保线程安全
  */
 public static final Singleton getInstance(){
  for (;;) {
   Singleton current = INSTANCE.get();
            if (current != null) {
                return current;
            }
            current = new Singleton();
            if (INSTANCE.compareAndSet(null, current)) {
                return current;
            }
        }
 }
 
 public static void main(String[] args) {
  Singleton singleton1 = Singleton.getInstance();
  Singleton singleton2 = Singleton.getInstance();
     System.out.println(singleton1 == singleton2);
 }
}

分析：
CAS 是线程安全的,使用了无锁编程. 这种方式当在大量线程去获取实例的时候,会造成CPU的激情燃烧~

4.总结

本文给出了多个版本的单例模式，供我们在项目中使用。实际上，我们在实际项目中一般从艳遇四、五、六中，根据实际情况三选一即可。
最后，希望大家有所收获。

最后编辑于：2019.07.29 15:02:22

人面猴
序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
沈念sama阅读 203,547评论 6赞 477
死咒
序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
沈念sama阅读 85,399评论 2赞 381
救了他两次的神仙让他今天三更去死
文/潘晓璐我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
开封第一讲书人阅读 150,428评论 0赞 337
道士缉凶录：失踪的卖姜人
文/不坏的土叔我叫张陵，是天一观的道长。经常有香客问我，道长，这世上最难降的妖魔是什么？我笑而不...
开封第一讲书人阅读 54,599评论 1赞 274
港岛之恋（遗憾婚礼）
正文为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
茶点故事阅读 63,612评论 5赞 365
恶毒庶女顶嫁案：这布局不是一般人想出来的
文/花漫我一把揭开白布。她就那样静静地躺着，像睡着了一般。火红的嫁衣衬着肌肤如雪。梳的纹丝不乱的头发上，一...
开封第一讲书人阅读 48,577评论 1赞 281
城市分裂传说
那天，我揣着相机与录音，去河边找鬼。笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。我是一名探鬼主播，决...
沈念sama阅读 37,941评论 3赞 395
双鸳鸯连环套：你想象不到人心有多黑
文/苍兰香墨我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
开封第一讲书人阅读 36,603评论 0赞 258
万荣杀人案实录
序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
沈念sama阅读 40,852评论 1赞 297
护林员之死
正文独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋以下内容为张勋视角年9月15日...
茶点故事阅读 35,605评论 2赞 321
白月光启示录
正文我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
茶点故事阅读 37,693评论 1赞 329
活死人
序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
沈念sama阅读 33,375评论 4赞 318
日本核电站爆炸内幕
正文年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
茶点故事阅读 38,955评论 3赞 307
男人毒药：我在死后第九天来索命
文/蒙蒙一、第九天我趴在偏房一处隐蔽的房顶上张望。院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
开封第一讲书人阅读 29,936评论 0赞 19
一桩弑父案，背后竟有这般阴谋
文/苍兰香墨我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。一阵脚步声响...
开封第一讲书人阅读 31,172评论 1赞 259
情欲美人皮
我被黑心中介骗来泰国打工，没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。一个月前我还...
沈念sama阅读 43,970评论 2赞 349
代替公主和亲
正文我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
茶点故事阅读 42,414评论 2赞 342

设计模式-单例模式☞10种不一样的艳遇 让你精通单例

1.引言

2.概述

3.开启艳遇

4.总结

推荐阅读更多精彩内容

设计模式-单例模式☞10种不一样的艳遇让你精通单例