您的位置:首页 > 其它

单例模式的七种写法,你都知道吗?

2021-09-13 11:05 183 查看

大家好,我是三乙己。考上大家一考:"单例模式的单例,怎样写的?"

"不就是构造方法私有化么?"

”对呀对呀!……单例模式有七种写法,你知道么?“

言归正传……

单例模式(Singleton Pattern)可以说是最简单的设计模式了。

用一个成语来形容单例模式——“天无二日,国无二主”。

什么意思呢?就是当前进程确保一个类全局只有一个实例。

那单例模式有什么好处呢?[1]

  • 单例模式在内存中只有一个实例,减少了内存开支
  • 单例模式只生成一个实例,所以减少了系统的性能开销
  • 单例模式可以避免对资源的多重占用
  • 单例模式可以在系统设置全局的访问点

那单例模式是银弹吗?它有没有什么缺点?

  • 单例模式一般没有接口,扩展很困难
  • 单例模式不利于测试
  • 单例模式与单一职责原则有冲突

那什么情况下要用单例模式呢?

  • 要求生成唯一序列号的环境
  • 在整个项目中需要一个共享访问点或共享数据
  • 创建一个对象需要消耗的资源过多
  • 需要定义大量的静态常量和静态方法(如工具类)的环境

接下来,进入今天的主题,我们来看看单例模式的七种写法!

1、饿汉式(线程安全)⭐

public class Singleton_1 {

private static Singleton_1 instance=new Singleton_1();

private Singleton_1() {
}

public static Singleton_1 getInstance() {
return instance;
}

}

饿汉式
,就像它的名字,饥不择食,定义的时候直接初始化。

因为

instance
是个静态变量,所以它会在类加载的时候完成实例化,不存在线程安全的问题。

这种方式不是懒加载,不管我们的程序会不会用到,它都会在程序启动之初进行初始化。

所以我们就有了下一种方式👇

2、懒汉式(线程不安全)⭐

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对象。

这不符合我们单例的要求啊?怎么办呢?

3、懒汉式(加锁)

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;
}
}

最直接的办法,直接上锁呗!

但是这种把锁直接方法上的办法,所有的访问都需要获取锁,导致了资源的浪费。

那怎么办呢?

4、懒汉式(双重校验锁)⭐

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指令,是分为三步的:

  1. 分配内存空间
  2. 初始化对象
  3. 将对象指向刚分配的内存空间

有些编译器为为了性能优化,可能会把第二步和第三步进行

重排序
,顺序就成了:

  1. 分配内存空间
  2. 将对象指向刚分配的内存空间
  3. 初始化对象

所以呢,如果不使用volatile防止指令重排可能会发生什么情况呢?

在这种情况下,T7时刻线程B对

instance
的访问,访问的是一个初始化未完成的对象。

所以需要在

instance
前加入关键字
volatile

  • 使用了volatile关键字后,可以保证
    有序性
    ,指令重排序被禁止;
  • volatile还可以保证
    可见性
    ,Java内存模型会确保所有线程看到的变量值是一致的。

5、单例模式(静态内部类)

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帮助我们保证了线程安全。

6、单例模式(CAS)

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资源的浪费。

7、单例模式(枚举)

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]. 设计模式系列 - 单例模式

[4]. Java中的双重检查锁(double checked locking)

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: