【JavaEE】——单例模式引起的多线程安全问题：“饿汉/懒汉”模式，及解决思路和方法（面试高频）

阿华代码，不是逆风，就是我疯，你们的点赞收藏是我前进最大的动力！！希望本文内容能够帮助到你！

目录

一：单例模式（singleton）

1：概念

二：“饿汉模式”

1：前引

2：代码编译

3：代码分析

4：解释为什么叫“饿汉模式”

三：“懒汉”模式

1：前引

2：代码编译

3：代码分析

4：“懒汉”的优点

5：比较“饿汉”和“懒汉”

四：“饿汉”模式线程安全问题

五：“懒汉”模式的线程安全问题

1：重复创建实例

2：解决问题

（1）解决思路的核心本质：

（2）缺点：

①效率降低：

②不可预期：

3：优化效率问题

（1）问题解释

（2）解决方法

六：指令重排序问题

前引：

1：代码拆分三指令

2：分析

3：代码解释

4：解锁思路

（1）复习volatile两个功能

---

一：单例模式（singleton）

1：概念

单例模式就是，在java进程中，要求指定的类，只能有一个对象

我们通过一些特殊的技巧来确保，我们的实例（对象）只有一个——换句话说，就是如果我们尝试new多个实例，编译器就会报错。

二：“饿汉模式”

1：前引

（1）知识科普

我们先认识俩个单词——singleton（单例模式）和getInstance（获取实例）

（2）每个类只能有一个类对象，比如Thread类，Thread.class（获取到Thread这个类的类对象）它是从.class文件加载到内存当中的

2：代码编译

package thread;/*** Created with IntelliJ IDEA.* Description:* User: Hua YY* Date: 2024-09-24* Time: 13:20*/
class Singleton{private static Singleton instance = new Singleton();public static Singleton getInstance(){//返回值类型为Singletonreturn instance;}private Singleton(){//静态构造方法让你访问不到}}
public class ThreadDemon28 {//“饿汉模式”public static void main(String[] args) {Singleton s1 = Singleton.getInstance();Singleton s2 = Singleton.getInstance();System.out.println(s1 == s2);//判断s1和s2是否指向的是同一个对象}
}

3：代码分析

最后我们在main方法中比较s1，s2获取到的地址是否相同（s1，s2所指向的对象）

4：解释为什么叫“饿汉模式”

因为我们在类加载的时候就创建了这个实例，（初始化静态成员变量），这个时机非常的早——相当于程序一启动，实例就创建好了。所以就用“饿汉”来形容创建实例非常的迫切非常早

三：“懒汉”模式

1：前引

“懒汉”模式相对于“饿汉”模式不同的地方在于创建实例的时机更加晚一些，下面我们通过代码来进行展示

2：代码编译

package thread;/*** Created with IntelliJ IDEA.* Description:* User: Hua YY* Date: 2024-09-24* Time: 13:52*/
class SingletonLazy{private static SingletonLazy instance = null;public static SingletonLazy getInstance(){if (instance == null){   //如果instance为null，则进入if创建实例，创建实例的时机是第一次调用getInstance这个方法instance = new SingletonLazy();}return instance;//第二次第三次调用getInstance()这个方法，就不会进入if语句中，而直接返回instance了}private SingletonLazy(){}
}
public class ThreadDemon29 {public static void main(String[] args) {SingletonLazy s1 = SingletonLazy.getInstance();SingletonLazy s2 = SingletonLazy.getInstance();System.out.println(s1 == s2);}}

3：代码分析

很明显的不同是，初始，instance初始化为null，并没有实例化对象，只有第一次调用了getInstance方法后才会实例化SingletonLazy

4：“懒汉”的优点

例如现在有一个非常大的文件（1个G）

“饿汉”模式会直接把一个G全部加载到内存中，在进行展示。

“懒汉”模式会先加载100kb的数据到内存中，随着用户的翻页，在逐步的加载到内存当中

5：比较“饿汉”和“懒汉”

（1）创建时机上“饿汉”更早

（2）“饿汉”创建实例依赖于程序驱动，“懒汉”创建实例依赖于调用方法

四：“饿汉”模式线程安全问题

对于饿汉模式，无论有多少个线程在调用getInstance 方法，都会返回instance，对于return这一条代码来说，只有一个“读操作”，线程是非常安全的

五：“懒汉”模式的线程安全问题

1：重复创建实例

①看下面这个例子，我们拆分if里面的代码，会发现实例被new了两次，这就不是单例模式了，就有bug了

②有人说：不就是多new了个对象嘛，问题不大~~~。但是对于单例模式来说，一个对象可能要管理10GB的内存，或者更大，多new一个对象，就多翻了一倍的内存啊！！

2：解决问题

想办法给if条件和创建实例进行打包——用关键字synchronized。

（1）解决思路的核心本质：

是让，if语句打包成一个整体，成为“原子性操作”

（2）缺点：

①效率降低：

以下加锁的思路有一个致命缺点，我们保证多线程下我们创建出来的实例就只有一个是通过“加锁”和“解锁”来解决的，但是这个过程很耗费资源

②不可预期：

一旦线程发生了阻塞，那么什么时候解除阻塞我们是不可控制和预期的

3：优化效率问题

（1）问题解释

（2）解决方法

六：指令重排序问题

前引：

指令重排序是编译器优化的一种方式，调整原有代码的执行顺序，保证逻辑不变的前提下，提高程序的效率

1：代码拆分三指令

上面这段代码可以分为三个指令来执行 

①申请一段内存空间                    （买房子）

②在这段内存上，调用构造方法，初始化实例       （给房子装修）

③把内存地址赋值给instance                             （拿到房子的钥匙）

package thread;/*** Created with IntelliJ IDEA.* Description:* User: Hua YY* Date: 2024-09-24* Time: 13:52*/
class SingletonLazy{private static Object locker1 = new Object();private static SingletonLazy instance = null;public static SingletonLazy getInstance(){if (instance == null){synchronized(locker1){if (instance == null){   //如果instance为null，则进入if创建实例，创建实例的时机是第一次调用getInstance这个方法instance = new SingletonLazy();}}}return instance;//第二次第三次调用getInstance()这个方法，就不会进入if语句中，而直接返回instance了}private SingletonLazy(){}
}
public class ThreadDemon29 {public static void main(String[] args) {SingletonLazy s1 = SingletonLazy.getInstance();SingletonLazy s2 = SingletonLazy.getInstance();System.out.println(s1 == s2);}}

2：分析

我们延用上面的代码

上述三个指令的执行顺序可以为①②③，也可以为①③②

问题出现在如果执行顺序为①③②上

3：代码解释

线程t1经过代码优化后，先执行③赋值地址，此时instance只是接收了一个地址，它所指向的是一个尚未被初始化的对象，这个对象啥也不是，可以理解成“全为0”

恰巧此时线程t2插入，进入if条件判断，判断instance ！= null，线程t2以为实例已经创建完毕，直接return instance，假设t2紧接着调用instance里面的方法或者属性，就会出现大问题。

4：解锁思路

加入关键字volatile

（1）复习volatile两个功能

①保证内存可见性（即每次访问变量都要重新读取内存，而不会优化到寄存器或者缓存当中）

②禁止指令重排序

此时针对变量的读写操作，就不会出现重排序的问题了