单例模式（Singleton Pattern）是 Java 中最简单的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。
注意：
1、单例类只能有一个实例。
2、单例类必须自己创建自己的唯一实例。
3、单例类必须给所有其他对象提供这一实例。
资源加载和性能：
饿汉式在类创建的同时就实例化一个静态对象出来，不管之后会不会使用这个单例，都会占据一定的内存，但是相应的，在第一次调用时速度也会更快，因为其资源已经初始化完成。
而懒汉式顾名思义，会延迟加载，在第一次使用该单例的时候才会实例化对象出来，第一次调用时要做初始化，如果要做的工作比较多，性能上会有些延迟，之后就和饿汉式一样了。
主要解决：一个全局使用的类频繁地创建与销毁。
何时使用：当您想控制实例数目，节省系统资源的时候。
如何解决：判断系统是否已经有这个单例，如果有则返回，如果没有则创建。
关键代码：构造函数是私有的。
应用实例：
1、一个男人只能有一个妻子。
2、Windows 是多进程多线程的，在操作一个文件的时候，就不可避免地出现多个进程或线程同时操作一个文件的现象，所以所有文件的处理必须通过唯一的实例来进行。
3、一些设备管理器常常设计为单例模式，比如一个电脑有两台打印机，在输出的时候就要处理不能两台打印机打印同一个文件。
优点：
1、在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例（比如管理学院首页页面缓存）。
2、避免对资源的多重占用（比如写文件操作）。
缺点：
没有接口，不能继承，与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心外面怎么样来实例化。
使用场景：
1、要求生产唯一序列号。
2、WEB 中的计数器，不用每次刷新都在数据库里加一次，用单例先缓存起来。
3、创建的一个对象需要消耗的资源过多，比如 I/O 与数据库的连接等。
饿汉式
饿汉式天生就是线程安全的，可以直接用于多线程而不会出现问题。
- 是否 Lazy 初始化：否
- 实现难度：易
- 描述：这种方式比较常用，但容易产生垃圾对象。
- 优点：没有加锁，执行效率会提高。
- 缺点：类加载时就初始化，浪费内存。
- 它基于 classloder 机制避免了多线程的同步问题。不过，instance 在类装载时就实例化，虽然导致类装载的原因有很多种。
- 在单例模式中大多数都是调用 getInstance 方法，但是也不能确定有其他的方式（或者其他的静态方法）导致类装载，这时候初始化 instance 显然没有达到 lazy loading 的效果。
public class EagerSigleton(){
private static final EagerSigleton m_instatnce=new EagerSigleton();
// 构造器私有化,不能在类的外部随意创建对象
private EagerSigleton(){}
// 提供一个全局的访问点来获得这个"唯一"的对象
public static EagerSigleton getInstance(){
System.out.println("加载饿汉式....");
return m_instatnce;
}
}
静态代码块实现：
public class EagerSigleton{
private static EagerSigletoninstance;
static {
m_instatnce= new EagerSigleton();
}
private EagerSigleton() {}
public static EagerSigletongetInstance() {
return m_instatnce;
}
}
这种方式和上面的方式其实类似，只不过将类实例化的过程放在了静态代码块中，也是在类装载的时候，就执行静态代码块中的代码，初始化类的实例。优缺点和上面是一样的。
饿汉就是类一旦加载，就把单例初始化完成，保证getInstance的时候，单例是已经存在的了。
懒汉式
懒汉式本身是非线程安全的。
- 是否 Lazy 初始化：是
- 实现难度：易
- 描述：这种方式是最基本的实现方式，这种实现最大的问题就是不支持多线程。因为没有加锁 synchronized，所以严格意义上它并不算单例模式。
- 这种方式 lazy loading 很明显，不要求线程安全，在多线程不能正常工作。
public class LazySigleton(){
private static final LazySigleton instatnce=null;
// 构造器私有化,不能在类的外部随意创建对象
private LazySigleton(){}
// 提供一个全局的访问点来获得这个"唯一"的对象
public static LazySigleton getInstance(){
if(instatnce == null){ //1：读取instance的值
instatnce = new LazySigleton(); //2: 实例化instance
}
return instatnce;
}
}
而懒汉比较懒，只有当调用getInstance的时候，才会去初始化这个单例。
懒汉非线程安全原因（两点）
对于以上代码注释部分，如果此时有两个线程，线程A执行到1处，读取了instance为null，然后cpu就被线程B抢去了，此时，线程A还没有对instance进行实例化。
因此，线程B读取instance时仍然为null，于是，它对instance进行实例化了。然后，cpu就被线程A抢去了。此时，线程A由于已经读取了instance的值并且认为它为null，所以，
再次对instance进行实例化。所以，线程A和线程B返回的不是同一个实例。
那么，如何解决呢？
- 在方法前面加synchronized修饰。这样肯定不会再有线程安全问题。
public class LazySigleton(){
private static final LazySigleton instatnce=null;
private LazySigleton(){}
public static synchronized LazySigleton getInstance(){
if(instatnce == null){
instatnce = new LazySigleton();
}
return instatnce;
}
}
这种解决方式有个问题：假如有100个线程同时执行，那么，每次去执行getInstance方法时都要先获得锁再去执行方法体。如果没有锁，就要等待，耗时长，感觉像是变成了串行处理。因此，尝试其他更好的处理方式。
特点：性能不高，同步范围太大。在实例化instacne后，获取实例仍然是同步的，效率太低，需要缩小同步的范围。
- 加同步代码块，减少锁的颗粒大小。我们发现，只有第一次instance为null的时候，才去创建实例，而判断instance是否为null是读的操作，不可能存在线程安全问题。因此，我们只需要对创建实例的代码进行同步代码块的处理，也就是所谓的对可能出现线程安全的代码进行同步代码块的处理。
public class LazySigleton(){
private static final LazySigleton instatnce=null;
private LazySigleton(){}
public static LazySigleton getInstance(){
if(instatnce == null){
synchronized (LazySigleton.class){
instatnce = new LazySigleton();
}
}
return instatnce;
}
}
但是，这样处理就没有问题了吗？同样的原理，线程A和线程B，线程A读取instance值为null，此时cpu被线程B抢去了，线程B再来判断instance值为null，于是，它开始执行同步代码块中的代码，对instance进行实例化。此时，线程A获得cpu，由于线程A之前已经判断instance值为null，于是开始执行它后面的同步代码块代码。它也会去对instance进行实例化。这样就导致了还是会创建两个不一样的实例。
特点：缩小同步范围，来提高性能，但是仍然存在多次执行instance=new Singletom()的可能，由此引出double check。
那么，如何解决上面的问题。
很简单，在同步代码块中instance实例化之前进行判断，如果instance为null，才对其进行实例化。这样，就能保证instance只会实例化一次了。也就是所谓的双重检查加锁机制。
再次分析上面的场景：
线程A和线程B，线程A读取instance值为null，此时cpu被线程B抢去了，线程B再来判断instance值为null。于是，它开始执行同步代码块代码，对instance进行了实例化。这时线程A获得cpu执行权，当线程A去执行同步代码块中的代码时，它再去判断instance的值，由于线程B执行完后已经将这个共享资源instance实例化了，所以instance不再为null，所以，线程A就不会再次实行实例化代码了。
public class LazySigleton() {
private LazySigleton(){}
private static final LazySigleton instatnce=null;
public static LazySigleton getInstance(){
if(instatnce== null) {
synchronized (LazySigleton.class){
if (instatnce == null){
instatnce = new LazySigleton();
}
}
}
return l_instatnce;
}
}
但是，双重检查加锁并不表示一定没有线程安全问题了。因为，Java内存模型（JMM）并不限制处理器重排序。instatnce = new LazySigleton()并不是原子语句，其实可以分为下面的步骤：
- 申请一块内存空间；
- 在这块空间里实例化对象；
- instatnce 的引用指向这块空间地址（instatnce 指向分配的内存空间后就不为null了）。
（由此可理解，Java中new是不具有原子性的。）
指令重排序存在的问题是：
对于以上步骤，指令重排序很有可能不是按上面123步骤依次执行的。比如，先执行1申请一块内存空间，然后执行3步骤，l_instatnce的引用去指向刚刚申请的内存空间地址。那么，当它再去执行2步骤，判断l_instatnce时，由于l_instatnce已经指向了某一地址，它就不会再为null了，因此，也就不会实例化对象了。这就是所谓的指令重排序安全问题。那么，如何解决这个问题呢？
加上volatile关键字，因为volatile可以禁止指令重排序。volatile可以保证1、2、3的执行顺序，没执行完1、2就肯定不会执行3，也就是没有执行完1、2，instance一直为空。这样就可以保证3步骤（instance赋值操作）是保持最后一步完成，这样就不会出现instance在对象没有初始化时就不为null的情况了。这样也就实现了正确的单例模式了。具体代码如下：
public class LazySigleton() {
private LazySigleton(){}
private static final volatile LazySigleton instatnce=null;
public static LazySigleton getInstance(){
if(instatnce== null) {
synchronized (LazySigleton.class){
if (instatnce == null){
instatnce = new LazySigleton();
}
}
}
return instatnce;
}
}
附：静态内部类懒汉模式
public class Singleton{
private Singleton(){}
public static Singleton getInstance(){
return InstanceHolder.instance;
}
static class InstanceHolder{
private static Singleton instance=new Singleton();
}
}
静态内部类在没有显示调用的时候是不会进行加载的，当执行了
return InstanceHolder.instance后才加载初始化，这样就实现了正确的单例模式。
volatile的作用：
1.保证可见性
可以保证在多线程环境下，变量的修改可见性。每个线程都会在工作内存（类似于寄存器和高速缓存），实例对象都存放在主内存中，在每个线程要使用的时候把主内存中的内容拷贝到线程的工作内存中。使用volatile关键字修饰后的变量，保证每次修改了变量需要立即写回主内存中，同时通知所有的该对变量的缓存失效，保证缓存一致性，其他线程需要使用该共享变量时就要重新从主内存中获取最新的内容拷贝到工作内存中供处理器使用。这样就可以保证变量修改的可见性了。但volatile不能保证原子性，比如++操作。
2.提供内存屏障
volatile关键字能够通过提供内存屏障，来保证某些指令顺序处理器不能够优化重排，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。
下面是保守策略插入内存屏障：
在每个volatile写操作的前面插入一个StoreStore屏障。
在每个volatile写操作的后面插入一个StoreLoad屏障。
在每个volatile读操作的前面插入一个LoadLoad屏障。
在每个volatile读操作的后面插入一个LoadLoad屏障。
这样可以保证在volatile关键字修饰的变量的赋值和读取操作前后两边的大的顺序不会改变，在内存屏障前面的顺序可以交换，屏障后面的也可以换序，但是不能跨越内存屏障重排执行顺序。
随时随地看视频
