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

1.引言

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

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

• 二、单例类必须本身建立本身的惟一实例。

• 三、单例类必须给全部其余对象提供这一实例。

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.总结

本文给出了多个版本的单例模式，供咱们在项目中使用。实际上，咱们在实际项目中通常从艳遇4、5、六中，根据实际状况三选一便可。最后，但愿你们有所收获。

原文地址：https://mp.weixin.qq.com/s/VZsgoCS90deYHKeSMhVlOg