引言
相信在实际的开发项目的过程中，很多时候有些对象的生命周期是伴随APP的全生命周期的，而且创建新的对象也消耗较大资源，那么此时我们在开发的时候就不应该让他有机会轻而易举地频繁创建。因为很明显他在内存中的实例应该是唯一的，此时单例模式就是很好的方案之一。
一、单例模式概述
单例模式（Singleton Pattern）是一个比较简单的模式，其官方定义如下：确保某一个类
只有一个实例，而且自行实例化并向整个系统提供这个实例。（Ensure a class has only one instance, and provide a global point of access to it.）同时单例模式可能是应用最广泛也是应用最多的设计模式了吧，通俗来说就是在使用这个模式的时候，整个程序系统只需要拥有一个唯一全局的对象。换言之，单例对象的类必须确保只有一个实例的存在。比如说Singlton是一个单例的话，那么在内存中第一次创建了对象之后并分配这个对象的内存地址，那么这个地址就一直属于Singleton直到其生命周期结束。
二、单例模式的优点和缺点及常见可用场景
1、单例模式的优点
单例模式从一定程度上来说可以通过复用实例来减少不必要的内存开支，特别是一个对象需要频繁地创建、销毁时，而且创建或销毁时性能又无法优化时。
当一个对象的产生需要比较多的资源时，如读取配置、产生其他依赖对象、加载图片等时，则可以通过在应用启动时直接产生一个单例对象，然后用永久驻留内存的方式来解决，从而达到减少了系统的性能开销的目的。
单例模式可以避免对资源的多重占用，例如一个写文件动作，由于只有一个实例存在内存中，避免对同一个资源文件的同时写操作。
单例模式可以在系统设置全局的访问点，优化和共享资源访问，例如可以设计一个单例类，负责所有数据表的映射处理。
省去了new操作符，降低了系统内存的使用频率，减轻GC压力。
2、单例模式的缺点
一般情况下，单例模式没有接口，扩展很困难。若想要扩展，除了修改源码基本上没有第二种方式实现。因为采用单例模式的类通常都是自己实例化的，并且提供单一实例，而接口或抽象类是不可能被实例化的，所以接口对单例模式是没有任何意义的，当然，在特殊情况下，单例模式也可实现接口、被继承等。
单例模式对测试是不利的。在并行开发环境中，如果单例模式没有完成，是不能进行测试的，没有接口也不能使用mock的方式虚拟一个对象。
单例模式与单一职责原则有冲突。一个类应该只实现一个逻辑，而不关心它是否是单例的，是不是要单例取决于环境，单例模式把“要单例”和业务逻辑融合在一个类中。
单例对象如果持有Context对象，很容易引发内存泄漏，解决对策就是传递给单例对象的Context最好传递Application Context。
3、适合使用单例模式的场景及注意事项
在一个系统中，要求一个类有且仅有一个对象，如果出现多个对象就会出现“不良反应”，可以采用单例模式，具体的场景如下：
要求生成唯一序列号的环境；
在整个项目中需要一个共享访问点或共享数据，例如一个Web页面上的计数器，可以不用把每次刷新都记录到数据库中，使用单例模式保持计数器的值，并确保是线程安全的；
创建一个对象需要消耗的资源过多，如要访问IO和数据库等资源；
需要定义大量的静态常量和静态方法（如工具类）的环境，可以采用单例模式（当然，也可以直接声明为static的方式）
首先，在高并发情况下，需要注意单例模式的线程同步问题，该单例模式在低并发的情况下尚不会出现问题，若系统压力增大，并发量增加时则可能在内存中出现多个实例，破坏了最初的预期。通常说的是线程安全。如果有一个外部的共享变量在某个方法中被修改了。这个时候才需要同步锁给锁上，避免同时多个线程调用的时候，这个共享变量被反复修改。导致数据异常，如果说单例在多线程中使用有线程安全问题，那必定是这个单例中有共享数据存在。要么这个数据允许外部修改，但修改的方法必须加上同步锁。要么这个数据只读，所以假如采用懒汉式实现单例时需要注意线程安全。
其次，需要考虑对象的复制情况。在Java中，对象默认是不可以被复制的，若实现了Cloneable接口，并实现了clone方法，则可以直接通过对象复制方式创建一个新对象，对象复制是不用调用类的构造函数，因此即使是私有的构造函数，对象仍然可以被复制。在一般情况下，类复制的情况不需要考虑，很少会出现一个单例类会主动要求被复制的情况，解决该问题的最好方法就是单例类不要实现Cloneable接口。
三、单例模式的实现形式
单例模式实现的形式有几种，但通用的思路都是：先私有化构造方法，再自己产生实例。
1、静态内部类(推荐)
静态内部类在第一次加载类的时候并不会去初始化，而是在调用getInstance方法的时候，通过静态内部类去初始化（因为在第一次调用getInstance方法的时候，虚拟机会自动加载SingletonHolder类）在保证了线程安全性的同时，也确保了对象的唯一性，还延迟了单例的实例化，节省了不必要的资源消耗。
public class Singleton{
private Singleton(){}
public static Singleton getInstance(){
return Singleton.SingletonHolder.single;
}
private static class SingletonHolder{
private final static Singleton single=new Singleton();
}
}
2、饿汉式
饿汉式是在声明一个静态对象的同时调用构造方法就进行初始化。
/**
饿汉式：先初始化对象，Single类一进内存就创建好了对象
*/
public class Singleton{
private static Singleton single=new Singleton();
private Singleton(){}
public static Singleton getInstance(){
return single;
}
}
3、懒汉式
懒汉式是先声明一个静态对象，并且仅在用户第一次调用getInstance方法时候进行初始化。
最优化的懒汉式 DLC(double check)
/**
懒汉式：对象是方法被调用时才初始化，即对象的延时加载，Single类进内存，对象还为创建，只有调用了getInstance方法之后才初始化创建
*/
public class Singleton{
private volatile static Singleton singleton;///注意:用volatile修饰的变量，线程在每次使用变量的时候，都会读取变量修改后的最的值
private Singleton(){}
public static Singleton getInstance(){
if(singleton==null){
synchronized(Singleton.class){
singleton=new Singleton();
}
}
return singleton;
}
}
构造方法需要传递参数时
private volatile static Camera2Helper singleton;///注意:用volatile修饰的变量，线程在每次使用变量的时候，都会读取变量修改后的最的值
private Camera2Helper(){}
private Camera2Helper(Activity act,AutoFitTextureView view){
activity=act;
textureView=view;
}
public static Camera2Helper getInstance(Activity act,AutoFitTextureView view){
if(singleton==null){
synchronized(Camera2Helper.class){
singleton=new Camera2Helper( act,view);
}
}
return singleton;
}
/*不宜采取以下写法*/
public static Singleton getInstance() {
if (instance == null) {
synchronized (instance) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
前面说到懒汉式存在线程安全的隐患，为什么会存在线程安全隐患呢，在Java指令中创建对象和赋值操作是分开进行的，也就是说single= new Singleton();语句是分两步执行的。但是JVM并不保证这两个操作的先后顺序，也就是说有可能JVM会为新的Singleton实例分配空间，然后直接赋值给instance成员，然后再去初始化这个Singleton实例，模拟以下现实场景来说明：
多线程并发情况下，当A、B线程同时进入了第一个if判断，然后A首先进入synchronized块，由于instance为null，所以它执行instance = new Singleton(); 而此时由于JVM内部的优化机制，JVM先划出了一些分配给Singleton实例的空白内存，并赋值给instance成员（注意此时JVM没有开始初始化这个实例），接着A离开了synchronized块。 注意此时B进入synchronized块，由于instance此时不是null，因此它马上离开了synchronized块并将结果返回给调用该方法的程序。最后B线程打算使用Singleton实例，却发现它没有被初始化，于是悲剧发生了。
4、使用容器实现管理多种单例模式
使用容器实现单例模式的核心思路，主要是将多种单例类型添加到一个统一的管理容器类中，从而管理多种类型的单例，并且在使用时可以通过统一的接口进行获取操作，形如conext.getSystemService方法。
public class SingletonManager{
private static Map<String,Object> objMap=new HashMap<String,Object>();
private SingletonManager(){}
public static void registService(String key,Object instance){
if(!objMap.containsKey(key)){
objMap.put(key,instance);
}
}
public static Object getService(String key){
return objMap.get(key);
}
}
四、单例模式在源码中的应用简单说明
在Android系统中提供了很多系统级别的服务，比如说电源管理PowerManagerService 、包管理PackageManagerService 、窗口管理WindowManagerService 、输入法管理InputMethodManagerService 、桌面管理WallpaperManagerService 、ActivityManagerService、布局映射LayoutInflater等，这些服务都是由系统在适宜的时机以单例的模式注册到系统中的，然后我们才可以通过Context的getSystemService(String name)方法获取对应的服务。由于篇幅有限后续再详细分析系统源码。
