【Java设计模式实战系列】好的单例模式是怎样的，2021吊打面试官系列

• 由于在系统内存中只存在一个对象，因此可以节约系统资源，对于一些需要频繁创建和销毁的对象，单例模式无疑可以提高系统的性能。

• 允许可变数目的实例。我们可以基于单例模式进行扩展，使用与单例控制相似的方法来获得指定个数的对象实例。

缺点

=================================================================

• 由于单例模式中没有抽象层，因此单例类的扩展困难

• 单例类的职责过重，在一定程度上违背了“单一职责原则”。

因为单例类既充当了工厂角色，提供了工厂方法，同时又充当了产品角色，包含一些业务方法，将产品的创建和产品的本身的功能融合到一起。

• 滥用单例将带来一些负面问题，如

• 为了节省资源将数据库连接池对象设计为单例类，可能会导致共享连接池对象的程序过多而出现连接池溢出

• 现在很多面向对象语言的运行环境都提供了自动垃圾回收的技术，因此，如果实例化的对象长时间不被利用，系统会认为它是垃圾，会自动销毁并回收资源，下次利用时又将重新实例化，这将导致对象状态的丢失。

#适用场景

• 系统只需要一个实例对象，如

• 系统要求提供一个唯一的序列号生成器

• 需要考虑资源消耗太大而只允许创建一个对象

• 客户调用类的单个实例只允许使用一个公共访问点，除了该公共访问点，不能通过其他途径访问该实例。

• 在一个系统中要求一个类只有一个实例时才应当使用单例模式。反过来，如果一个类可以有几个实例共存，就需要对单例模式进行改进，使之成为多例模式

应用

=================================================================

一个具有自动编号主键的表可以有多个用户同时使用，但数据库中只能有一个地方分配下一个主键编号，否则会出现主键重复，因此该主键编号生成器必须具备唯一性，可以通过单例模式来实现。

#总结

• 单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方法。单例模式的要点有三个：一是某个类只能有一个实例；二是它必须自行创建这个实例；三是它必须自行向整个系统提供这个实例。单例模式是一种对象创建型模式。

• 单例模式只包含一个单例角色：在单例类的内部实现只生成一个实例，同时它提供一个静态的工厂方法，让客户可以使用它的唯一实例；为了防止在外部对其实例化，将其构造函数设计为私有。

• 单例模式的目的是保证一个类仅有一个实例，并提供一个访问它的全局访问点。单例类拥有一个私有构造函数，确保用户无法通过new关键字直接实例化它。除此之外，该模式中包含一个静态私有成员变量与静态公有的工厂方法。该工厂方法负责检验实例的存在性并实例化自己，然后存储在静态成员变量中，以确保只有一个实例被创建。

• 单例模式的主要优点在于提供了对唯一实例的受控访问并可以节约系统资源；其主要缺点在于因为缺少抽象层而难以扩展，且单例类职责过重。

• 单例模式适用情况包括：系统只需要一个实例对象；客户调用类的单个实例只允许使用一个公共访问点。

实现方式

===================================================================

1 懒汉式(非线程安全)

---

最基本的实现方式

不支持多线程。因为没有加锁 synchronized，所以严格意义上并不算单例模式

这种方式 lazy loading 很明显，不要求线程安全，当有多个线程并行调用 getInstance() 的时候，就会创建多个实例。也就是说在多线程下不能正常工作。

public class Singleton {

private static Singleton instance;

private Singleton (){}

public static Singleton getInstance() {

if (instance == null) {

instance = new Singleton();

}

return instance;

}

}

2 懒汉式(线程安全)

---

为了解决上面的问题，最简单的方法是将整个 getInstance() 方法设为同步（synchronized）

优点：第一次调用才初始化，避免内存浪费。

缺点：必须加锁 synchronized 才能保证单例，但加锁会影响效率。

虽然做到了线程安全，并解决了多实例的问题，但并不高效。

因为在任何时候只能有一个线程调用 getInstance()

但是同步操作只需要在第一次调用时才被需要，即第一次创建单例实例对象时。

这就引出了双重检验锁。

public class Singleton {

private static volatile Singleton INSTANCE = null;

// Private constructor suppresses

// default public constructor

private Singleton() {}

//thread safe and performance promote

public static Singleton getInstance() {

if(INSTANCE == null){

synchronized(Singleton.class){

//when more than two threads run into the first null check same time, to avoid instanced more than one time, it needs to be checked again.

if(INSTANCE == null){

INSTANCE = new Singleton();

}

}

}

return INSTANCE;

}

}

3 饿汉式

---

较常用，但易产生垃圾对象

• 优点：无锁，执行效率提高

• 缺点：类加载时就初始化，浪费内存

非常简单，实例被声明成 static 和 final变量了，在第一次加载类到内存中时就会初始化，所以创建实例本身是线程安全的。

它基于类加载机制避免了多线程的同步问题

不过，instance在类装载时就实例化，虽然导致类装载的原因有很多种，在单例模式中大多数都是调用 getInstance， 但也不能确定有其他的方式（或者其他的静态方法）导致类装载，这时候初始化instance 显然没有达到lazy loading

public class Singleton {

priv

《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享

ate final static Singleton INSTANCE = new Singleton();

// Private constructor suppresses

private Singleton() {}

// default public constructor

public static Singleton getInstance() {

return INSTANCE;

}

}

这种写法如果完美的话，就没必要在啰嗦那么多双检锁的问题了。

缺点是它不是一种懒加载模式（lazy initialization），单例会在加载类后一开始就被初始化，即使客户端没有调用 getInstance()方法。

饿汉式的创建方式在一些场景中将无法使用：譬如 Singleton 实例的创建是依赖参数或者配置文件的，在 getInstance() 之前必须调用某个方法设置参数给它，那样这种单例写法就无法使用了。

4 双重检验锁模式（double checked locking pattern）

---

一种使用同步块加锁的方法。程序员称其为双重检查锁，因为会有两次检查instance == null：

• 第一次在同步块外

• 第二次在同步块内

为什么在同步块内还要再检验一次？因为可能有多个线程一起进入同步块外的 if，若在同步块内不进行二次检验，就会生成多实例。

public class Singleton {

private volatile static Singleton singleton;

private Singleton (){}

public static Singleton getSingleton() {

if (singleton == null) { // Single Checked

synchronized (Singleton.class) {

if (singleton == null) { // Double Checked

singleton = new Singleton();

}

}

}

return singleton;

}

}

看起来很完美，很可惜哦，它还是有问题。

主要在于

instance = new Singleton()

并非一个原子操作，事实上在 JVM 中这句话大概做了下面 3 件事情

• 1、memory = allocate() 分配对象的内存空间

• 2、ctorInstance() 调用 Singleton 的构造函数来初始化成员变量

• 3、instance = memory 设置instance指向刚分配的内存执行完这步 instance 就为非 null 了）

JVM和CPU优化，发生了指令重排

但是在 JVM 的JIT 中存在指令重排序的优化。

也就是说上面的第2步和第3步的顺序是不能保证的，最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是后者

• 1、memory = allocate() 分配对象的内存空间

• 3、instance = memory 设置instance指向刚分配的内存

• 2、ctorInstance() 初始化对象

则在 3 执行完毕、2 未执行之前，被线程二抢占了，这时 instance 已经是非 null 了（但却没有初始化），所以线程二会直接返回 instance，然后使用，然后顺理成章地报错。

只需要将 instance 变量声明成volatile

public class Singleton {

private volatile static Singleton instance; //声明成 volatile

private Singleton (){}

public static Singleton getSingleton() {

if (instance == null) {

synchronized (Singleton.class) {

if (instance == null) {

instance = new Singleton();

}

}

}

return instance;

}

}

有些人认为使用 volatile 的原因是可见性，也就是可以保证线程在本地不会存有 instance 的副本，每次都是去主内存中读取。

但其实是不对的。使用 volatile 的主要原因是其另一个特性：禁止指令重排序优化。

在 volatile 变量的赋值操作后面会有一个内存屏障（生成的汇编代码上），读操作不会被重排序到内存屏障之前。

比如上面的例子，取操作必须在执行完 1-2-3 之后或者 1-3-2 之后，不存在执行到 1-3 然后取到值的情况。从「先行发生原则」的角度理解的话，就是对于一个 volatile 变量的写操作都先行发生于后面对这个变量的读操作（这里的“后面”是时间上的先后顺序）。

但是特别注意在 Java 5 以前的版本使用了 volatile 的双检锁还是有问题的。其原因是 Java 5 以前的 JMM （Java 内存模型）是存在缺陷的，即时将变量声明成 volatile 也不能完全避免重排序，主要是 volatile 变量前后的代码仍然存在重排序问题。这个 volatile 屏蔽重排序的问题在 Java 5 中才得以修复，所以在这之后才可以放心使用 volatile。

相信你不会喜欢这种复杂又隐含问题的方式，当然我们有更好的实现线程安全的单例模式的办法。

5 静态内部类

---

线程安全

实现难度： 一般

描述： 这种方式能达到双检锁方式一样的功效，但实现更简单

对静态域使用延迟初始化，应使用这种方式而不是双检锁方式

这种方式只适用于静态域的情况，双检锁方式可在实例域需要延迟初始化时使用。

这种方式同样利用了 classloder 机制来保证初始化 instance 时只有一个线程，它跟第 3 种方式不同的是：第 3 种方式只要 Singleton 类被装载了，那么 instance 就会被实例化（没有达到 lazy loading 效果），而这种方式是 Singleton 类被装载了，instance 不一定被初始化。因为 SingletonHolder 类没有被主动使用，只有通过显式调用 getInstance 方法时，才会显式装载 SingletonHolder 类，从而实例化 instance。想象一下，如果实例化 instance 很消耗资源，所以想让它延迟加载，另外一方面，又不希望在 Singleton 类加载时就实例化，因为不能确保 Singleton 类还可能在其他的地方被主动使用从而被加载，那么这个时候实例化 instance 显然是不合适的。这个时候，这种方式相比第 3 种方式就显得很合理

public class Singleton {

private static class SingletonHolder {

private static final Singleton INSTANCE = new Singleton();

}

private Singleton (){}

public static final Singleton getInstance() {

return SingletonHolder.INSTANCE;

}

}