【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(){//返回值类型为Singleton
        return 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是否指向的是同一个对象
    }
}

image.gif

image.gif 编辑

3:代码分析

image.gif 编辑

image.gif 编辑

最后我们在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);
    }
}

image.gif

image.gif 编辑

3:代码分析

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

4:“懒汉”的优点

例如现在有一个非常大的文件(1个G)

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

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

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

(1)创建时机上“饿汉”更早

(2)“饿汉”创建实例依赖于程序驱动,“懒汉”创建实例依赖于调用方法

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

image.gif 编辑

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

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

1:重复创建实例

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

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

image.gif 编辑

2:解决问题

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

(1)解决思路的核心本质:

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

(2)缺点:

①效率降低:

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

②不可预期:

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

image.gif 编辑

image.gif 编辑

3:优化效率问题

(1)问题解释

image.gif 编辑

(2)解决方法

image.gif 编辑

六:指令重排序问题

前引:

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

image.gif 编辑

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

image.gif

2:分析

我们延用上面的代码

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

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

image.gif 编辑

3:代码解释

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

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

4:解锁思路

加入关键字volatile

(1)复习volatile两个功能

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

②禁止指令重排序

image.gif 编辑

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

相关文章
|
2天前
|
Java
【JavaEE】——多线程常用类
Callable的call方法,FutureTask类,ReentrantLock可重入锁和对比,Semaphore信号量(PV操作)CountDownLatch锁存器,
|
2天前
|
Java 关系型数据库 MySQL
【JavaEE“多线程进阶”】——各种“锁”大总结
乐/悲观锁,轻/重量级锁,自旋锁,挂起等待锁,普通互斥锁,读写锁,公不公平锁,可不可重入锁,synchronized加锁三阶段过程,锁消除,锁粗化
|
2天前
|
Java Go 调度
【JavaEE】——线程池大总结
线程数量问题解决方式,代码实现线程池,ThreadPoolExecutor(核心构造方法),参数的解释(面试:拒绝策略),Executors,工厂模式,工厂类
|
2天前
|
Java 调度
|
2天前
|
Java 调度
【JavaEE】——线程的安全问题和解决方式
【JavaEE】——线程的安全问题和解决方式。为什么多线程运行会有安全问题,解决线程安全问题的思路,synchronized关键字的运用,加锁机制,“锁竞争”,几个变式
|
5天前
|
NoSQL Redis
单线程传奇Redis,为何引入多线程?
Redis 4.0 引入多线程支持,主要用于后台对象删除、处理阻塞命令和网络 I/O 等操作,以提高并发性和性能。尽管如此,Redis 仍保留单线程执行模型处理客户端请求,确保高效性和简单性。多线程仅用于优化后台任务,如异步删除过期对象和分担读写操作,从而提升整体性能。
17 1
|
2月前
|
存储 消息中间件 资源调度
C++ 多线程之初识多线程
这篇文章介绍了C++多线程的基本概念,包括进程和线程的定义、并发的实现方式,以及如何在C++中创建和管理线程,包括使用`std::thread`库、线程的join和detach方法,并通过示例代码展示了如何创建和使用多线程。
60 1
|
2月前
|
Java 开发者
在Java多线程编程中,创建线程的方法有两种:继承Thread类和实现Runnable接口
【10月更文挑战第20天】在Java多线程编程中,创建线程的方法有两种:继承Thread类和实现Runnable接口。本文揭示了这两种方式的微妙差异和潜在陷阱,帮助你更好地理解和选择适合项目需求的线程创建方式。
33 3
|
2月前
|
Java 开发者
在Java多线程编程中,选择合适的线程创建方法至关重要
【10月更文挑战第20天】在Java多线程编程中,选择合适的线程创建方法至关重要。本文通过案例分析,探讨了继承Thread类和实现Runnable接口两种方法的优缺点及适用场景,帮助开发者做出明智的选择。
25 2
|
2月前
|
Java
Java中多线程编程的基本概念和创建线程的两种主要方式:继承Thread类和实现Runnable接口
【10月更文挑战第20天】《JAVA多线程深度解析:线程的创建之路》介绍了Java中多线程编程的基本概念和创建线程的两种主要方式:继承Thread类和实现Runnable接口。文章详细讲解了每种方式的实现方法、优缺点及适用场景,帮助读者更好地理解和掌握多线程编程技术,为复杂任务的高效处理奠定基础。
41 2