目录
一、单例模式概述
二、“饿汉模式”实现单例模式
三、“懒汉模式”实现单例模式
3.1 单线程下的“懒汉模式”
3.2 多线程下的“懒汉模式”
一、单例模式概述
1）什么是单例模式？ 单例模式是一种设计模式。 单例模式可以保证某个类在程序中只存在唯一实例，即不允许创建多份实例。 使用单例模式，上述要求就得到了检查和校验。
2）单例模式的实现形式 单例模式可以通过很多种方法实现，“饿汉模式”和“懒汉模式”是其中最基础的两种，本文只介绍这两种实现。
二、“饿汉模式”实现单例模式
通过代码演示“饿汉模式”实现的单例模式：
class Singleton{
//新建一个唯一实例；
private static Singleton instance = new Singleton();
//方法返回唯一实例；
public static Singleton getInstance() {
return instance;
}
//将构造方法私有化；
private Singleton() { }
}
1）上述代码做了什么？ 创建了一个被 static 修饰的实例，这个实例成为了类属性。类对象只会有一个，这个类属性也只会有一个。 私有化构造方法，外部无法 new 新的实例，只能通过 get 方法获取唯一的那一个 instance。
2）为什么叫做“饿汉模式”？ 上述代码中，实例是类属性。类属性在类加载的时候就创建了，创建时机早，十分“迫切”，因此称为“饿汉模式”。
代码证明“饿汉模式”返回的实例是唯一的：
public class Singleton_Demo0 {
public static void main(String[] args) {
//想直接new对象，就会报错；
//Singleton instance = new Singleton();
//两次调用getInstance()方法并分别赋值；
Singleton instance1 = Singleton.getInstance();
Singleton instance2 = Singleton.getInstance();
//对比两个变量，发现是同一实例；
if(instance1 == instance2){
System.out.println("两个对象是同一个对象");
}
}
}
//运行结果：
两个对象是同一个实例
3）“饿汉模式”的单例模式在多线程下是线程安全的吗？ 上述代码中，get 方法返回的是已经创建好的实例，这个操作本质上只是一个“读操作”，多个线程读取同一个变量并不会造成线程不安全。 因此“饿汉模式”的单例模式在多线程下是线程安全的。
三、“懒汉模式”实现单例模式
3.1 单线程下的“懒汉模式”
通过代码演示“懒汉模式”实现的单例模式：
class Singleton{
//声明一个变量作为类属性；
private static Singleton instance = null;
//判断变量是否为null，是则创建实例后返回，否则返回；
public static Singleton getInstance() {
if(instance == null){
instance = new Singleton();
}
return instance;
}
//将构造方法私有化；
private Singleton() { }
}
1）上述代码做了什么？ 声明了一个类属性。类对象只会有一个，这个类属性也只会有一个。 私有化构造方法，外部无法 new 新的实例，只能通过 get 方法获取唯一的那一个 instance。get 方法中根据变量是否为 null 判断是否应该创建实例。
2）为什么叫做“懒汉模式”？ 上述代码中，实例是在程序员第一次调用 get 方法后才创建的，创建时机较晚，或者根本不用创建，因此称为“懒汉模式”。
3.2 多线程下的“懒汉模式”
1）单线程下的“懒汉模式”在多线程下是线程安全的吗？ 答案是否定的，单线程下的“懒汉模式”在多线程下是线程不安全的，我们可以从以下两个方面分析： “原子性”： 上述代码中判断变量是否为空的代码 —— if(instance == null)，和实例化代码 —— instance = new Singleton()，并非是“原子”的。在多线程环境下，这就可能导致线程不安全。 可以使用 synchronized 关键字，将这两句代码加锁，解决这个问题。 内存可见性和指令重排序： 因为 instance 是一个被 static 修饰的共享数据，而且编译器内部可能对实例化的代码 —— new Singleton()，进行了编译器优化。 这就无法保证内存的可见性和指令的顺序执行，因此在多线程环境下可能导致线程不安全。 可以使用 volatile 关键字，对共享数据 instance 进行修饰，解决这个问题。
使用以上两个关键字的原因和方式，详细请参考以下博客：
阅读指针 -> 《synchronized 关键字 和 volatile 关键字》＜JavaEE＞ synchronized关键字和锁机制 -- 锁的特点、锁的使用、锁竞争和死锁、死锁的解决方法-CSDN博客文章浏览阅读70次。介绍了 synchronized 关键字 和 锁机制，其中重点介绍了锁的特点、使用方法和死锁的相关内容。https://blog.csdn.net/zzy734437202/article/details/134742168＜JavaEE＞ volatile关键字 -- 保证内存可见性、禁止指令重排序-CSDN博客文章浏览阅读59次。简单介绍什么是内存可见性和指令重排序。volatile关键字可以将这两种编译器优化强制关闭。https://blog.csdn.net/zzy734437202/article/details/134757070
2）“懒汉模式”在多线程下应该怎么编写？ 根据上述分析，根据单线程模式下的“懒汉模式”进行改进。 方法如下： 增加 volatile 关键字对共享数据进行修饰。 为判断是否为 null 和 实例化的代码加锁，使这两句代码称为“原子”。
增加 volatile 关键字对共享数据进行修饰：
private volatile static Singleton instance = null;
为判断是否为 null 和 实例化的代码加锁，使这两句代码称为“原子”：
public static Singleton getInstance() {
synchronized (locker){
if(instance == null){
instance = new Singleton();
}
}
return instance;
}
3）“双重校验锁” 我们再仔细分析一下上述的 get 方法。 假设程序需要多次调用这个 get 方法，那么每一次进入都会进行加锁，加锁是会增加系统开销的。 那么是否真的有必要每次都加锁呢？ 当 get 方法被第一次调用，实例就会被创建，那么后续再调用这个 get 方法时，返回实例就好了，加锁部分的代码块，完全可以不用执行。 在加锁的代码块之外，再增加一个if(instance == null)进行判断，那么实例在被创建之后，也就不会再进入加锁的代码块中了。 我们成功利用“双重校验锁”，优化了程序。
代码演示“双重校验锁”优化后的 get 方法：
public static Singleton getInstance() {
//这个if用于判断是否需要加锁；
if(instance == null){
synchronized (locker){
//这个if用于判断是否需要新建实例；
if(instance == null){
instance = new Singleton();
}
}
}
return instance;
}
经过以上的完善和优化，我们终于可以写出在多线程下保证线程安全的“懒汉模式”单例模式了：
class Singleton{
//声明一个变量作为类属性；
private volatile static Singleton instance = null;
//判断变量是否为null，是则创建实例后返回，否则返回；
public static Singleton getInstance() {
//这个if用于判断是否需要加锁；
if(instance == null){
synchronized (Singleton.class){
//这个if用于判断是否需要新建实例；
if(instance == null){
instance = new Singleton();
}
}
}
return instance;
}
//将构造方法私有化；
private Singleton() { }
}
阅读指针 -> 《经典设计模式之 -- 使用阻塞队列实现“生产者-消费者模型”》
＜JavaEE＞ 经典设计模式之 -- 使用阻塞队列实现“生产者-消费者模型”-CSDN博客自己实现了的阻塞队列，介绍了经典的设计模式“生产者-消费者模型”。https://blog.csdn.net/zzy734437202/article/details/134807241
参考阅读
发表评论