单例模式（Singleton）看了就懂

单例，故名思议，一个只能创建一个实例的类。

单例被广泛应用于Spring的bean（默认）、线程池、数据库连接池、缓存，还有其他一些无状态的类如servlet。

一个没必要多例的类实现了单例可以节约空间（显而易见），节省资源（线程、数据库连接）。

单例模式有这么多好处，那我们来实现它吧，首先想到的是创建一个对象要使用new方法，new方法调用的是类的构造函数，想要不被程序员随意的new对象可以将类的构造函数设为私有，然后再提供一个获取这个类实例的方法，所以就有了下面这个实现。

1、只能正确运行在单线程模式下的单例实现：

public class SingletonSingleThread {

    private static SingletonSingleThread instance;
    
    private SingletonSingleThread(){}
    
    public static SingletonSingleThread getInstance(){
        if(instance == null){
            instance = new SingletonSingleThread();
        }
        return instance;
    }
}

以上代码只能保证在单线程下运行，在多线程环境下可能有多个线程在第8行时判断到instance当前是指向null，然后都去执行第9行的代码。

如果读者了解过volatile修饰变量的作用，可能想到将以上代码修改成如下形式，因为volatile可以保证线程之间变量的“可见性”，就可以保证每个线程在第8行判断的时候都是instance的最新引用了？

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

但是第8行和第9行是两行代码，并不是原子操作，完全可能出现线程A执行通过第8行校验，准备执行第9行的时候，另一个线程B来到第8行校验，也通过了校验。

实际上就算是代码中的一行指令也不是原子操作，在编译成.class文件后未必是一行字节码，就算是一行字节码，在解释执行或即时编译执行转化成机器码时也可能对应多条指令，以上结论原理不在本文介绍范围之内。

思考：java里有一个很方便的实现线程安全的synchronized修饰符，加上不就实现线程安全了吗？是的，下面这个实现就是在getInstance方法上简单加上synchronized修饰符。

2、对性能不敏感的多线程安全单例实现：

public class SingletonSlow {

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

如果程序对一个单例实现的getInstance()方法效率不敏感可以使用这种实现方式。好处就是直观，简单。坏处也显而易见，只有当SingletonSlow对象第一次被创建时是需要同步的，之后的调用synchronized都将是额外的负担。

思考：能不能只在第一次调用对象实例需要创建的时候才同步代码，其他时候不同步代码的方法呢？有的。

3、DCL单例模式（双重锁检查） 注意：这种方式只能应用于JDK1.5及以后的版本，JDK1.5解决了volatile无法实现双重锁单例的bug：

public class SingletonDCL {

    private volatile static SingletonDCL instance;

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

DCL方式虽然也用到了同步保证单例，但是它的效率要远远高于第2种实现方式。首先实例变量instance用volatile修饰，保证第8行拿到的是instance的最新引用，这行判断可以快速逃避instance已经被初始化的情况，当然这行代码还是会出现多个线程都判断为真的情况，第9行的代码保证了10-12行代码只有一个线程能执行，第10行重新判断instance引用为空的意义在于解决以下情况的发生：

　　①若线程A和B同时通过第8行代码判断，等待进入同步块依次执行，若A先执行，则B获得执行时间时instance已经被线程A初始化了。

　　②若线程A通过第8行代码判断，进入同步块开始执行11行代码未执行完时，线程B执行到第8行判断通过，这时A同步代码块执行完毕，B虽然接下来不需要等待直接进入同步块，但instance也是已经被初始化过的。

思考：这个写法看上去很难理解，我想到一个实现方式，既然是静态变量类型，直接在变量声明时赋值，或者写一个静态块初始化不就好了，静态类型的变量初始化是伴随着类加载进行的，不也是线程安全的吗？确实。

4、利用类加载器实现的急切加载单例：

public class SingletonEagerly {

    private static SingletonEagerly instance = new SingletonEagerly();
    
    private SingletonEagerly(){}
    
    public static SingletonEagerly getInstance(){
        return instance;
    }
}

为什么叫急切加载单例呢，因为依赖于java的类加载机制，类被加载的时机未必是在需要使用类的对象时，也许在还不需要这个类的实例的时候类的实例就已经被初始化了，如果这个单例很耗费资源，我们肯定想采用懒加载的方式去实现他。

这种实现还有一个缺陷就是依赖于当前线程的ClassLoader()，如果类被多个ClassLoader加载（比如servlet），那就无法保证单例了。

思考：怎样避免类的实例只有在真正需要它的时候才被初始化呢？ 可以用私有静态内部类实现。

5、利用类加载器实现的懒加载单例：

public class SingletonLazyByClassLoader {

    private SingletonLazyByClassLoader(){}
    
    public static SingletonLazyByClassLoader getInstance(){
        return SingletonHolder.instance;
    }
    
    private static class SingletonHolder{
        private static final SingletonLazyByClassLoader  instance= new SingletonLazyByClassLoader();
    }
}

将类的唯一实例放在内部静态类里，这样外部只要不调用getInstance方法就不会有类加载器加载去加载内部静态类，而内部静态类是私有的，所以只有第一次instance方法被调用的时候才会初始化了类的实例变量。

遗憾的是这种实现方式仍然无法避免ClassLoader不一样的问题。

---

如果实在对getInstance效率无要求，使用方式2实现单例最简单直观；

如果程序运行在Jdk1.5及以上的环境，又不会觉得实现麻烦，强烈推荐使用方式3实现单例，高效、可靠；

如果嫌方式3麻烦或者运行在Jdk1.5以前的版本，则根据是否对懒加载有需求使用方式5或方式4，同时要保证程序中用到的类加载器是AppClassLoader或先代加载器是AppClassLoader（并且遵循双亲委托机制），否则单例会失效。