- 单例模式:是一种设计模式
- 设计模式,类似于“棋谱”,就是固定套路,针对一些特定的场景,给出一些比较好的解决方法
- 只要按照设计模式来写代码,就可以保证代码不会太差,保证代码的下限
设计模式
设计模式
- 设计模式并非只有 23 种
- 23 这个数字是有三个大佬(GOF),写了一本设计模式的书,这本书中谈到了 23 种设计模式
- 设计模式也适合变成语言相关的,有些设计模式,是在给语法填坑
- 有的语言本身语法设计的更好,不太依赖设计模式
- 这 23 种设计模式是针对 C# 这个语言来谈的,比较适用于 C++,Java、C#
- 校招中,掌握 4~5 个就好了
- 设计模式适合具有一定的编程经验之后再学习,因为缺少经验,难以理解人家为什么这样写
- 编程这个圈子中,“灵活”是贬义词(易出 bug),“死板”才是褒义词(稳健)
- 设计模式就是针对编写代码过程中的“软性约束”(不是强制的,选择性遵守,但遵守当然有好处)
框架
- 针对一些特定的场景问题,大佬们把基本的代码已经写好了,大部分逻辑也都写好了,留出来一些空位,让你在空位上填充一些自定制的逻辑
- 框架就是针对编写代码过程中的“硬性约束”
- Java 圈子中,特别讲究框架
单例模式
- 开发者,希望有的类在一个进程中,不应该存在多个实例(对象)
- 此时,就可以使用单例模式(单个实例/单个对象),只有唯一实例
- 比如在
JDBC
中JDBC => DataSourse
数据源描述数据库在哪- 一般来说,一个程序中,只有一个数据库,对应的
mysql
服务器只有一份,此时DataSourse
这个类没有必要创建出多个类 - 此时就可以使用单例模式,描述
DataSourse
,避免不小心创建出了多个实例
- 比如广告系统
- 广告数据都是要加载在内存中的,这里的查询就是直接查内存 hash 表,避免直接插数据库(查数据库太慢)
- 所以就在代码中专门搞了个类,管理这些数据,此时这个类也就是案例模式
- 这个类,一个实例就是几百G 内存空间
- 比如在
前提是“一个进程中”,如果有多个进程,自然每个进程中都可以有一个实例
- Java 中,单例模式的实现有很多种写法,这里我们介绍两种最主流的写法:饿汉模式和懒汉模式
理解
在你们家,每次吃完饭后,如果是你的妈妈洗碗,那一般都是吃完后立即就把碗洗了
但如果是你洗碗,就会把碗先泡一会再洗,但这样容易忘记,一拖,就拖到了下顿使用碗的时候才会洗
你妈妈这种洗碗习惯就相当于是“饿汉模式”
你这种洗碗模式就相当于是“懒汉模式”
饿汉模式
“饿”的意思是“迫切”,在类被加载的时候,就会创建出这个单例的实例
- 在
Singleton
类中,成员变量instance
要用static
修饰,这样instance
就变成了“类成员”
类成员初始化,就是在Singleton
这个类被加载的时候(近似于程序启动的时候)
class Singleton { //static修饰,instance 成员变量就是“类成员” private static Singleton instance = new Singleton();
}
- 程序启动,类就加载了,这个类一加载,这里的初始化就进行了,于是这里的实例就创建了
- 这就叫实例创建的非常迫切,就叫“饿汉模式”
- 不过有了实例还不够,还需要外面能对实例进行使用,我们再创建一个方法
class Singleton { //static修饰,instance 成员变量就是“类成员” private static Singleton instance = new Singleton(); //获取实例对象public static Singleton getInstance() { return instance; }
}
- 之后我们需要使用实例的时候,只需要调用这个
getInstance
方法就好了 - 现在只要我们不在其他代码中,
new
这个类,每次需要使用都通过getInstance
方法来调用到这个实例,此时这个类就是单例的了
- 但这个设定其实不科学,凭什么你说别人都不去 new 这个类,这就相当于是一个君子协议,口头约定一下。但万一不遵守呢?
- 所以“ 只要我们不在其他代码中,
new
这个类 ”这个才是单例模式中主要需要解决的问题,防止别人不小心 new 了对象
类的使用者的想法都很简单,“用就对了”,但类的设计者需要考虑的事就多了
- 如何避免这个的实例不小心被
new
了一下
- 单例模式最关键一步:将类的构造方法设为私有
class Singleton { //static修饰,instance 成员变量就是“类成员” private static Singleton instance = new Singleton(); //获取实例对象public static Singleton getInstance() { return instance; } //最关键的一步private Singleton() {}
}
- 这就意味着在类的外面,就无法调用构造方法,也就无法创建实例了
单例模式只能避免别人的“失误
”,但无法应对别人的“故意攻击
”:
- 你不是 private 吗,我通过反射拿到构造方法,通过反射 API 来调用,不就能 new 出实例了吗
- 除了反射,还可以通过“序列化反序列化”打破上述单例模式
懒汉模式
计算机中,“懒”是褒义词。谈到“懒”,效率会更高,是高效的代名词
在这里,推迟了创建实例的时机,实例会在第一次使用的时候才会创建
经常有这种情况:
中午的时候,需要使用 4 个碗
晚上的时候,只需要使用 2 个碗,此时只需要洗两个碗就可以了
- 洗两个碗,比洗四个碗更高效
- 能不搞就不搞,很多时候就可以把这部分开销就省下了
“这里的优劣只是在计算机中,不是在生活中!!!”
比如,有一个编辑器,打开一个非常大的文本文档,有两种方式:
- 一启动,就把所有的文本内容都读取到内存中,然后再显示到界面上[饿汉]
- 启动之后,只加载一小部分数据(一个屏幕能显示的最大数据),随着用户进行翻页操作,再按需地加载剩下的内容[懒汉]
毋庸置疑,我们更青睐于“懒汉模式”
class SingletonLazy { //先把实例的引用设为 null,不着急创建实例private static SingletonLazy instance = null; public static SingletonLazy getInstance() { if(instance == null) { instance = new SingletonLazy(); } return instance; }private SingletonLazy() {}
}
- 先把实例的引用设为
null
,不着急创建实例 - 当首次调用
getInstance
,由于此时引用为null
,就会进入if
分支,从而创建实例 - 后续再重复调用
getInstance
,结果都不会创建实例,直接返回 - 还是要将构造函数设为
private
,避免被不小心new
是否线程安全
上述写的“饿汉“和“懒汉“单例模式代码,是否是线程安全的?(如果是多线程环境下,调用 getInstance,是否会有问题呢?)
- 饿汉模式
public static Singleton getInstance() { return instance; }
无线程安全问题
- 这里的
return instance
只是一个“读操作”,没有涉及到“多个线程对变量进行修改”
- 懒汉模式
public static SingletonLazy getInstance() { if(instance == null) { instance = new SingletonLazy(); } return instance; }
有线程安全问题
- 这里的赋值操作就涉及到“修改”了,还有一个“判定”操作结合在一起,这样就非常容易产生“线程安全”问题了
对于 判定+赋值
操作,产生的线程安全问题:
if(instance == null) { instance = new SingletonLazy();
}
调度顺序 | 线程 | t1 | t2 |
---|---|---|---|
if (istance == null) | |||
if (instance == null) 由于 instance 仍然为 null ,所以 t2 会认为这个条件也是满足的 | |||
instance = new SingletonLazy(); 创建实例 | |||
instance = new SingletonLazy(); 由于 t2 刚刚完成了条件判断,所以 t2 也会执行创建实例的逻辑 |
- 上述逻辑中,就创建了两个实例
- 第二次创建,覆盖了
instance
的值,使得第一次创建的实例没有引用指向,很快就会被垃圾回收机制给消除掉 - 但即使如此,仍然认为上述代码是存在
bug
的- 因为实际上,构造方法内部可能会执行很多的逻辑
“先判定,再修改”,这种代码模式,是属于典型的线程不安全代码,因为判定和修改之间可能涉及到线程的切换
如何解决线程安全问题
1. 线程切换导致的线程安全
通过加锁,来解决问题
- 出现线程安全问题,是因为
if
判定和new
操作之间出现了线程切换,出现了逻辑上的穿插 - 所以需要锁,把
if
和new
打包成一个整体就可以了
public static SingletonLazy getInstance() { synchronized (locker) { if (instance == null) { instance = new SingletonLazy(); } } return instance;
}
- 这样,
if
判定和new
操作就是一个“原子”了 return
加不加到锁里面无所谓- 此处的矛盾是
if
和new
中间出现线程切换,引起逻辑错误,而后面的return
不会受到影响 - 无论
return
是在本线程还是其他线程,此处的return
的值都是instance
内存中的最新值
- 此处的矛盾是
2. 加锁导致的性能下降
加锁之后,确实解决了线程安全问题,到那时加锁却可能会带来阻塞
如果上述代码,已经 new
完了对象,if
分支再也进不去了,后续的代码,都是单纯的“读操作”,此时 getInstance
不加锁也是线程安全的
这样就没有必要加锁了
而当前的代码写法,虽然没有线程安全问题了(instance
new
出来之后,就都是读操作了),但只要调用了 getInstance
,就都会触发加锁操作,此时就会因为加锁,而产生阻塞,啥时候能恢复执行,中间可能是“沧海桑田”,影响性能
因此,针对这个问题,还需要进行进一步改进
- 通过条件判断,在需要加锁的时候才加锁,不需要的时候就不加
public static SingletonLazy getInstance() { //在这个条件中判断当前是否应该加锁 if(instance == null) { synchronized (locker) { if (instance == null) { instance = new SingletonLazy(); } } } return instance;
}
- 首次调用,才会有线程安全问题(
instance == null
),一旦instance
已经创建好了,不为null
,意味着此时不需要加锁了,没有线程安全问题了 - 如果不在锁前面加上
if
,性能会下降很多
3. 指令重排序导致的线程安全
指令重排序,也是一种编译器的优化方式,在不改变原有代码逻辑的条件下,有的时候调整逻辑执行顺序也能提高性能
- 如果是单线程代码,编译器能准确地进行判断
- 如果是多线程代码,编译器可能会出现误判
instance = new SingletonLazy();
这个语句,可以理解是分成了三个步骤:(粗略)
- 给
SingletonLazy
对象分配内存空间(买房) - 在内存空间中,针对这个对象进行初始化(执行构造方法)(装修)
- 将内存空间的地址,赋值给引用变量(收房拿到钥匙)
编译器可能按照 1、2、3 的顺序执行,也可能按照 1、3、2 的顺序来执行,分配内存的 1 肯定是在最前面,其他的步骤交换
对于单线程来说,先执行 2 还是 3 本质上是一样的
在多线程环境下,按照 132 的顺序来执行,是可能出现问题的
调度顺序 | 线程 | t1 | t2 |
---|---|---|---|
if(instance == null) { synchronized (locker) { if (instance == null) { | |||
1. 分配内存 | |||
3. 把地址赋值给引用 (这个赋值使 instance 不再为 null ) | |||
return instance; 因为在 t1 线程中,引用已经被赋值了,不再为空,所以直接返回。instance 指向了一个没有被初始化,上面的值全为 0 的内存 | |||
2. 执行构造方法,初始化内存 |
- 在
t2
中,由于instance
对象内存未初始化,一旦调用的方法里使用了任何instance
的成员,都可能是错误的值,可能会引起一系列不可预期的情况
要解决因为指令重排序导致的线程安全,只需要请出 volatile
关键字就可以了
private static volatile SingletonLazy instance = null;
- 编译器就发现了,
instance
是易失的(易改变的),之后围绕这个变量的优化,就会非常的克制 - 不仅仅会在读取变量的优化上克制,也会在修改变量的优化上克制
- 加上
volatile
之后,也能禁止对instance
赋值的操作插入到其他操作之间,上述 123 的操作不会再变成 132
volatile
有两个功能:
- 保证内存的可见性
- 禁止指令重排序(针对赋值)