摘要:考上大家一考单例模式的单例,怎样写的不就是构造方法私有化么对呀对呀单例模式有七种写法,你知道么言归正传单例模式可以说是最简单的设计模式了。单例模式静态内部类静态内部类是更进一步的写法,不仅能实现懒加载线程安全,而且还保持了指令优化的能力。
大家好,我是三乙己。考上大家一考:“单例模式的单例,怎样写的?”
“不就是构造方法私有化么?”
”对呀对呀!……单例模式有七种写法,你知道么?“
言归正传……
单例模式(Singleton Pattern)可以说是最简单的设计模式了。
用一个成语来形容单例模式——“天无二日,国无二主”。
什么意思呢?就是当前进程确保一个类全局只有一个实例。
那单例模式有什么好处呢?[1]
那单例模式是银弹吗?它有没有什么缺点?
那什么情况下要用单例模式呢?
接下来,进入今天的主题,我们来看看单例模式的七种写法!
public class Singleton_1 { private static Singleton_1 instance=new Singleton_1(); private Singleton_1() { } public static Singleton_1 getInstance() { return instance; }}
饿汉式
,就像它的名字,饥不择食,定义的时候直接初始化。
因为instance
是个静态变量,所以它会在类加载的时候完成实例化,不存在线程安全的问题。
这种方式不是懒加载,不管我们的程序会不会用到,它都会在程序启动之初进行初始化。
所以我们就有了下一种方式?
public class Singleton_2 { private static Singleton_2 instance; private Singleton_2() { } public static Singleton_2 getInstance() { if (instance == null) { instance = new Singleton_2(); } return instance; }}
懒汉式
是什么呢?只有用到的时候才会加载,这就实现了我们心心念的懒加载。
但是!
它又引入了新的问题?什么问题呢?线程安全问题。
图片也很清楚,多线程的情况下,可能存在这样的问题:
一个线程判断instance==null
,开始初始化对象;
还没来得及初始化对象时候,另一个线程访问,判断instance==null
,也创建对象。
最后的结果,就是实例化了两个Singleton对象。
这不符合我们单例的要求啊?怎么办呢?
public class Singleton_3 { private static Singleton_3 instance; private Singleton_3() { } public synchronized static Singleton_3 getInstance() { if (instance == null) { instance = new Singleton_3(); } return instance; }}
最直接的办法,直接上锁呗!
但是这种把锁直接方法上的办法,所有的访问都需要获取锁,导致了资源的浪费。
那怎么办呢?
public class Singleton_4 { //volatile修饰,防止指令重排 private static volatile Singleton_4 instance; private Singleton_4() { } public static Singleton_4 getInstance() { //第一重校验,检查实例是否存在 if (instance == null) { //同步块 synchronized (Singleton_4.class) { //第二重校验,检查实例是否存在,如果不存在才真正创建实例 if (instance == null) { instance = new Singleton_4(); } } } return instance; }}
这是比较推荐的一种,双重校验锁。
它的进步在哪里呢?
我们把synchronized
加在了方法的内部,一般的访问是不加锁的,只有在instance==null
的时候才加锁。
同时我们来看一下一些关键问题。
大家想一下,如果不双重校验。
如果两个线程一起调用getInstance方法,并且都通过了第一次的判断instance==null,那么第一个线程获取了锁,然后实例化了instance,然后释放了锁,然后第二个线程得到了线程,然后马上也实例化了instance。这就不符合我们的单例要求了。
接着我们来看第二个问题,为什么要用volatile 修饰 instance?
我们可能知道答案是防止指令重排。
那这个重排指的是哪?指的是instance = new Singleton()
,我们感觉是一步操作的实例化对象,实际上对于JVM指令,是分为三步的:
有些编译器为为了性能优化,可能会把第二步和第三步进行重排序
,顺序就成了:
所以呢,如果不使用volatile防止指令重排可能会发生什么情况呢?
在这种情况下,T7时刻线程B对instance
的访问,访问的是一个初始化未完成的对象。
所以需要在instance
前加入关键字volatile
。
有序性
,指令重排序被禁止;可见性
,Java内存模型会确保所有线程看到的变量值是一致的。public class Singleton_5 { private Singleton_5() { } private static class InnerSingleton { private static final Singleton_5 instance = new Singleton_5(); } public static Singleton_5 getInstance() { return InnerSingleton.instance; }}
静态内部类是更进一步的写法,不仅能实现懒加载、线程安全,而且JVM还保持了指令优化的能力。
Singleton类被装载时并不会立即实例化,而是在需要实例化时,调用getInstance方法,才会加载静态内部类InnerSingleton类,从而完成Singleton的实例化。
类的静态属性只会在第一次加载类的时候初始化,同时类加载的过程又是线程互斥的,JVM帮助我们保证了线程安全。
public class Singleton_6 { private static final AtomicReference<Singleton_6> INSTANCE = new AtomicReference<Singleton_6>(); private Singleton_6() { } public static final Singleton_6 getInstance() { //等待 while (true) { Singleton_6 instance = INSTANCE.get(); if (null == instance) { INSTANCE.compareAndSet(null, new Singleton_6()); } return INSTANCE.get(); } }}
这种CAS式的单例模式算是懒汉式直接加锁的一个变种,sychronized
是一种悲观锁,而CAS
是乐观锁,相比较,更轻量级。
当然,这种写法也比较罕见,CAS存在忙等的问题,可能会造成CPU资源的浪费。
public enum Singleton_7 { //定义一个枚举,代表了Singleton的一个实例 INSTANCE; public void anyMethod(){ System.out.println("do any thing"); }}
调用方式:
@Test void anyMethod() { Singleton_7.INSTANCE.anyMethod(); }
《Effective Java》作者推荐的一种方式,非常简练。
但是这种写法解决了最主要的问题:线程安全、⾃由串⾏化、单⼀实例。
从使用的角度来讲,如果不需要懒加载的话,直接饿汉式就行了;如果需要懒加载,可以考虑静态内部类,或者尝试一下枚举的方式。
从面试的角度,懒汉式、饿汉式、双重校验锁饿汉式,这三种是重点。双重校验锁方式一定要知道指令重排是在哪,会导致什么问题。
简单的事情重复做,重复的事情认真做,认真的事情有创造性地做。
我是三分恶,一个努力学习中的程序员。
点赞
、关注
不迷路,咱们下期见!
参考:
[1]. 《设计模式之禅》
[2]. 《重学设计模式》
[3]. 设计模式系列 - 单例模式
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/119936.html
摘要:单例是应用开发中一种设计模式,主要应用场景为当且仅当系统中只能保留一个对象时使用。本文提出中可以在生产环境中使用的单例设计模式。在的一书中给出了三种单例设计模式采用静态变量这种写法使用了私有的构造方法。 单例是应用开发中一种设计模式,主要应用场景为:当且仅当系统中只能保留一个对象时使用。本文提出4中可以在生产环境中使用的单例设计模式。推荐使用enum的方式。 应用场景 例如一下应用场景...
摘要:大潮来袭前端开发能做些什么去年谷歌和火狐针对提出了的标准,顾名思义,即的体验方式,我们可以戴着头显享受沉浸式的网页,新的标准让我们可以使用语言来开发。 VR 大潮来袭 --- 前端开发能做些什么 去年谷歌和火狐针对 WebVR 提出了 WebVR API 的标准,顾名思义,WebVR 即 web + VR 的体验方式,我们可以戴着头显享受沉浸式的网页,新的 API 标准让我们可以使用 ...
摘要:简单工厂模式的实质是由一个工厂类根据传入的参数,动态决定应该创建哪一个产品类。中的就是简单工厂模式的体现,根据传入一个唯一的标识来获得对象,但是否是在传入参数后创建还是传入参数前创建这个要根据具体情况来定。 设计模式作为工作学习中的枕边书,却时常处于勤说不用的尴尬境地,也不是我们时常忘记,只是一直没有记忆。 Spring作为业界的经典框架,无论是在架构设计方面,还是在代码编写方面,都堪...
摘要:简单工厂模式的实质是由一个工厂类根据传入的参数,动态决定应该创建哪一个产品类。中的就是简单工厂模式的体现,根据传入一个唯一的标识来获得对象,但是否是在传入参数后创建还是传入参数前创建这个要根据具体情况来定。 设计模式作为工作学习中的枕边书,却时常处于勤说不用的尴尬境地,也不是我们时常忘记,只是一直没有记忆。 Spring作为业界的经典框架,无论是在架构设计方面,还是在代码编写方面,都堪...
摘要:简单工厂模式的实质是由一个工厂类根据传入的参数,动态决定应该创建哪一个产品类。中的就是简单工厂模式的体现,根据传入一个唯一的标识来获得对象,但是否是在传入参数后创建还是传入参数前创建这个要根据具体情况来定。 设计模式作为工作学习中的枕边书,却时常处于勤说不用的尴尬境地,也不是我们时常忘记,只是一直没有记忆。 Spring作为业界的经典框架,无论是在架构设计方面,还是在代码编写方面,都堪...
阅读 1564·2021-11-12 10:36
阅读 2581·2021-10-14 09:43
阅读 1548·2021-09-23 11:34
阅读 2236·2021-09-22 15:45
阅读 11565·2021-09-22 15:07
阅读 1707·2021-09-14 17:57
阅读 1948·2021-09-02 15:40
阅读 3884·2021-07-29 14:48