本文主要是介绍【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修饰。
日子是自己的，你开心，它就会幸福。
这篇关于【JavaEE初阶系列】——单例模式 (“饿汉模式“和“懒汉模式“以及解决线程安全问题）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
