双重检查锁模式导致空指针

今天遇到一个问题：莫名奇妙报了个空指针，后来发现原来单例模式在高并发下引起的：

双重检查锁模式的一般实现：

双重检查锁模式解决了单例、性能、线程安全问题，但是这种写法同样存在问题：在多线程的情况下，可能会出现空指针问题，出现问题的原因是JVM在实例化对象的时候会进行优化和指令重排序操作。

双重检查锁模式的一般实现

public class DoubleCheckLockMode {private static DoubleCheckLockMode instance;/*** 私有化构造函数*/private DoubleCheckLockMode(){}/*** 提供公开获取实例接口* @return*/public static DoubleCheckLockMode getInstance(){// 第一次判断，如果这里为空，不进入抢锁阶段，直接返回实例if (instance == null) {synchronized (DoubleCheckLockMode.class) {// 抢到锁之后再次判断是否为空if (instance == null) {instance = new DoubleCheckLockMode();}}}return instance;}
}

双重检查锁模式解决了单例、性能、线程安全问题，但是这种写法同样存在问题：在多线程的情况下，可能会出现空指针问题，出现问题的原因是JVM在实例化对象的时候会进行优化和指令重排序操作

什么是指令重排？

private SingletonObject(){// 第一步int x = 10;// 第二步int y = 30;// 第三步Object o = new Object();
}

上面的构造函数SingletonObject()，JVM 会对它进行指令重排序，所以执行顺序可能会乱掉，但是不管是那种执行顺序，JVM 最后都会保证所以实例都完成实例化。 如果构造函数中操作比较多时，为了提升效率，JVM 会在构造函数里面的属性未全部完成实例化时，就返回对象。双重检测锁出现空指针问题的原因就是出现在这里，当某个线程获取锁进行实例化时，其他线程就直接获取实例使用，由于JVM指令重排序的原因，其他线程获取的对象也许不是一个完整的对象，所以在使用实例的时候就会出现空指针异常问题。

双重检查锁模式优化

要解决双重检查锁模式带来空指针异常的问题，只需要使用volatile关键字，volatile关键字严格遵循happens-before原则，即：在读操作前，写操作必须全部完成

public class DoubleCheckLockModelVolatile {/*** 添加volatile关键字，保证在读操作前，写操作必须全部完成*/private static volatile DoubleCheckLockModelVolatile instance;/*** 私有化构造函数*/private DoubleCheckLockModelVolatile(){}/*** 提供公开获取实例接口* @return*/public static DoubleCheckLockModelVolatile getInstance(){if (instance == null) {synchronized (DoubleCheckLockModelVolatile.class) {if (instance == null) {instance = new DoubleCheckLockModelVolatile();}}}return instance;}
}

顺便复习一下设计模式：

一、设计模式

1.1 设计模式是什么？

设计模式是解决特定问题的一系列套路，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用。其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。
设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解。

1.2 为什么要使用设计模式？

项目的需求是永远在变的，为了应对这种变化，使得我们的代码能够轻易的实现解耦和拓展

1.3 设计模式类型

创建型模式

创建型模式的主要关注点是怎样创建对象，它的主要特点是将对象的创建与使用分离。这样可以降低系统的耦合度，使用者不需要关注对象的创建细节。

结构型模式

结构型模式描述如何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式，前者采用继承机制来组织接口和类，后者釆用组合或聚合来组合对象。

行为型模式

行为型模式用于描述程序在运行时复杂的流程控制，即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，它涉及算法与对象间职责的分配。它分为类行为模式和对象行为模式，前者采用继承机制来在类间分派行为，后者采用组合或聚合在对象间分配行为。

创建型模式	结构型模式	行为型模式
单例模式、抽象工厂模式、建造者模式、工厂模式、原型模式	适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式	模版方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、职责链模式(责任链模式)、访问者模式

二、面向对象设计的六大设计原则

2.1 开闭原则

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭

解读

用抽象构建框架，用实现扩展细节；
不以改动原有类的方式来实现新需求，而是应该以实现事先抽象出来的接口（或具体类继承抽象类）的方式来实现。

优点

可以在不改动原有代码的前提下给程序扩展功能，增加了程序的可扩展性；
同时也降低了程序的维护成本。

2.2 单一职责原则

一个类只允许有一个职责，即只有一个导致该类变更的原因。

解读

类职责的变化往往就是导致类变化的原因：也就是说如果一个类具有多种职责，就会有多种导致这个类变化的原因，从而导致这个类的维护变得困难；
往往在软件开发中随着需求的不断增加，可能会给原来的类添加一些本来不属于它的一些职责，从而违反了单一职责原则。如果我们发现当前类的职责不仅仅有一个，就应该将本来不属于该类真正的职责分离出去；
不仅仅是类，函数（方法）也要遵循单一职责原则，即：一个函数（方法）只做一件事情。如果发现一个函数（方法）里面有不同的任务，则需要将不同的任务以另一个函数（方法）的形式分离出去。

优点

提高代码的可读性，更实际性地更降低了程序出错的风险；
有利于bug的追踪，降低了程序的维护成本。

2.3 依赖倒置原则

依赖抽象，而不是依赖实现;
抽象不应该依赖细节；细节应该依赖抽象;
高层模块不能依赖低层模块，二者都应该依赖抽象。

解读

面向接口编程，而不是面向实现编程；
尽量不要从具体的类派生，而是以继承抽象类或实现接口来实现；
关于高层模块与低层模块的划分可以按照决策能力的高低进行划分。业务层自然就处于上层模块，逻辑层和数据层自然就归类为底层。

优点

通过抽象来搭建框架，建立类和类的关联，以减少类间的耦合性；
以抽象搭建的系统要比以具体实现搭建的系统更加稳定，扩展性更高，同时也便于维护。

里氏替换原则

子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说，子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。

2.4 接口隔离原则

多个特定的客户端接口要好于一个通用性的总接口。

解读

客户端不应该依赖它不需要实现的接口；
不建立庞大臃肿的接口，应尽量细化接口，接口中的方法应该尽量少。

注意：接口的粒度也不能太小。如果过小，则会造成接口数量过多，使设计复杂化。

优点

避免同一个接口里面包含不同类职责的方法，接口责任划分更加明确，符合高内聚低耦合的思想。

2.5 迪米特法则（最少知道原则）

一个对象应该对尽可能少的对象有接触，也就是只接触那些真正需要接触的对象。

解读

一个类应该只和它的成员变量，方法的输入，返回参数中的类作交流，而不应该引入其他的类（间接交流）。

优点

可以良好地降低类与类之间的耦合，减少类与类之间的关联程度，让类与类之间的协作更加直接。

2.6 组合聚合复用原则

所有引用基类的地方必须能透明地使用其子类的对象，也就是说子类对象可以替换其父类对象，而程序执行效果不变。

-解读

在继承体系中，子类中可以增加自己特有的方法，也可以实现父类的抽象方法，但是不能重写父类的非抽象方法，否则该继承关系就不是一个正确的继承关系。

优点

可以检验继承使用的正确性，约束继承在使用上的泛滥。

关于设计模式更多的可以参考：

菜鸟教程：https://www.runoob.com/design-pattern/singleton-pattern.html

部分摘自：https://www.cnblogs.com/vandusty/p/11444293.html