深入分析单例模式

最新推荐文章于 2021-04-14 11:56:47 发布

Snail_JR

最新推荐文章于 2021-04-14 11:56:47 发布

阅读量408

点赞数

分类专栏： JAVA 文章标签：设计模式面试

本文链接：https://blog.csdn.net/Snail_Ren/article/details/76656058

版权

JAVA 专栏收录该内容

20 篇文章 0 订阅

订阅专栏

单例模式，是设计模式中最常见的一种设计模式，也是面试官最喜欢考察的模式。那什么是单例模式，这里我就不在赘述了，百度一大堆。

那么如何写一个好的单例模式呢？网上最经典的就是那七种单例模式。但是基本都是浅显地解释为什么要那样写单例，如何保证线程安全。但是对于单例的编写，我们不仅仅需要知道可以那样写，还应该知道为什么可以那样写，还应该知道怎么想出可以那样写的。这样我相信才会对童鞋们帮助更大。

第一层就是最简单的懒汉模式。

public class Singleton {  
    private static Singleton instance;  
    private Singleton (){}  
    public static Singleton getInstance() {  
        if (instance == null) {        ---------------------1            
            instance = new Singleton();---------------------2
        }  
        return instance;
    }  
}

这种写法是普遍都知道的入门级。这种写法的目的是延迟加载，当instance没有初始化的时候才进行初始化。但是毫无疑问，无法保证线程安全的。为什么？当然是因为现在假如有两个线程A,B。线程A执行代码1的同时，线程B执行代码2。这会出现什么问题？

实例的创建，主要分三步：

分配对象的内存空间
初始化对象，进行一下赋值操作
将实例的引用指向刚才分配的内存地址

JMM在进行实例创建的时候，只会保证intra-thread-semantics，即只保证在单线程中，不改变程序的执行结果（as-if-serial）。我们知道，为了进一步优化程序的执行，编译器或者处理器会进行指令的重排。也就说在上面的三个步骤中，2,3两个步骤可能会发生重排，可能具体执行的顺序为3,2。intra-thread-semantics只保证单线程执行正确，所以会允许这样的重排。

那么这样就带来了问题。假如进行了重排，先3再2，那么当线程B在执行了2，先给instance赋值后，然后执行3的时候，此时线程A看到instance已经被赋值了，那么就会认为对象已经创建完成，然后使用该instance。但是实际上，该instance还没完成初始化。这就造成了问题。

因为指令的重排，这种写法无法保证线程安全。那么我们从指令重排的角度来考虑怎么解决。既然是因为2,3步骤重排，那么可以用两个方法解决：1.即使发生了重排，那我们只要保证在执行期间，其他线程看不到这个重排。2.既然是因为重排导致的问题，那就禁止2,3重排好了。

解决思路一：禁止重排

重排不可见，解决方法很多。

法一

直接在方法层上加锁。

public class Singleton {  
    private static Singleton instance;  
    private Singleton (){}  
    public static synchronized Singleton getInstance() {  
        if (instance == null) {  
            instance = new Singleton();  
        }  
        return instance;  
    }  
}

这样就保证了线程安全。但是，假如getInstance的调用很频繁，每次都会去竞争锁。那就很尴尬了。因为锁的竞争是需要开销的。虽然说synchronized经过优化，在java8里开销已经比较小了，在高并发场景下吞吐相对于lock也小了。但是仍然是会有开销的。

因此机智的人们就想到了很经典的双重检查锁，来减少锁的竞争。
于是就有了这样的代码：

public class Singleton {  
    private  static Singleton singleton;  
    private Singleton (){}  
    public static Singleton getSingleton() {  
        if (singleton == null) {  
            synchronized (Singleton.class) {  
                if (singleton == null) {  
                    singleton = new Singleton();  
                }  
            }  
        }  
        return singleton;  
    }  
}

ok，这样的话，只有在还没有创建实例之前需要竞争锁去创建。但，这样的修改，线程仍然是安全的吗？大家看看先代码想一下。好吧，我知道大部分人不会想，那就直接说。

虽然上面的代码减少了锁的竞争，但却也把原来的线程安全又给搞得不安全了。仍然是实例还没有初始化结束，另一个线程就能读到。原因和上面讲的一样。不过有的童鞋会问：“你不是已经用了synchronized (Singleton.class) 吗？那这个synchronized还存在的意义是啥”？

因为（需要待求证）

那怎么办？

法二

那我们的解决方法，就是在instance上加volatile。需要在JDK5+上运行。代码如下

完整代码

public class Singleton {  
    private  volatile static Singleton singleton;  
    private Singleton (){}  
    public static Singleton getSingleton() {  
        if (singleton == null) {  
            synchronized (Singleton.class) {  
                if (singleton == null) {  
                    singleton = new Singleton();  
                }  
            }  
        }  
        return singleton;  
    }  
}

这样的话，2,3的重排序就会被禁止。

解决思路二：重排对其他线程不可见

这个思路，我们需要利用JVM的类的初始化的特性。我们知道，在初始化一个类的时候，为了防止多个线程同时对一个类做初始化，JVM会利用锁。在执行类的初始化之前呢，先获取锁，然后去初始化。那么我们做延迟加载，在类需要的时候才去初始化，就可以利用这个特性了。

不过类的初始化，是在某些场景下才会调用初始化的。比如说创建一个类的instance的时候，比如类中的静态方法被调用了，比如类中的静态方法被赋值了等等。那这里呢，我们采用静态类的形式来做。代码如下

public class Singleton {  
    private static class InstanceHolder{
        public static Instance instance = new Instance();
    }
    public static Singleton getSingleton() {  
         return InstanceHolder.instance;  
    }  
}