【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修饰。