单例模式（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单例模式中双重检查锁的问题