写在前面#
其实我也不知道想说什么，来简书已经足足15天了，每天都在通过文字总结和分享自己的所学知识，写技术文章好像也已经成了生活中的一部分了，但是，更重要的是，我要告诉你们，作为一只异地恋狗在大街上看见别的情侣秀恩爱，真的会超想她，有没有和我一样的同胞（掩面失声痛哭），如果我的心情一片黑暗，我将用学习将它照亮！
单例模式####
单例模式(Singleton pattern)是一种常用的软件设计模式。在它的核心结构中只包含一个被称为单例的特殊类。通过单例模式可以保证系统中一个类只有一个实例，要实现这一点，可以从客户端对其进行实例化开始。因此需要用一种只允许生成对象类的唯一实例的机制，“阻止”所有想要生成对象的访问。使用工厂方法来限制实例化过程。这个方法应该是静态方法（类方法），因为让类的实例去生成另一个唯一实例毫无意义。其定义是： 一个类有且仅有一个实例，并且自行实例化向整个系统提供。
在安卓中，我们很多时候只需要拥有一个全局对象，这样有利于我们协调整体的行为操作，比如ImageLoader实例，在一个应用中只应该存在一个，因为在ImageLoader中又包含了线程池、缓存系统、网络请求等等，他们是非常消耗资源的，因此，没有理由让它无限制地实例化，这种我们觉得不能随意地构造对象的情况，就是单例模式的应用场景了。
实现单例模式，有几个关键点:
- 构造函数不对外开放，一般为private。
- 确保单例类的对象有且只有一个，尤其是在多线程的环境下。
- 通过一个静态方法或者枚举返回单例对象。
- 确保单例对象在反序列化的时候不会重新构造对象。
下面我们就来进行一个简单的实例演示。正如我们知道的，在一家公司中通常只有一个CEO，CEO对于公司而言是唯一的，此处我们使用CEO为模拟示例。
public class CEO {
private static final CEO mCEO = new CEO();
private CEO() {}
public static CEO getCEO() {
return mCEO;
}
}
非常简单的代码，
CEO类不能通过new的形式构造对象，还能通过CEO.getCEO()函数来获取，而这个CEO对象又是静态（static）对象并且在声明的时候就已经初始化了，这就保证了CEO对象的唯一性。此处介绍的是单例模式的一种，叫做饿汉单例模式。
我们继续学习一下其他的各种单例模式，作者会尽量解释几种实现单例模式的区别。
-
懒汉模式#####
懒汉模式是声明一个静态对象，并且在用户第一次调用
getInstance时进行初始化，而上面所讲述的CEO类则是在声明静态对象的时候就已经完成了实例化操作。懒汉单例模式的实现方式如下：.
public class CEO {
private static CEO instance;
private CEO() {}
public static synchronized CEO getInstance() {
if (instance == null) instance = new CEO();
return instance;
}
}
善于发现的朋友又看到了，在此处的
getInstance方法中有一个关键字synchronized，对synchronized关键字不理解的同学，请跳转到深入理解java中的synchronized关键字。
关键字synchronized在此处声明getInstance为一个同步方法，也就是上面所说的在多线程情况下保证单例对象唯一性的手段。
但是此处存在一个问题，即使我们的Instance已经被初始化了（第一次调用时就会初始化），每次调用getInstance方法都会进行同步，这样会小号不必要的资源，这也是懒汉模式所存在的最大问题。那么，通过上述内容，我们对懒汉模式做一个小小的总结。
- 优点： 懒汉单例模式只有在使用时才会将类实例化，在一定程度上节约了资源。
- 缺点： 第一次加载时需要进行实例化，反应稍慢，最大的问题是每次调用getInstance方法都需要进行同步，造成不必要的同步开销。
这种方式一般不推荐使用。
-
Double Check Lock (DLC)实现单例#####
这里我们直接上示例代码
public class CEO {
private static CEO sInstance = null;
private CEO() {
}
public static synchronized CEO getInstance() {
if (sInstance == null) {
synchronized (CEO.class) {
if (sInstance == null) {
sInstance = new CEO();
}
}
}
return sInstance;
}
}
我们的关注点依然在
getInstance方法上，可以看到我们在该方法中对sInstance做了两次判断是否为空：
- 第一层判断主要为了避免不必要的同步。
- 第二层为了在null的情况下创建实例。
估计此时会有部分朋友不知道我在说什么了，没关系，我们一起来进行分析：假设线程A执行到
sInstance = new CEO();这里看到的只是简单的一行代码，但实际上会进行多条汇编指令，主要做了三件事情:
- 给CEO的实例分配内存。
- 调用CEO的构造函数，初始化成员字段。
- 将sInstance对象只想分配的内存空间中(完成此步骤时，我们的sInstance就不为null了)
以下内容可根据理解能力选择是否观看
Java编译器是允许程序乱序执行的，以及JDK1.5之前的
JMM(Java Memory Model，Java内存模型)中Cache、寄存器到主内存回写顺序规定，上面第二和第三的顺序是无法保证的，也就是说，执行顺序可能是1-3-2，也可能是1-2-3。如果是前者，并且在3执行完毕、2未执行之前，被切换到线程B上，这时候sInstance因为已经在线程A内执行过第三点，sInstance已经是非空的了，所以，线程B会直接取走sInstance，然而在实际上它并没有走完过程2，再使用时就会报错，这就是DCL失效问题。
在JDK1.5以后，SUN官方调整了JVM，具体化了volatile关键字，因此，如果是JDK1.5或者之后的版本，只需要将sInstance的声明改为private volatile static CEO sInstance = null就可以保证sInstance对象每次都是从主内存中读取的，此时，使用DCL来完成单例模式一般是不会出错的，当然，volatile关键字也会牺牲一定的程序性能，但为了程序稳定，牺牲一丁点性能，是值得的。
根据以上所述，DLC模式我们同样地进行适当总结:
- 优点
- 资源利用率高，第一次执行
getInstance时单例对象才会被实例化，效率高
- 资源利用率高，第一次执行
- 缺点
- 第一次加载时反应较慢，也由于Java内存模型原因有时候会失败。
- 在高并发场景下有一定缺陷。
- DLC模式能够在需要的时候才实例化单例对象，并且能够哎绝大多数场景下保证单例对象的唯一性，除非你的代码在高并发场景比较复杂或者低于JDK1.6的版本下使用，否则，这种方式一般能够满足需求。
-
静态内部单例模式#####
DLC模式虽然在一定程度上解决了资源消耗、多余的同步、线程安全灯问题，但是，它还是在某些情况下出现失效问题。这个问题被成为双重检查锁定（DLC）失效，在《Java并发编程与实践》一书中，指出这种“优化”是丑陋的，不赞成使用，而建议使用如下代码替代：
public class CEO {
private CEO() {}
public static synchronized CEO getInstance() {
return CEO_Holder.sInstance;
}
private static class CEO_Holder {
private static final CEO sInstance = new CEO();
}
}
当第一加载CEO类的时候并不会初始化sInstance，只有在第一次调用
getInstance方法时它才会被初始化，因此，第一次调用getInstance方法会导致虚拟机加载CEO_Holder类，这种方式不仅能够保证线程安全，还能够保证单例对象的唯一性，同时也延迟了单例的实例化，所以这是推荐使用的单例模式实现方式。
