【JavaEE初阶系列】——单例模式 (“饿汉模式“和“懒汉模式“以及解决线程安全问题)

目录

🚩单例模式

🎈饿汉模式

🎈懒汉模式

❗线程安全问题

📝加锁

📝执行效率提高

📝指令重排序

🍭总结


单例模式,非常经典的设计模式,也是一个重要的学科,也是程序员必备的技能。

设计模式其实就是程序员的棋谱,开发过程中,会遇到"经典场景",针对这些经典场景,

🚩单例模式

单例实际上是单个实例(对象),这种场景种,希望有的类,只能有一个对象,不能有多个,再这种场景下,就可以使用单例模式了。

程序员不能手动自己设置一个单个对象,确实可以,但是编译器不相信你,需要我们做监督,确保这个对象不会出现多个(出现多个的时候直接编译报错) 比如我们前期学到的 final ,interface,@Override,throw等等,都是涉及到这里的思想方法。


🎈饿汉模式

类加载的时候,创建实例

  • 在类的内部,提供一个现成的实例。
  • 把构造方法设为private,避免其他代码能够创建出实例。

通过上述方式,就强制了其他程序员在使用这个类的时候,就不会创建出多个对象了。

class SingTon{
    private static SingTon instance=new SingTon();
    //后续如果需要得到这个实例,那么就可以直接调用getInstance()方法
    public static SingTon getInstance(){
        return instance;
    }
    //给构造方法设置成私有的,此时类外面的其他代码,就无法new其他实例了
    private SingTon(){};
}

得到实例的方法是被static修饰的,所以只用依赖类来。

但是如果你创建对象的时候,因为构造方法是私有的,也是无法创建的。

所以这样就真正做到了"饿汉模式"的单例模式.


🎈懒汉模式

非必要,不创建实例,等需要了,再创建

class SingLazy{
    private static SingLazy instance=null;
    public static SingLazy getInstance(){
        //首次调用getInstace()方法的时候才是创建
        if(instance==null){
            instance=new SingLazy();
        }
        return instance;
    }
    private SingLazy(){};
}

首先我们先不创建对象,其指向空,如果instace是null,那么我们创建对象,如果不是空,那么就直接返回instace。


其实"懒"也是意味着高效率,省略了一些不必要的操作,比如去上个厕所,顺便去倒杯水喝。而不是想喝水立即去喝水。

就比如文本编译器(记事本)比如需要打开一个非常大的文件(10gb)

  • 1.先把所有的内容,都加载到内存中,然后再显示内容(加载过程会很慢)
  • 2.只加载一小部分数据到内存,立即显示内容,随着用户翻页,再加载其他内容(懒汉)

介绍完懒汉模式和饿汉模式是如何实现单例模式的。

接下来我们来探究探究"懒汉模式"和"饿汉模式"俩种模式在线程安全中是否是安全的!


❗线程安全问题

📝加锁

这俩种写法,是否有线程安全问题呢?(如果多个线程,同时调用getInstance,是否会出问题呢?)

这俩种方式,有一个是线程安全的,一个是不安全的。

  • 如果多个线程,同时修改同一个变量,此时就可能出现线程安全问题。
  • 如果多个线程,同时读取同一个变量,这个时候就没事~不会有线程安全问题。

我们之前学到了,再多线程中对同一个变量进行修改的时候,这时候会出现线程安全问题。

这个时候,实例已经是多个了,违背了单例的要求。

一旦这俩操作被穿插了,就容易出现问题,加锁的关键是要保证这俩操作是一个整体


那加锁的位置是在哪呢?

一个加锁new是创建对象,第二个加锁是将if和new的都加锁了。锁不是加了就线程安全,加的对不对,非常关键。

  • 1>锁的{}范围是合理的,能够把需要作为整体的每个部分都囊括进去
  • 2>锁的对象,也得是能够起到合理的锁竞争的效果。

因为我们上述的线程中因为t1线程if成立了,然后t2线程进行if和new操作,此时new操作完了后t1线程剩下的部分继续进行,我们只给new的部分加锁,那么就依旧存在线程安全问题。我们需要将if 和new操作整体都加上锁,才会避免穿插的情况。

但是一旦代码这样写,后续每次调用getInstace,就需要先加锁了,但是实际上,懒汉模式,线程安全问题,只是出现在最开始的时候(对象没有new的情况),一旦对象new出来了,后续多线程调用getInstace,就只有读操作,就不会线程不安全了。其实加锁是一个开销很大的操作,加锁就可能涉及到锁冲突的问题,一冲突就会引起阻塞等待了,某个代码涉及到加锁,其实这个代码和高性能就冲突了。

如果多个线程情况下,第一次对象是null,此时创建好对象之后,其他线程阻塞等待,然后后面线程继续进行,然后一直加锁,if判断不成立,就进行解锁,然后其他线程又加锁,这样如果有一百个线程进行,那么就会有一百次加锁的情况,那样性能方面是开销很大的。


📝执行效率提高

有没有什么办法,既可以让代码线程安全,又不会对执行效率产生太多的影响呢?

在加锁语句的外层,再引入一个if条件,判定一下,看看当前这里的锁,是否要加上。

  • 如果对象已经有了,线程就安全了,就不用加锁了。

  • 如果对象还没有,存在线程不安全的风险,就需要加锁。

     if(instance==null){
        //首次调用getInstace()方法的时候才是创建
          synchronized (SingLazy.class) {
             if(instance==null){
                 instance=new SingLazy();
               }
             }
          }
    

同样的条件连续写俩遍,在别的地方没啥意义,但是这个代码是非常有意义的,也是非常重要的,防止上述的执行效率很低。第一个if用来判定是否需要加锁,第二个if用来判定是否需要new对象。

就是说第二个if确保只有一个线程去创建实例,第一个if确保其他线程直接拿这个实例就行,不用每次都在那一直傻傻等待。t1线程俩个if都判断成立了,然后t2线程第一个if都进不去,因为已经创建好对象了(是否需要继续加锁)。


📝指令重排序

指令重排序也可能会出现对上述的问题影响。编译器为了执行效率,可能会调整原有代码的执行顺序,调整的前提是要保持逻辑不变。

通常情况下,指令重排序,就能够保证逻辑不变的前提下,把程序执行效率大幅度提高。(单线程下好办,多线程下,可能会出现误判)

new操作,是可能会触发指令重排序的。

new操作可以拆分成三步:

  • 1.申请内存空间
  • 2.在内存空间上构造对象(构造方法)
  • 3.把内存的地址,赋值给instance引用

可以按照1,2,3来执行,也可以按照1,3,2来执行(但是1肯定是执行的)。

但是在多线程的情况下,就可能有问题了。假设是按132执行的,当t1执行完1和3时候,此时Instance就已经非空了!!但是此时Instance指向的是一个还没初始化的非法对象。

此时此刻,还没执行2呢,t2就开始执行了,t2判定instance==null,条件不成立,于是t2就直接return instance。进一步的t2线程的代码就可能会访问instance里面的属性和方法了。

但是instance是一个未初始化的非法对象,如果t2线程访问的话就会出现bug。

这就相当于买房子的时候,第一步是买房子,第二步装修,第三步是交钥匙,最后是一个精装房,但是如果我们按照这个顺序第一步是买房子,第二步就交钥匙了,打开之后只是一个毛胚房。

解决的方法就是我们之前学到的是volatile,可以避免指令重排序问题。让volatile修饰Instance,此时就可以保证Instance在修改过程中就不会出现执行重排序的现象了。

class SingLazy{
    private static volatile SingLazy instance=null;
    public static SingLazy getInstance(){
        if(instance==null){
            //首次调用getInstace()方法的时候才是创建
            synchronized (SingLazy.class) {
                if(instance==null){
                    instance=new SingLazy();
                }
            }
        }
        return instance;
    }
    private SingLazy(){};
}

这样就解决了在创建对象的时候,编译器优化的时候,直接执行分配内存空间和把内存的地址,赋值给insatance引用。但是中间的在内存空间中创建对象的一步直接被编译器优化了,就不执行了。然后最后别的线程在调用的时候判断不成立, 直接返回instance就会是一个没初始化的非法对象。如果用volatile修饰,那么三步都操作,没有编译器优化的现象了。


🍭总结

在最开始的时候,

一、多线程的情况下对同一个变量进行修改会出现线程安全的问题,之后我们就需要加锁,让其他线程阻塞等待,

二、 加锁的时候我们要注意到,if和new俩个操作都得统一加锁在一起,如果只给new加锁的话,也依旧会出现问题。

三、加完锁之后,我们发现线程t1判断之后instance不为空,然后其他线程继续加锁,不为空null,然后解锁,然后阻塞等待的线程继续加锁,如果有一百个线程,那么就有一百次加锁。这样会使执行效率降低,所以我们就继续判断if,这个if和内层的if判断的条件是一样的,但是意义是不一样的,第一个if是判断是否需要加锁,第二个if是判断是否创建这个对象

四、我们还要考虑到指令重排序问题,因为new操作会有三步,分配内存空间,让内存空间构造方法(创建对象),内存的地址赋值给instance引用,但是编译器会优化,不进行内存空间构造方法,直接分配完空间之后,直接赋值给instance引用。这样就导致了t1线程拿到的instance是一个未初始化的非法对象但是非null,t2线程再继续进入俩层if不为空,这样就返回了未初始化的非法对象,这样就导致了bug,就得需要用volatile修饰


日子是自己的,你开心,它就会幸福。

相关推荐
真的很上进4 小时前
如何借助 Babel+TS+ESLint 构建现代 JS 工程环境?
java·前端·javascript·css·react.js·vue·html
噢,我明白了8 小时前
同源策略:为什么XMLHttpRequest不能跨域请求资源?
javascript·跨域
sanguine__8 小时前
APIs-day2
javascript·css·css3
关你西红柿子8 小时前
小程序app封装公用顶部筛选区uv-drop-down
前端·javascript·vue.js·小程序·uv
济南小草根8 小时前
把一个Vue项目的页面打包后再另一个项目中使用
前端·javascript·vue.js
小木_.9 小时前
【python 逆向分析某有道翻译】分析有道翻译公开的密文内容,webpack类型,全程扣代码,最后实现接口调用翻译,仅供学习参考
javascript·python·学习·webpack·分享·逆向分析
Aphasia3119 小时前
一次搞懂 JS 对象转换,从此告别类型错误!
javascript·面试
m0_748256569 小时前
Vue - axios的使用
前端·javascript·vue.js
m0_748256349 小时前
QWebChannel实现与JS的交互
java·javascript·交互
胡西风_foxww9 小时前
【es6复习笔记】函数参数的默认值(6)
javascript·笔记·es6·参数·函数·默认值