🎉🎉🎉点进来你就是我的人了
博主主页：🙈🙈🙈戳一戳,欢迎大佬指点!
人生格言：当你的才华撑不起你的野心的时候,你就应该静下心来学习!

欢迎志同道合的朋友一起加油喔🦾🦾🦾
目标梦想：进大厂，立志成为一个牛掰的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 可以防止 指令重排序。

 至此,懒汉单例的实现带来的线程不安全问题基本得以解决!

对于线程安全问题不是太了解的可以参考我上一篇博客

线程安全及解决方案(看这一篇就够了)