多线程 (六) 单例模式
🎉🎉🎉点进来你就是我的人了
博主主页：🙈🙈🙈戳一戳,欢迎大佬指点!
人生格言：当你的才华撑不起你的野心的时候,你就应该静下心来学习!欢迎志同道合的朋友一起加油喔🦾🦾🦾
目标梦想：进大厂，立志成为一个牛掰的Java程序猿，虽然现在还是一个🐒嘿嘿
谢谢你这么帅气美丽还给我点赞！比个心
目录
一. 什么是单例模式
二. 单例模式的类型
三. 单例模式优缺点
四. 创建单例模式
1.饿汉式实现单例模式
2. 懒汉式实现单例模式
3. 两种实现方式的比较
五.解决懒汉单例的实现带来的线程不安全问题
一. 什么是单例模式
单例模式是指在内存中只会创建且仅创建一次对象的设计模式。在程序中多次使用同一个对象且作用相同时，为了防止频繁地创建对象使得内存飙升，单例模式可以让程序仅在内存中创建一个对象，让所有需要调用的地方都共享这一单例对象。
二. 单例模式的类型
单例模式有两种类型：
- 懒汉式：在真正需要使用对象时才去创建该单例类对象
- 饿汉式：在类加载时已经创建好该单例对象，等待被程序使用
三. 单例模式优缺点
优点： 1、在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例（比如管理学院首页页面缓存）。
2、避免对资源的多重占用（比如写文件操作）。
缺点：没有接口，不能继承，与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心外面怎么样来实例化。
主要解决：一个全局使用的类频繁地创建与销毁。
何时使用：当您想控制实例数目，节省系统资源的时候。
如何解决：判断系统是否已经有这个单例，如果有则返回，如果没有则创建。
关键代码：构造函数是私有的。
注意：
1、单例类只能有一个实例。
2、单例类必须自己创建自己的唯一实例。
3、单例类必须给所有其他对象提供这一实例。
四. 创建单例模式
1.饿汉式实现单例模式
主要实现步骤:(饿汉主要体现在直接创建对象）
1.先将构造方法私有化， 避免用户直接在外部 new 新对象。
2.在类的内部属性部分直接创建一个对象（我们已经将构造方法私有化了，因此在外部没有办法 new 新对象，所以只能在类的内部创建对象）。
3.向外提供一个公共的静态方法，用于外部引用该对象。（创建好了对象后，如果对外不提供公共方法，我们就没有办法使用这个被创建的对象。）
注意:之所以用static是因为类外无法直接创建对象,我们加上static就可以通过类名获取该类的属性和方法了.
代码演示:
public class Singleton {// 提供一个对象private static Singleton instance = new Singleton();// 防止外部new对象private Singleton(){}// 使得外部能够访问到创建的对象public static Singleton getInstance(){return instance;}
}2. 懒汉式实现单例模式
主要实现步骤:
1.先将构造器私有化， 避免用户直接在外部 new 新对象。
2.在类的内部 声明一个对象引用，但是不创建， 即先不 new；
3.向外提供一个公共的静态方法，用于创建对象并返回对象引用。
(懒汉主要体现在不直接创建对象，而是在需要的时候再创建)
代码演示:
public class Singleton {// 提供一个对象的引用private static Singleton instance = null;// 防止外部new对象private Singleton(){}// 用于创建对象或使得外部能够访问到创建的对象public static Singleton getInstance(){if (instance == null){instance = new Singleton();}return instance;}
}3. 两种实现方式的比较
两种实现方法都是通过将构造方法限定为private避免了类在外部被实例化，在同一个虚拟机范围内，Singleton的唯一实例只能通过getInstance()方法访问。
（事实上，通过Java反射机制是能够实例化构造方法为private的类的，那基本上会使所有的Java单例实现失效。此问题在此处不做讨论，姑且掩耳盗铃地认为反射机制不存在。）
但是以上懒汉式单例的实现没有考虑线程安全问题，它是线程不安全的，并发环境下很可能出现多个Singleton实例，相比较饿汉式单例的实现仅仅只是读取了变量的内容，因此，是线程安全的！
五.解决懒汉单例的实现带来的线程不安全问题
在懒汉模式的这段代码中,既包含了读，又包含了写，且读写还不是原子的（分成了两个步骤~）， 所以存在线程安全问题。
举例解释说明:
比如：两个线程t1，t2同时进入该方法，需要返回给 t1 ，t2 对象实例。当 t1 进入该方法后，进行判断，不为 null，因此需要创建一个对象，而在创建对象的过程中，t2 刚好也进入了该方法，也被判断成了不为 null，此时，t1, t2就指向不同的对象了，所以它是线程不安全的。
对于原子性所引起的线程安全问题,前面我们有讲线程安全及解决方案(看这一篇就够了)
这里我们可以对这段代码直接加锁,这样就可以保证在进行读和写操作的时候，只有一个线程在操作，也就可以避免另一个线程同时进入 if 语句去创建对象了
public static Singleton getInstance(){//对类对象加锁synchronized (Singleton.class) {if (instance == null) {instance = new Singleton();}return instance;}}问题解决了,可是，这种方案真的好吗？
对于加锁操作来说，加锁确实可以让代码保证线程安全，但是也会付出相应的代价， 最典型的代价就是程序运行变慢了。本来我多个线程运行的好好的，你给我加了把锁，其他线程不就进不去了吗？（一定程度上的阻塞）
此时我们可以再加一个判断！判断 instance 是否被初始化完成，如果已经初始化，就不必进入加锁的代码块了！
// 用于创建对象或使得外部能够访问到创建的对象public static Singleton getInstance(){//用于判断是否加锁if(instance == null) {synchronized (Singleton.class) {//用于判断是否创建对象实例if (instance == null) {instance = new Singleton();}}}return instance;}现在代码似乎看起来已经没有问题了,但实际上还有可能发生内存可见性问题!
如果多个线程，都去调用 getInstance方法，就会造成大量的读 instance 操作。而，我们知道，对于在内存读和在寄存器读来说，后者的效率更高。因此，编译器会自作主张，对代码进行优化：将读内存操作优化成读寄存器操作。
也就是说，即使某个线程将instance初始化了，但是由于编译器的优化，在其他线程的视角看起来，instance 还是null。
也就是说，这里的内存可见性问题，会导致第一个if语句失效，即不该加锁的时候还会加锁。因此，我们需要保证内存可见！即使用 volatile 对 instance 进行修饰,被volatile修饰的变量，都会从主内存中读取该变量。同时，使用 volatile 可以防止 指令重排序。
至此,懒汉单例的实现带来的线程不安全问题基本得以解决!
对于线程安全问题不是太了解的可以参考我上一篇博客
线程安全及解决方案(看这一篇就够了)