【极客思考】设计模式:你确定你真的理解了单例模式吗?

举报
技术火炬手 发表于 2020/05/21 17:12:50 2020/05/21
【摘要】 说到单例模式,其实大家应该都不陌生,因为真的太常用了,应该所有开发者接触设计模式的第一个模式。那我这里一句话简单说下为何使用单例:如果你希望你的某个类只需要有一个实例对象,并且全局共享,那么你就使用单例。

什么是单例模式?

说到单例模式,其实大家应该都不陌生,因为真的太常用了,应该所有开发者接触设计模式的第一个模式。那我这里一句话简单说下为何使用单例:如果你希望你的某个类只需要有一个实例对象,并且全局共享,那么你就使用单例。

我喜欢的单例模式实现

单例模式常见的实现有懒汉式、饿汉式这两种方式,但是在这里,我不想讨论这两种方式,因为常见所以没有讨论和需要思考的价值。

让我们来看看以下的几种方式的一些实现机制:

一、双重校验锁(DCL)

上代码:

DCL双重加锁的方式保证每次调用getSingleton方法的时候都是同步的。其实加锁大家都能理解,就是解决多线程同步的问题。但其实这里有个重点,就是这行代码:

private volatile static Singleton singleton

 为什么要用volatile去修饰呢,这边从两个方面去说明:

1.如果不用volatile修饰会怎么样?

这看起来似乎也是行的通的,但是了解过编译器和程序指令的话就会知道那是不可靠的,具体原因如下:

 1)编译器优化了程序指令,以加快cpu处理速度。

 2)多核cpu会动态调整表指令顺序,以加快并行运算能力。

简单理解,那就是现在都0202年了,一台计算机cpu和内核都是好几个出现的,不在是那个单核的老时代了,所以java文件编译成字节码指令之后,你的编码逻辑确实是串行的,计算机也会根据范式把你编程的逻辑结果给你执行返回,但是具体到cpu去执行指令的时候,为了体现多核的优势,会对一些指令做并行处理,以加快程序运行速度。

 我想好奇的你,还是想知道,如果不加volatile的话,会在什么时候出现问题,那我给你说说问题出现的顺序:

 1)线程A,调用方法获取实例,发现对象未实例化,准备开始实例化。

 2)由于编译器优化了程序的指令,允许对象在构造函数未调用完成前,将共享变量的引用指向部分构造的对象,虽然对象未完全实例化,但是已经不为null了。

 3)线程B进入也要调用方法获取实例,发现部分构造的对象已经不为null,则直接返回了该对象。

至于线程B返回之后会发生什么,可想而知,没实例化完,那么就会导致调用部分的方法的时候,就会有空指针的异常,所以就是我上面说的,不可靠。 

2.volatile作用是啥?

为了解决这个问题,JDK1.6之后的版本提供了该关键字, 其实就是为了让其修饰的变量你能够在线程间可见,而所谓的可见,那就是大家都从主存中获取,至于主存等概念在这里就不展开说明了。

可以这么理解:在线程B读取volatile变量后,线程A在写这个volatile之前,所有可见的共享变量的值都将立即变得对线程B可见。

对应上面的问题解决也就是:线程A在未初始化完,singleton变量那就是null,线程B读到的也就是null,那么当线程B再进去想要加锁实例化的时候,发现线程A获取了锁正在实例化,那就阻塞了起来,直到A实例化完释放锁,但是因为实例化完之后B立马又知道该变量不为null了所以在第二个判断的时候,就不用进去new了,返回了。

二、静态内部类

       上代码:

 静态内部类是一个我比较喜欢的实现方式,当然很明显代码少,逻辑较为简单。这种方式主要是利用了classloader机制来保证初始化singleton的时候只有一个线程,避免了需要再去保证线程同步的问题。同时我们把这种方式实例化有lazy loading的效果,其实主要是因为静态内部类Holder类并不会在Singleton类被装载的时候就被初始化了,只有当Holder类被主动使用,也就是调用了getSingleton方法之后,才会显示的装载Holder类,从而实例化singleton对象。如果singleton对象是一个消耗资源占用比较大的内存的对象的时候,如果你希望延迟加载的话,那么这种方式是个不错的选择。

但是其实静态内部类的方式实际上并没有想象中的那么完美,因为它无法阻挡反射和反序列攻击,你可以利用前面两种方式再去构造新的Singleton的实例,所以不是严格意义上的单例。

 三、枚举

      上代码:

这种方式是Josh Bloch提倡的,利用枚举的特性,让JVM来保证线程安全和单例的问题,还能防止反序列化和反射,除了大家不怎么常用外,其实这种简单的方式是个很好的方式。

     反编译看一下,其实枚举是在static块中进行的对象的创建:

单例模式真的有那么好吗?

优点:

      1.提供了唯一实例的受控访问。

      2.因为只有一个实例,节约了系统资源,提高系统性能。

缺点:

      1.单例模式没有抽象层,扩展比较困难。

      2.单例类的职责过重,违背了“单一职责原则”。

我的推荐:

我们去使用单例基本目标就是为了节省内存资源,而且一般的web项目都会引入Spring框架,通过Spring实现的单例和上面设计模式说的单例有所不同。设计模式的单例是在整个Java应用中只有一个实例,而Spring中的单例是在一个IOC容器中就只有一个单例。但对于web应用来说,web容器(Jetty或tomcat)对用户的每个请求都会创建一个单独的servlet线程去处理请求,Spring框架下的接口每个action也都是单例的,那么其实就保证了我们使用的是一个实例。

同时Spring也支持我们通过注解或者xml进行lazy-init,也可以指定scope确定其是否为全局单例,又或者是多个实例,对于程序来说有了更多的选择。

当然上面提到的线程安全的问题,其实大多数情况下Spring是没有去保证所有bean的线程安全,所以主动权交给了开发者,我们自己编写程序要保证线程安全的。不过在我们经常使用的数据库dao层的那些dao 的bean对象,Spring通过ThreadLocal对象,区别与我们常用的加锁的方式而是用空间换时间,给每个线程分配了独自的变量副本,从而隔离了多线程访问对数据访问的冲突,保证了线程安全性。至于这个类和这个机制,这里就不展开谈了,谈多了这篇文章就装不下了。

本文经作者授权转载,如需转载请联系作者授权

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。