Android 内功心法(1.1)——android常用设计模式之单例模式

上一篇：Android 内功心法(1)——设计模式的原则和android中常用的模式 中 我阐述了设计模式的几大原则，其中包括标准解释和我自己的理解。

这一篇博文就后续android内功心法，来讲一讲单例模式。
设计模式中一般最想讲解的是工厂模式，但是因为单例模式相对独立，代码简单易懂，所以这里先讲它。

我发布的博文中设计模式的讲解顺序也是我学习设计模式的顺序，其中有我排序学习的道理。

先来说明一下单例模式的优缺点和注意事项。
优点：“计划生育”，保证一个实例只出现一次。控制实例new的次数。
缺点： 单例出现在一个进程中，不同的进程之间难以控制单例。
注意事项：不同的线程控制；内存中实例是否需要优先加载；单例适合于哪些地方。

先写一种常用的单例：

public static class Instance {    private static volatile Instance instance = null;    private Instance() {    }    public synchronized static Instance getInstance() {        if (instance == null) {            synchronized (Instance.class) {                if (instance == null) {                    instance = new Instance();                }            }        }        return instance;    }}

其中，volatile的作用是： 作为指令关键字，确保本条指令不会因编译器的优化而省略，且要求每次直接读值。
简单地说就是防止编译器对代码进行优化。
举个栗子：
XBYTE[2]=0x55;
XBYTE[2]=0x56;
XBYTE[2]=0x57;
XBYTE[2]=0x58;
对外部硬件而言，上述四条语句分别表示不同的操作，会产生四种不同的动作，但是编译器却会对上述四条语句进行优化，认为只有XBYTE[2]=0x58（即忽略前三条语句，只产生一条机器代码）。
如果键入volatile，则编译器会逐一的进行编译并产生相应的机器代码（产生四条代码）。

synchronized 关键字的作用是“程序锁”。当两个线程同时进入getInstance()方法的时候，synchronized关键字会让线程逐一进入，也就是“排队”进入。synchronized关键字的作用就显而易见了，防止多线程的时候new出多个对象。

这种单例估计是程序员用到的最多的一种。它的确代码简单，结构清晰。这种单例能够胜任百分之九十的情况。而且是“懒汉式”。

说到“懒汉式”的单例，那么就不得不说“饿汉式”的单例了。
我们可以先看看代码，说说两者的区别。

 public class GetInstance {        //加载类的时候会初始化static的instance，从这以后，这个static的instance对象便一直占着这段内存，永远不会被回收掉。        private static GetInstance instance = new GetInstance();        private GetInstance() {//将构造函数private掉，避免直接new SingleTon()            super();        }        /**         * 因为是单例，所以只能通过static方法来获取实例，因此必须是static的。         * 方法实现较为简单，因为instance已经在加载类的时候被初始化好了，所以不存在多线程并发造成的问题         */ public static GetInstance getInstance() {            return instance;   }}

看看“懒汉式”单例和“饿汉式”单例，一目了然。“饿汉式”单例只有在你使用到该单例的时候，才会去实例化一个对象，并一直保存在内存中。
而“饿汉式”单例则是在程序一启动的时候就被加载到了内存中，是一种优先使用系统资源的方式。

那么有人就要说了，既然这样，“饿汉式”就不用了。那也不一定，“存在即合理”。不管是“饿汉式”还是“懒汉式”单例，都要根据实际情况来使用。

这就体现了单例模式的三个注意事项的第三点，单例使用在哪些地方，具体的地方对应具体的方式。甚至有些时候静态方法比单例又好使，这就要看程序员对于代码和逻辑的理解而灵活运用了。

以上两种单例是众所周知的，也是使用较广泛的，可以满足百分之九十的情况。

那么对于处女座的程序员就要问了，那么剩下的百分之十是什么情况？要怎解决？要怎么做到百分之百？

那么我就来解答一下这个问题。

剩下的百分之十的情况是什么呢？
1，序列化
2，java的反射机制
3，线程安全

以上两种单例在面多线程的时候是通过双重加锁的方式过滤的。但是面对序列化和java反射的时候就无能为力了。

举个栗子：一旦你实现了serializable接口，他们就不再是单例的了，因为readObject()方法总是返回一个 新的实例对象，就像java中的构造器一样。

所以，还有另一种写法——枚举。

public class GetInstance {    public enum GetStrInstance {        INSTANCE;        private final static String path = "data/data/android/intance";        private GetStrInstance() {        }        public boolean saveSDcardByPath(String filePath) {            File file = new File(path + filePath);            if (!file.exists()) {                try {                    file.createNewFile();                    return true;                } catch (IOException e) {                    e.printStackTrace();                    return false;                }            }            return false;        }    } }    /**     * 使用方法     */    boolean bl = GetStrInstance.INSTANCE.saveSDcardByPath("文件绝对路径");

利用枚举来完成单例。
枚举完成的单例有一下几个优点：
1，线程安全
2，自由序列化
3，即使使用反射机制也无法多次实例化一个枚举量

---

通过枚举实现单例的方式是java5之后最好的方式。目前应该以这种单例为主导。

---

这就是目前我所理解的单例模式，希望对广大开发者有所帮助。