单例模式（SingleTon）

概述

单例模式（SingleTon）属于创建型模式，确保某个类只有一个实例，是最常见的设计模式之一。如日志对象，Android系统下面的XXXManager，在java语言下单例有如下三个特点：
1. 一个虚拟机单例类只能有一个实例
2. 单例类必须自己创建自己的唯一实例
3. 单例类必须给所有其他对象提供这一实例

单例类的写法

单例类的写法主要有：饿汉式和懒汉式两种

饿汉式

//饿汉式单例类.在类加载时，已经自行实例化   public class Singleton1 {      private Singleton1() {}      private static final Singleton1 single = new Singleton1();      //静态方法       public static Singleton1 getInstance() {          return single;      }  }  

饿汉式单例在类的创建的同时，就已经创建好一个静态的对象供系统调用，以后不再改变，所以天生是线程安全的。

懒汉式

//懒汉式单例类.在第一次调用的时候实例化自己   public class Singleton {     private Singleton() {}      private static Singleton single=null;      //静态工厂方法       public static Singleton getInstance() {           if (single == null) {                 single = new Singleton();           }            return single;      }  } 

Singleton通过将构造方法限定为private 避免了类在外部被实例化，在同一个虚拟机范围内，Singleton只能通过getInstance()方法访问。
（但是java的放射机制是能够实例化构造方法为private的类的，基本上会使得java的单例失效，但此处自动忽略）。

但上述的懒汉式单例的实现是没有考虑线程安全的，要实现线程安全，有以下三种方式：

1、 在getInstance方法上加同步

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

2、双重检查锁（DCL）

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

3、 静态内部类

public class Singleton {        private static class LazyHolder {            private static final Singleton INSTANCE = new Singleton();        }        private Singleton (){}        public static Singleton getInstance() {            return LazyHolder.INSTANCE;        }    }  

上述三种方式都可以实现单例模式，但是第三种静态内部类的实现方式比前两种都好一点，因为既实现了线程安全，又避免了同步带来的性能影响

饿汉式和懒汉式的区别：

特点：饿汉是着急初始化，类一旦加载就把单例初始化完成，即getInstance时已存在
懒汉是比较懒，只有当调用getInstance的时候，才会去初始化这个单例对象
1、线程安全：饿汉式天生线程安全，可以直接用于多线程而不会出现问题
懒汉式是非线程安全的，为实现线程安全有上述3种方法，在性能上有区别
2、资源加载和性能
饿汉式在类创建的同时就实例化一个静态对象，不管之后会不会使用这个单例，都会占据一定的内存，相应的在第一次调用的时候速度会更快。
懒汉式，会延迟加载，在第一次使用该单例的时候才会实例化对象出来，第一次调用时要做初始化，如果要做的工作比较多，性能上会有些延迟，之后就和饿汉式一样了。
懒汉式的三种实现的区别：

• 在方法上加了同步，虽然线程安全，但是每次都要同步，会影响性能，毕竟99%的情况不需要同步
• 在getInstance中做了两次null检查，确保了只有第一次调用单例的时候才会做同步，这样也是线程安全的，同时避免了每次都同步的性能损耗。
• 利用了classloader的机制来保证初始instance的时候只有一个线程，所以也是线程安全的，同时没有性能损耗，这种是最佳的。

双重检查锁失效

但是在网上经常看到有文章分析双重检查锁导致单例失效的问题。

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

这里如果将volatile去除，那确实可能存在单例失效问题，主要原因是singleton = new Singleton();并不是原子操作，主要分为两步，一步是构造Singleton对象，即调用构造函数，第二步是将构建出来的实例赋给singleton变量。由于JVM重排序的问题，可能先执行赋值，后执行构造函数，这是为什么呢？因为JVM重排序只保证在单线程中的顺序一致性，即重排序不会导致单线程中的结果不一致。因此JVM是可以先初始化singleton变量，然后执行构造函数。
假设有两个线程，线程一进入同步块，并初始化了singleton变量，然后由于线程调度，线程一暂停，线程二开始执行，此时发现singleton变量不为空，则可能会调用该对象的一些方法，但该对象尚未执行构造函数体，就会导致空指针异常。

那为何volatile关键字可以解决呢？
volatile有两层语义：
1.可见性，不同线程对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这个值对其他线程来说是立即可见的
2.禁止指令重排序

这里就是利用volatile的禁止指令重排序的语义来解决，即不会先赋值后执行构造函数体。

不过针对双重检查锁失效问题，曾提出过很多不起作用的修复，其中下面这种是被用的比较多的，我也曾在很多同事写的代码中有看到过类似的写法。

class Foo {    private Helper helper = null;    public Helper getHelper() {       if (helper == null) {           Helper h;           synchronized(this) {               h = helper;               if (h == null)                    synchronized (this) {                       h = new Helper();                   } // release inner synchronization lock               helper = h;           }       }          return helper;    }}

将创建Helper对象的代码放到了一个内部的同步块中。直觉的想法是，在退出同步块的时候应该有一个内存屏障，这会阻止Helper的初始化与helper字段赋值之间的重排序。

很不幸，这种直觉完全错了。同步的规则不是这样的。monitorexit（即，退出同步块）的规则是，在monitorexit前面的action必须在该monitor释放之前执行。但是，并没有哪里有规定说monitorexit后面的action不可以在monitor释放之前执行。因此，编译器将赋值操作helper = h;挪到同步块里面是非常合情合理的。调整之后如下：

class Foo {    private Helper helper = null;    public Helper getHelper() {       if (helper == null) {           Helper h;           synchronized(this) {               h = helper;               if (h == null)                    synchronized (this) {                       helper = new Helper();                   } // release inner synchronization lock           }       }          return helper;    }}

参考：

有关“双重检查锁定失效”的说明
Java并发编程：volatile关键字解析
Java单例模式中双重检查锁的问题