单例模式（Singleton）看了就懂
单例，故名思议，一个只能创建一个实例的类。
单例被广泛应用于Spring的bean（默认）、线程池、数据库连接池、缓存，还有其他一些无状态的类如servlet。
一个没必要多例的类实现了单例可以节约空间（显而易见），节省资源（线程、数据库连接）。
单例模式有这么多好处，那我们来实现它吧，首先想到的是创建一个对象要使用new方法，new方法调用的是类的构造函数，想要不被程序员随意的new对象可以将类的构造函数设为私有，然后再提供一个获取这个类实例的方法，所以就有了下面这个实现。
1、只能正确运行在单线程模式下的单例实现：
1 public class SingletonSingleThread { 2 3 private static SingletonSingleThread instance; 4 5 private SingletonSingleThread(){} 6 7 public static SingletonSingleThread getInstance(){ 8 if(instance == null){ 9 instance = new SingletonSingleThread(); 10 } 11 return instance; 12 } 13 }
以上代码只能保证在单线程下运行，在多线程环境下可能有多个线程在第8行时判断到instance当前是指向null，然后都去执行第9行的代码。
如果读者了解过volatile修饰变量的作用，可能想到将以上代码修改成如下形式，因为volatile可以保证线程之间变量的“可见性”，就可以保证每个线程在第8行判断的时候都是instance的最新引用了？
1 public class SingletonSingleThread { 2 3 private static volatile SingletonSingleThread instance; 4 5 private SingletonSingleThread(){} 6 7 public static SingletonSingleThread getInstance(){ 8 if(instance == null){ 9 instance = new SingletonSingleThread(); 10 } 11 return instance; 12 } 13 }
但是第8行和第9行是两行代码，并不是原子操作，完全可能出现线程A执行通过第8行校验，准备执行第9行的时候，另一个线程B来到第8行校验，也通过了校验。
实际上就算是代码中的一行指令也不是原子操作，在编译成.class文件后未必是一行字节码，就算是一行字节码，在解释执行或即时编译执行转化成机器码时也可能对应多条指令，以上结论原理不在本文介绍范围之内。
思考：java里有一个很方便的实现线程安全的synchronized修饰符，加上不就实现线程安全了吗？是的，下面这个实现就是在getInstance方法上简单加上synchronized修饰符。
2、对性能不敏感的多线程安全单例实现：
1 public class SingletonSlow { 2 3 private static SingletonSlow instance; 4 5 private SingletonSlow(){} 6 7 public synchronized static SingletonSlow getInstance(){ 8 if(instance == null){ 9 instance = new SingletonSlow(); 10 } 11 return instance; 12 } 13 }
如果程序对一个单例实现的getInstance()方法效率不敏感可以使用这种实现方式。好处就是直观，简单。坏处也显而易见，只有当SingletonSlow对象第一次被创建时是需要同步的，之后的调用synchronized都将是额外的负担。
思考：能不能只在第一次调用对象实例需要创建的时候才同步代码，其他时候不同步代码的方法呢？有的。
3、DCL单例模式（双重锁检查） 注意：这种方式只能应用于JDK1.5及以后的版本，JDK1.5解决了volatile无法实现双重锁单例的bug：
1 public class SingletonDCL { 2 3 private volatile static SingletonDCL instance; 4 5 private SingletonDCL(){} 6 7 public static SingletonDCL getInstance(){ 8 if(instance == null){ 9 synchronized(SingletonDCL.class){ 10 if(instance == null){ 11 instance = new SingletonDCL(); 12 } 13 } 14 } 15 return instance; 16 } 17 }
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、利用类加载器实现的急切加载单例：
1 public class SingletonEagerly { 2 3 private static SingletonEagerly instance = new SingletonEagerly(); 4 5 private SingletonEagerly(){} 6 7 public static SingletonEagerly getInstance(){ 8 return instance; 9 } 10 }
为什么叫急切加载单例呢，因为依赖于java的类加载机制，类被加载的时机未必是在需要使用类的对象时，也许在还不需要这个类的实例的时候类的实例就已经被初始化了，如果这个单例很耗费资源，我们肯定想采用懒加载的方式去实现他。
这种实现还有一个缺陷就是依赖于当前线程的ClassLoader()，如果类被多个ClassLoader加载（比如servlet），那就无法保证单例了。
思考：怎样避免类的实例只有在真正需要它的时候才被初始化呢？ 可以用私有静态内部类实现。
5、利用类加载器实现的懒加载单例：
1 public class SingletonLazyByClassLoader { 2 3 private SingletonLazyByClassLoader(){} 4 5 public static SingletonLazyByClassLoader getInstance(){ 6 return SingletonHolder.instance; 7 } 8 9 private static class SingletonHolder{ 10 private static final SingletonLazyByClassLoader instance= new SingletonLazyByClassLoader(); 11 } 12 }
将类的唯一实例放在内部静态类里，这样外部只要不调用getInstance方法就不会有类加载器加载去加载内部静态类，而内部静态类是私有的，所以只有第一次instance方法被调用的时候才会初始化了类的实例变量。
遗憾的是这种实现方式仍然无法避免ClassLoader不一样的问题。
如果实在对getInstance效率无要求，使用方式2实现单例最简单直观；
如果程序运行在Jdk1.5及以上的环境，又不会觉得实现麻烦，强烈推荐使用方式3实现单例，高效、可靠；
如果嫌方式3麻烦或者运行在Jdk1.5以前的版本，则根据是否对懒加载有需求使用方式5或方式4，同时要保证程序中用到的类加载器是AppClassLoader或先代加载器是AppClassLoader（并且遵循双亲委托机制），否则单例会失效。
