单例模式 java 双重锁_单例模式之双重校验锁的优缺点

单例设计双重校验锁这种方式采用双锁机制，安全且在多线程情况下能保持高性能。但其中也有优缺点

双重校验锁代码

public class DoubleLock {

private static DoubleLock doubleLock;

private DoubleLock(){

}

public static DoubleLock getInstance(){

if (doubleLock == null){

synchronized (DoubleLock.class){

if (doubleLock == null){

doubleLock = new DoubleLock();

}

}

}

return doubleLock;

}

}

优点

安全且在多线程情况下能保持高性能，第一个if判断避免了其他无用线程竞争锁来造成性能浪费，第二个if判断能拦截除第一个获得对象锁线程以外的线程。

如果不加第二次判空，我们考虑下线程A，线程B都阻塞在了获取锁的步骤上，其中A获得锁---实例化了对象----释放锁，之后B---获得锁---实例化对象，此时违反了我们单例模式的初衷。

问题

双重检查锁定背后的理论是完美的。不幸地是，现实完全不同。双重检查锁定的问题是：并不能保证它会在单处理器或多处理器计算机上顺利运行。

双重检查锁定失败的问题并不归咎于 JVM 中的实现 bug，而是归咎于 Java 平台内存模型。内存模型允许所谓的“无序写入”，这也是这些习语失败的一个主要原因。

singleton = new Singleton();

该语句非原子操作，实际是三个步骤。1.给 Singleton 分配内存；

2.调用 Singleton 的构造函数来初始化成员变量；

3.将给 singleton 对象指向分配的内存空间(此时 singleton 才不为 null )；

虚拟机的指令重排序–>

执行命令时虚拟机可能会对以上3个步骤交换位置 最后可能是132这种 分配内存并修改指针后未初始化 多线程获取时可能会出现问题。

当线程A进入同步方法执行singleton = new Singleton();代码时，恰好这三个步骤重排序后为1 3 2，

那么步骤3执行后 singleton 已经不为 null ,但是未执行步骤2，singleton对象初始化不完全，此时线程B执行 getInstance() 方法，第一步判断时 singleton 不为null,则直接将未完全初始化的singleton对象返回了。

解决

如果一个字段被声明成volatile，Java线程内存模型确保所有线程看到这个变量的值是一致的，同时还会禁止指令重排序

所以使用volatile关键字会禁止指令重排序,可以避免这种问题。使用volatile关键字后使得 singleton = new Singleton();语句一定会按照上面拆分的步骤123来执行。

另一个问题

单例模式并不是绝对安全的，可以通过反射来破坏，只有枚举安全类是安全的。