十次艳遇单例设计模式（Singleton Pattern）

 

1.引言

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

• 1、单例类只能有一个实例。

• 2、单例类必须自己创建自己的唯一实例。

• 3、单例类必须给所有其他对象提供这一实例。

2.概述

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

• 懒汉：非线程安全，需要用一定的风骚操作控制，装逼失败有可能导致看一周的海绵宝宝

• 饿汉：天生线程安全，ClassLoad的时候就已经实例化好，该操作过于风骚会造成资源浪费

• 单例注册表：Spring初始化Bean的时候，默认单例用的就是该方式

• 单例模式有饿汉模式、懒汉模式、静态内部类、枚举等方式实现，这些模式的构造方法是私有的，不可继承

• 登记式单例 使得单例对继承开放

• ThreadLocal 是线程副本形式,可以保证局部单例，即在各自的线程中是单例的，但是线程与线程之间不保证单例。

1.特点

1. 私有构造方法，只能有一个实例。

2. 私有静态引用指向自己实例，必须是自己在内部创建的唯一实例。

3. 单例类给其它对象提供的都是自己创建的唯一实例

2.案例

1. 在计算机系统中，内存、线程、CPU等使用情况都可以在任务管理器中看到，但始终只能打开一个任务管理器，它在Windows操作系统中是具备唯一性的，因为弹多个框多次采集数据浪费性能不说，采集数据存在误差那就有点逗比了不是么…

2. 每台电脑只有一个打印机后台处理程序

3. 线程池的设计一般也是采用单例模式，方便对池中的线程进行控制

3.注意事项

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

3.开启艳遇

第一种艳遇:

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一模一样，由此可以判断出堆栈中只有一份内容，不过该代码块中存在线程安全隐患，因为缺乏竞争条件，多线程环境资源竞争的时候就显得不太乐观了，请看上文代码注释内容

 

第二种艳遇：无脑上锁（懒汉）线程安全，性能较差，第一种升级版

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

分析：

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

 

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

//划重点了 **volatile**1 private volatile static LazyLoadBalancer loadBalancer;23 public static LazyLoadBalancer getInstance() {4    if (loadBalancer == null) {5        synchronized (LazyLoadBalancer.class) {6            if (loadBalancer == null) {7               loadBalancer = new LazyLoadBalancer();8            }0        }10    }11    return loadBalancer;12 }

假如没有volatile情况下产生的问题: 如果第一次检查loadBalancer不为null，那么就不需要执行下面的加锁和初始化操作。因此，可以大幅降低synchronized带来的性能开销。在线程执行到第4行，代码读取到loadBalancer不为null时，loadBalancer引用的对象有可能还没有完成初始化。在第7行创建了一个对象，这行代码可以分解为如下的3行伪代码:

memory=allocate(); //1:分配对象的内存空间
ctorInstance(memory); //2:初始化对象
instance=memory; //3:设置instance指向刚分配的内存地址

上面3行代码中的2和3之间，可能会被重排序（在一些JIT编译器上，这种重排序是真实发生的，如果不了解重排序，后文JMM会详细解释）。2和3之间重排序之后的执行时序如下

memory=allocate(); //1:分配对象的内存空间
instance=memory; //3:设置instance指向刚分配的内存地址，注意此时对象还没有被初始化
ctorInstance(memory); //2:初始化对象

回到示例代码第7行，如果发生重排序，另一个并发执行的线程B就有可能在第4行判断instance不为null。线程B接下来将访问instance所引用的对象，但此时这个对象可能还没有被A线程初始化,可能导致NPE。

分析：

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

第四种艳遇：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. 一个类被加载，当且仅当其某个静态成员（静态域、构造器、静态方法等）被调用时发生。

第五种艳遇：懒汉式，  防止反射|序列化|反序列化​​​​​​​

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;}

第六种艳遇: 枚举特性（懒汉）线程安全，推荐使用​​​​​​​

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

分析：

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

 

第七种艳遇:饿汉单例（天生线程安全）​​​​​​​

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

分析：

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

 

第八种艳遇:登记式单例​​​​​​​

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的管理。

 

第九种艳遇: 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采用了“以空间换时间”的方式。前者仅提供一份变量，让不同的线程排队访问，而后者为每一个线程都提供了一份变量，即线程隔离，因此可以同时访问而互不影响。

第十种艳遇: 使用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.总结

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

最后：

『java进阶架构师』短短一年在各大平台斩获15W+程序员关注，专注分享Java进阶、架构技术、高并发、大数据、AI、Python、程序员成长等20大专题，同样期待你的关注。
转载说明：务必注明来源（注明：来源于公众号：java进阶架构师）