单例模式
单例模式是设计模式中最常见也最简单的一种设计模式，保证了在程序中只有一个实例存在并且能全局的访问到。比如在Android实际APP 开发中用到的 账号信息对象管理， 数据库对象（SQLiteOpenHelper）等都会用到单例模式
一、作用
单例模式（Singleton）：保证一个类仅有一个实例，并提供一个访问它的全局访问点
结构是简单的，但是却存在一下情况；
1.每次从getInstance()都能返回一个且唯一的一个对象。
2.资源共享情况下，getInstance()必须适应多线程并发访问。
3.提高访问性能。
4.懒加载（Lazy Load），在需要的时候才被构造。
二、适用场景
1. 应用中某个实例对象需要频繁的被访问。
2. 应用中每次启动只会存在一个实例。如账号系统，数据库系统。
三、常用的使用方式
（1）懒汉式
这是在开发中很容易就能写出来的一种方式，如下
public class Singleton {
/*持有私有静态实例，防止被引用，此处赋值为null，目的是实现延迟加载*/
private static Singleton instance =null;
/*私有构造方法，防止被实例化*/
private Singleton() {
}
/* 1:懒汉式，静态工程方法，创建实例*/
public static Singleton getInstance(){
if (instance == null) { // line 12
instance = newSingleton(); // line 13
}
return instance;
}
}
调用：
Singleton.getInstance().method();
优点：延迟加载（需要的时候才去加载）
缺点： 线程不安全，在多线程中很容易出现不同步的情况，如在数据库对象进行的频繁读写操作时。两个线程并发调用Singleton.getInstance()，假设线程一先判断完instance是否为null，既代码中的line 12进入到line 13的位置。刚刚判断完毕后，JVM将CPU资源切换给线程二，由于线程一还没执行line 13，所以instance仍然是空的，因此线程二执行了new Signleton()操作。片刻之后，线程一被重新唤醒，它执行的仍然是new Signleton()操作。所以这种设计的单例模式不能满足第2点需求。
（2）加同步锁
既然线程不安全，那就加上同步锁，一种加法如下：
/*2.懒汉式变种，解决线程安全问题**/
public static synchronized SingletongetInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
比起(1)仅仅在方法中多了一个synchronized修饰符，现在可以保证不会出线程问题了。但是这里有个很大（至少耗时比例上很大）的性能问题。除了第一次调用时是执行了SingletonKerriganB的构造函数之外，以后的每一次调用都是直接返回instance对象。返回对象这个操作耗时是很小的，绝大部分的耗时都用在synchronized修饰符的同步准备上，因此从性能上说很不划算。
更一般的写法是这样
/*加上synchronized，但是每次调用实例时都会加载**/
public static Singleton getInstance(){
synchronized (Singleton.class) {
if (instance == null) {
instance = newSingleton();
}
}
return instance;
}
调用：
Singleton.getInstance().method();
优点：解决了线程不安全的问题。
缺点：效率有点低，每次调用实例都要判断同步锁
补充：在Android源码中使用的该单例方法有：InputMethodManager，AccessibilityManager等都是使用这种单例模式
（3）双重检验锁
要优化（2）中因为每次调用实例都要判断同步锁的问题，很多人都使用下面的一种双重判断校验的办法
/*3.双重锁定:只在第一次初始化的时候加上同步锁*/
public static Singleton getInstance(){
if (instance == null) {
synchronized (Singleton.class){
if (instance == null) {
instance = newSingleton();
}
}
}
return instance;
}
这种方法貌似很完美的解决了上述效率的问题，它或许在并发量不多，安全性不太高的情况能完美运行，但是，这种方法也有不幸的地方。问题就是出现在这句
instance = new Singleton();
在JVM编译的过程中会出现指令重排的优化过程，这就会导致当 instance实际上还没初始化，就可能被分配了内存空间，也就是说会出现 instance !=null 但是又没初始化的情况，这样就会导致返回的 instance 不完整（可以参考：http://www.360doc.com/content/11/0810/12/1542811_139352888.shtml）。
这里看起来是一句话，但实际上它并不是一个原子操作（原子操作的意思就是这条语句要么就被执行完，要么就没有被执行过，不能出现执行了一半这种情形）。事实上高级语言里面非原子操作有很多，我们只要看看这句话被编译后在JVM执行的对应汇编代码就发现，这句话被编译成8条汇编指令，大致做了3件事情：
1.给Kerrigan的实例分配内存。
2.初始化Kerrigan的构造器
3.将instance对象指向分配的内存空间（注意到这步instance就非null了）。
但是，由于Java编译器允许处理器乱序执行（out-of-order），以及JDK1.5之前JMM（Java Memory Medel）中Cache、寄存器到主内存回写顺序的规定，上面的第二点和第三点的顺序是无法保证的，也就是说，执行顺序可能是1-2-3也可能是1-3-2，如果是后者，并且在3执行完毕、2未执行之前，被切换到线程二上，这时候instance因为已经在线程一内执行过了第三点，instance已经是非空了，所以线程二直接拿走instance，然后使用，然后顺理成章地报错，而且这种难以跟踪难以重现的错误估计调试上一星期都未必能找得出来，真是一茶几的杯具啊。
调用：
Singleton.getInstance().method();
优点：在并发量不多，安全性不高的情况下或许能很完美运行单例模式
缺点：不同平台编译过程中可能会存在严重安全隐患。
补充：在android图像开源项目Android-Universal-Image-Loader （https://github.com/nostra13/Android-Universal-Image-Loader）中使用的是这种方式。
（4）内部类的实现
内部类是一种好的实现方式，可以推荐使用一下：
public class SingletonInner {
/**
*内部类实现单例模式
*延迟加载，减少内存开销
*
* @author xuzhaohu
*
*/
private static class SingletonHolder{
private static SingletonInnerinstance = new SingletonInner();
}
/**
*私有的构造函数
*/
private SingletonInner() {
}
public static SingletonInnergetInstance() {
returnSingletonHolder.instance;
}
protected void method() {
System.out.println("SingletonInner");
}
}
调用：
SingletonInner.getInstance().method();
优点：延迟加载，线程安全（java中class加载时互斥的），也减少了内存消耗
（5）枚举的方法
这是网上很多人推荐的一种做法，但是貌似使用的不广泛，大家可以试试，
/**
* @function:单例模式枚举实现
* @author xuzhaohu
*
*/
public enum SingletonEnum {
/**
* 1.从Java1.5开始支持;
* 2.无偿提供序列化机制;
* 3.绝对防止多次实例化，即使在面对复杂的序列化或者反射攻击的时候;
*/
instance;
private String others;
SingletonEnum() {
}
public void method() {
System.out.println("SingletonEnum");
}
public String getOthers() {
return others;
}
public void setOthers(String others){
this.others = others;
}
}
调用：
SingletonEnum.instance.method();
参考链接：
http://blog.csdn.net/liguangzhenghi/article/details/8076361
http://blog.csdn.net/beyond0525/article/details/22794221
