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

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

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

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

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

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

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

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

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

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

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

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

1.特点

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

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

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

2.案例

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

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

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

3.注意事项

第一种艳遇:

分析：

<col>

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

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

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

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

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

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

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

假设new LazyLoadBalancer()加载内容过多

因重排而导致loadBalancer提前不为空

正好被其它线程观察到对象非空直接返回使用  一种罕见的单例空指针突然来袭

存在问题： 首先我们一定要清楚，DCL是不能保证线程安全的，稍微了解过JVM的就清楚，对比C/C++它始终缺少一个正式的内存模型，所以为了提升性能，它还会做一次指令重排操作，这个时候就会导致loadBalancer提前不为空，正好被其它线程观察到对象非空直接返回使用（但实际还有部分内容没加载完成）

解决方案： 用volatile修饰loadBalancer，因为volatile修饰的成员变量可以确保多个线程都能够顺序处理，它会屏蔽JVM指令重排带来的性能优化。

第四种艳遇：Demand Holder，静态内部类 （懒汉）线程安全，推荐使用

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

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

输出如下:

因此，我们有如下结论:

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

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

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

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

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

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

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

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

第八种艳遇:登记式单例

来一把测试:

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

来来 领略一下 Spring的源码:

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

使用map实现注册表；

使用protect修饰构造方法；

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

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

这就用到了登记式单例

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

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

第九种艳遇: ThreadLocal 局部单例

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

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

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

第十种艳遇: 使用CAS锁实现（线程安全）

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

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