目录
- 前言
- WHAT
- WHY
-
饿汉式
- 实现一:静态实例参数与静态代码块
- 实现二:静态内部类
-
懒汉式
- 错误一:单线程实现
- 错误二:同步方法
- 错误三:同步代码块之单次检查
- 错误四:同步代码块之双重检查
- 正确:双重检查+阻止重排序
-
枚举
-
场景
-
总结
前言
个人认为单例模式是设计模式中最简单也是最常用的一种,是对有限资源合理利用的一种方式。这个模式看似简单,但是其中蕴含了关于并发、类加载、序列化等一系列深层次的知识,如果理解不够深,就有可能在高并发时遇到难以预期的异常,或者会造成资源浪费。
所以本文会从将目前Java领域最常用的几种单例模式列出来,供大家参考。
WHAT
维基百科给出了解释、实现的思路以及应该注意的地方:
类图是:
WHY
正如定义所说,单例模式就是整个内存模型中,只有一个实例。实例少了,内存占用就少。同时,只有一个实例,也就只需要构建一个对象,计算就少。对于构造过程中需要大量计算或者占用大量资源的对象,只创建一次,就减少了资源占用和内存占用。
饿汉式
饿汉式是最简单的一种实现,在类装载过程中,完成实例化,避免多线程问题。
实现一:静态实例参数与静态代码块
?
1 2 3 4 5 6 7 8 9 10 |
|
根据java的特性,饿汉式还可以变种写法,有的地方称为静态代码块方式:
?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
这两种方式只是在写法上的区别,优缺点没有区别,只是借助Java语言特性的不同写法,所以归为一类。
饿汉式有两个明显的缺点:
- 类装载过程即完成实例化,如果整个应用生命周期内,实例没有使用,也就是浪费资源了。
- 因为没有办法向构造函数传递不同的参数,如果需要通过个性化参数定制实例时,这种方式就不支持了。
实现二:静态内部类
针对饿汉式第一个缺点,我们可以借助静态内部类的方式,将对象实例化的时间延后。
?
1 2 3 4 5 6 7 8 9 10 11 12 |
|
但是,依然不能很好的解决第二个缺点,如果需要根据不同的参数实现不同的实例,可以采用下面说的懒汉式实现。
懒汉式
懒汉式比饿汉式的一个优点,就是能够在使用的时候再进行实例化。但是,馅饼总是要伴随着陷阱,懒汉式写法有更多的坑,一不小心就摔着了。
错误一:单线程实现
?
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
之所以定义为单线程实现,是因为 INSTANCE==null这个判断,一个线程通过这个判断,开始进行对象实例化,但是还没有实例化完成,另一个线程又来了,这个时候,对象还没有实例化,就也会开始进行实例化,造成不必要的浪费。
错误二:同步方法
?
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
这种方式解决了多线程的问题,但是也引入了新的性能问题:太慢。synchronized把整个方法包起来,也就是每个线程进入的时候,都需要等待其他线程结束调用,才能拿到实例,在性能敏感的场景,是比较致命的。
错误三:同步代码块之单次检查
?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
这种写法看似将同步代码缩小,但也缩小了多线程保障,也犯了第一种写法的错误,属于没有对多线程有基本了解写出的低级错误代码。
错误四:同步代码块之双重检查
?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
这种写法在一定程度上属于正确的写法,双重判断可以很好的实现线程安全和延迟加载。如果到这里就结束,那就是谬以千里的毫厘之差。
双重检查和同步代码块都没有问题,问题出在 INSTANCE=newLazySingleton()这句话。在JVM中,为了充分利用CPU计算能力,会进行重排序优化, INSTANCE=newLazySingleton()做了三件事:
- 为 INSTANCE 初始化栈空间
- 为 LazySingleton 分配内存空间,实例化对象
- INSTANCE 指向 LazySingleton 实例分配的内存空间
因为重排序优化的存在,真正执行的过程中,可能会出现1-2-3的顺序,也可能出现1-3-2的顺序。如果是1-3-2,INSTANCE 指向了 LazySingleton 实例分配的内存空间后,就不是null,另外一个线程进入判断null时,就会直接返回 INSTANCE,但是这个时候 LazySingleton 实例化还没有完成,就可能出现意想不到的异常。
正确:双重检查+阻止重排序
?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
这种写法比上面那种,就差在 volatile这个关键字。
枚举
懒汉式和饿汉式都能够适用于多线程并发场景,但是通过反序列化或反射可以实例化对象,这样依然不能满足单例模式的要求,所以可以借助枚举实现,枚举可以完美避免多线程并发问题,而且可以防止反序列化和反射创建新对象。第一次看到这样定义单例模式,是在《Effective Java》中,多读经典书还是挺好的。
?
1 2 3 4 5 6 7 8 9 10 11 12 |
|
在开发实践中,枚举可以满足绝大部分场景,而且写法简单,定义单例的逻辑只需要三行代码,简洁而不简单,三行代码可以保证线程安全。同时枚举的反序列化只是通过name查找对象,不会产生新的对象;根据JVM规范,通过反射创建枚举对象时,会抛出 IllegalArgumentException异常。这样,相当于通过语法糖防止反序列化和反射破坏单例。
场景
- 无状态工具类:这种工具类不需要记录状态,只保证正确的应用就行,可以通过单例模式来定义。
- 数据共享:即多个不相关的两个线程或者进程之间实现通信。因为是一个实例,如果它的属性或者变量值被修改,所有引用都是同时修改的,当然需要 volatile 来定义变量。比如网站的计数器。
- 日志应用:通常应用会向日志文件写日志信息,为了实时向文件写,通常会使用单例模式,保证有一个实例持有文件,然后进行操作。
- 数据库连接池:数据库连接是一种数据库资源,使用数据库连接池,主要是节省打开或者关闭数据库连接所引起的效率损耗,这种效率上的损耗还是非常昂贵的,通过单例模式来维护,就可以大大降低这种损耗。
- Web应用的配置对象:读取文件需要消耗时间,如果读取大文件,消耗的时间和资源更久,所以通过单例模式可以大大降低消耗。
- 。。。
单例模式的场景还是比较多的,这里只是列出里几个简单的应用场景,算是抛砖引玉,如果看官们有什么其他应用场景,可以在说一说
总结
到此这篇关于Java中单例模式的文章就介绍到这了,更多相关Java单例模式内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家!
原文链接:https://juejin.cn/post/7025759553388019719
本文链接:https://my.lmcjl.com/post/7683.html
4 评论