单例模式

一、概述

       单例模式，在设计模式中，是一个比较重要的设计模式。在开发中，如果某个实例的创建需要消耗很多资源，那么我们通常会选择使用懒性加载机制。何谓懒性加载机制呢？说白了，就是在使用到这个实例的时候，才去创建这个实例。这个机制在单例模式中，得到了很广泛的应用。这个机制在单线程的环境下实现非常简单，但是在多线程的环境下存在安全隐患。

 

二、单例模式下的懒加载机制

       我们先来看看一个通常的单例模式的实现，如下所示：

@Slf4j
public class Demo {
    private static Demo demo = new Demo();

    private Demo(){
        log.info("init demo");
    }

    public static Demo createDemo(){
        return demo;
    }
}

       这段代码的缺点显而易见，即：第一次加载类的时候会连带着创建Demo实例，这样的结果与我们所期望的不同，因为创建实例的时候可能并不是我们需要这个实例的时候。同时如果这个Demo实例的创建非常消耗系统资源，而应用始终都没有使用Demo实例，那么创建Demo消耗的系统资源就被白白浪费了。

       为了解决这个问题，我们采用懒加载机制，示例如下：

@Slf4j
public class Demo {
    private static Demo demo = null;

    private Demo(){
        log.info("init demo");
    }

    public static Demo createDemo(){
        if (demo == null) {
            demo = new Demo();
        }
        return demo;
    }
}

       在单线程的环境下，上面的示例利用懒加载机制实现单例模式，是一个很好的方式。

       如果在多线程的环境下，这种懒性加载的方式会不会出现问题呢？我们可以分析一下，根据上面示例中的懒性加载的实现，假设有两个线程A和B，同时执行了该方法，按下面的顺序执行：

• A进入if条件判断，此时demo为null，因此A进入if内执行；
• B进入if条件判断，此时A还没有创建demo，因此demo也为null，因此B也可以进入if内执行；
• A创建了Demo实例并返回；
• B创建了Demo实例并返回。

       执行到此处，我们就得等等了，说好的单例模式呢，怎么创建了两个实例？这明显不是我们所期待的结果。因此，我们必须解决这个问题。

 

三、不同解决方案及存在的问题

3.1 使用Class锁机制

      Java中Class锁机制有很多种，针对上面的问题，最直观的解决方案是给createDemo方法加上一个synchronized关键字，这样每次只允许一个线程访问createDemo方法，如下所示：

public static synchronized Demo createDemo(){
        if (demo == null) {
            demo = new Demo();
        }
        return demo;
}

      这种方案的确可以防止错误的出现，但是它却很影响性能。即，每次调用getInstance方法的时候都必须获得Demo的锁，而实际上，当单例实例被创建以后，其后的请求没有必要再使用互斥机制了。

 

3.2 Double Check Locking方案

      在一次阅读这一块相关代码的时候，有幸看到过这种方案，当时觉得这种方案可以解决3.1方案中存在的问题。但是，从JVM的角度考虑，这个方案也是存在很大问题的。我们先来看看这种方案的具体实现，如下所示：

public static synchronized Demo createDemo(){
     if (demo == null) {
         synchronized (demo){
             if (demo == null) {
                 demo = new Demo();
             }
          }
     }
     return demo;
}

       这段代码的实现过程如下：首先当一个线程发出请求后，会先检查demo是否为null，如果不是则直接返回其内容，这样避免了进入synchronized块所需要花费的资源。其次，两个线程同时进入了第一个if判断，那么他们也必须按照顺序执行synchronized块中的代码，第一个进入代码块的线程会创建一个新的Demo实例，而后续的线程则因为无法通过if判断，而不会创建多余的实例。

      这种方案似乎已经解决了我们面临的所有问题，但实际上，从JVM的角度讲，这些代码仍然可能发生错误。对于JVM而言，它执行的是一个个Java指令。在Java指令中创建对象和赋值操作是分开进行的，也就是说

demo=new Demo();

语句是分两步执行的。但是JVM并不保证这两个操作的先后顺序，也就是说有可能JVM会为新的Demo实例分配空间，然后直接赋值给demo成员，然后再去初始化这个Demo实例。这样就使出错成为了可能，我们仍然以A，B两个线程为例，假如执行A和B的执行顺序如下所示：

• A，B线程同时进入了第一个if判断；
• A首先进入synchronized块，由于demo为null，所以它执行demo=new Demo()；
• 由于JVM内部的优化机制，JVM先画出了一些分配给Demo实例的空白内存，并赋值给demo成员（注意此时JVM没有开始初始化这个实例），然后A离开了synchronized块；
• B进入synchronized块，由于demo此时不是null，因此它马上离开了synchronized块并将结果返回给调用该方法的程序；
• 此时B线程打算使用Demo实例，却发现它没有被初始化，于是错误发生了。

3.3 内部类实现多线程环境中的单例模式

       为了实现慢加载，并且不希望每次调用createDemo时都必须互斥执行，最好并且最方便的解决办法如下：

@Slf4j
public class Demo {
    private Demo(){
        log.info("init demo");
    }

    private static class DemoContainer{
        private static Demo demo = new Demo();
    }
    public static synchronized Demo createDemo(){
        return DemoContainer.demo;
    }
}

       JVM内部的机制能够保证当一个类被加载的时候，这个类的加载过程是线程互斥的。这样当我们第一次调用createDemo的时候，JVM能够帮我们保证demo只被创建一次，并且会保证把赋值给demo的内存初始化完毕。这样我们就不用担心3.2中的问题。此外该方法也只会在第一次调用的时候使用互斥机制，这样就解决了3.1中的低效问题。最后demo是在第一次加载DemoContainer类时被创建的，而DemoContainer类则在调用createDemo方法的时候才会被加载，因此也实现了惰性加载。

 

四、总结

        3.3中的方案，是小弟在学习的过程中总结出来的，当然，解决问题的方案不止一种，有兴趣的朋友，可以想想。