java 23种设计模式-----单例模式

目的：但愿对象只建立一个实例，而且提供一个全局的访问点。

原文：http://www.iteye.com/topic/575052

Singleton模式能够是很简单的，它的所有只须要一个类就能够完成（看看这章可怜的UML图）。可是若是在“对象建立的次数以及什么时候被建立”这两点上较真起来，Singleton模式能够至关的复杂，比头五种模式加起来还复杂，譬如涉及到DCL双锁检测（double checked locking）的讨论、涉及到多个类加载器（ClassLoader）协同时、涉及到跨JVM（集群、远程EJB等）时、涉及到单例对象被销毁后重建等。

目的：

但愿对象只建立一个实例，而且提供一个全局的访问点。

图6.1 单例模式的UML图

结构是简单的，可是却存在一下状况；

1.每次从getInstance()都能返回一个且惟一的一个对象。

2.资源共享状况下，getInstance()必须适应多线程并发访问。

3.提升访问性能。

4.懒加载（Lazy Load），在须要的时候才被构造。

 

首先实现1中的单例模式A：

1. public class SingletonA {    
2.    
3.    /**  
4.     * 单例对象实例  
5.     */    
6.    private static SingletonA instance = null;    
7.  
8.    public static SingletonA getInstance() {    
9.        if (instance == null) {                              //line 12    
10.            instance = new SingletonA();          //line 13    
11.        }    
12.        return instance;    
13.    }    
14. }    

这个写法咱们把四点需求从上往下检测，发现第2点的时候就出了问题，假设这样的场景：两个线程并发调用Singleton.getInstance()，假设线程一先判断完instance是否为null，既代码中的line 12进入到line 13的位置。刚刚判断完毕后，JVM将CPU资源切换给线程二，因为线程一还没执行line 13，因此instance仍然是空的，所以线程二执行了new Signleton()操做。片刻以后，线程一被从新唤醒，它执行的仍然是new Signleton()操做。因此这种设计的单例模式不能知足第2点需求。

下面咱们继续

 

实现2中单例模式B：

1. public class SingletonB {    
2.     
3.    /**  
4.     * 单例对象实例  
5.     */    
6.    private static SingletonB instance = null;    
7.     
8.    public synchronized static SingletonB getInstance() {    
9.        if (instance == null) {    
10.            instance = new SingletonB();    
11.        }    
12.        return instance;    
13.    }    
14. }    

比起单例A仅仅在方法中多了一个synchronized修饰符，如今能够保证不会出线程问题了。可是这里有个很大（至少耗时比例上很大）的性能问题。除了第一次调用时是执行了SingletonKerriganB的构造函数以外，之后的每一次调用都是直接返回instance对象。返回对象这个操做耗时是很小的，绝大部分的耗时都用在synchronized修饰符的同步准备上，所以从性能上说很不划算。

 

实现3单例模式C：

1. public class SingletonC {    
2.     
3.    /**  
4.     * 单例对象实例  
5.     */    
6.    private static SingletonKerriganD instance = null;    
7.   
8.    public static SingletonC getInstance() {    
9.        if (instance == null) {    
10.             synchronized (SingletonC.class) {    
11.                if (instance == null) {    
12.                    instance = new SingletonC();    
13.                }    
14.            }    
15.        }    
16.        return instance;    
17.    }    
18. }    

 

看起来这样已经达到了咱们的要求，除了第一次建立对象以外，其余的访问在第一个if中就返回了，所以不会走到同步块中。已经完美了吗？

咱们来看看这个场景：假设线程一执行到instance = new SingletonKerriganD()这句，这里看起来是一句话，但实际上它并非一个原子操做（原子操做的意思就是这条语句要么就被执行完，要么就没有被执行过，不能出现执行了一半这种情形）。事实上高级语言里面非原子操做有不少，咱们只要看看这句话被编译后在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，而后使用，而后瓜熟蒂落地报错，并且这种难以跟踪难以重现的错误估计调试上一星期都未必能找得出来，真是一茶几的杯具啊。

DCL的写法来实现单例是不少技术书、教科书（包括基于JDK1.4之前版本的书籍）上推荐的写法，其实是不彻底正确的。的确在一些语言（譬如C语言）上DCL是可行的，取决因而否能保证二、3步的顺序。在JDK1.5以后，官方已经注意到这种问题，所以调整了JMM、具体化了volatile关键字，所以若是JDK是1.5或以后的版本，只须要将instance的定义改为“private volatile static SingletonKerriganD instance = null;”就能够保证每次都去instance都从主内存读取，就可使用DCL的写法来完成单例模式。固然volatile或多或少也会影响到性能，最重要的是咱们还要考虑JDK1.42以及以前的版本，因此本文中单例模式写法的改进还在继续。

代码倒愈来愈复杂了，如今先来个返璞归真，根据JLS（Java Language Specification）中的规定，一个类在一个ClassLoader中只会被初始化一次，这点是JVM自己保证的，那就把初始化实例的事情扔给JVM好了.

 

实现4单例模式D:

1. public class SingletonD {    
2.    
3.    /**  
4.     * 单例对象实例  
5.     */    
6.    private static SingletonD instance = new SingletonD();    
7.    
8.    public static SingletonD getInstance() {    
9.        return instance;    
10.    }    
11. }    

 

这种写法不会出现并发问题，可是它是饿汉式的，在ClassLoader加载类后Kerrigan的实例就会第一时间被建立，饿汉式的建立方式在一些场景中将没法使用：譬如实例的建立是依赖参数或者配置文件的，在getInstance()以前必须调用某个方法设置参数给它，那样这种单例写法就没法使用了。

可带参数单例模式E:

1. public class SingletonE {    
2.     
3.    private static class SingletonHolder {    
4.        /**  
5.         * 单例对象实例  
6.         */    
7.        static final SingletonE INSTANCE = new SingletonE();    
8.    }    
9.     
10.    public static SingletonE getInstance() {    
11.        return SingletonHolder.INSTANCE;    
12.    }    
13. }    

这种写法仍然使用JVM自己机制保证了线程安全问题；因为SingletonHolder是私有的，除了getInstance()以外没有办法访问它，所以它是懒汉式的；同时读取实例的时候不会进行同步，没有性能缺陷；也不依赖JDK版本。

固然，用户以其它方式构造单例的对象，若是设计者不但愿这样的状况发生，则须要作规避措施。其它途径建立单例实例的方式有：

1.直接new单例对象

2.经过反射构造单例对象

3.经过序列化构造单例对象。

对于第一种状况，通常咱们会加入一个private或者protected的构造函数，这样系统就不会自动添加那个public的构造函数了，所以只能调用里面的static方法，没法经过new建立对象。

对于第二种状况，反射时可使用setAccessible方法来突破private的限制，咱们须要作到第一点工做的同时，还须要在在 ReflectPermission("suppressAccessChecks") 权限下使用安全管理器（SecurityManager）的checkPermission方法来限制这种突破。通常来讲，不会真的去作这些事情，都是经过应用服务器进行后台配置实现。

对于第三种状况，若是单例对象有必要实现Serializable接口（不多出现），则应当同时实现readResolve()方法来保证反序列化的时候获得原来的对象。

 

终极版单例模式F:

1. public class SingletonF implements Serializable {    
2.    
3.    private static class SingletonHolder {    
4.       /**  
5.        * 单例对象实例  
6.         */    
7.        static final SingletonF INSTANCE = new SingletonF();    
8.    }    
9.     
10.    public static SingletonF getInstance() {    
11.        return SingletonHolder.INSTANCE;    
12.    }    
13.  
14.    /**  
15.     * private的构造函数用于避免外界直接使用new来实例化对象  
16.     */    
17.    private SingletonF() {    
18.    }    
19.     
20.    /**  
21.     * readResolve方法应对单例对象被序列化时候  
22.     */    
23.    private Object readResolve() {    
24.        return getInstance();    
25.    }    
26. }    

 

二、android中源码单例模式举例

一、日历模块 

App路径:packages/providers/CalendarProvider

文件:packages/providers/CalendarProvider/src/com/android/provider/calendar/CalendarDatabaseHelper.java

单例代码：

private static CalendarDatabaseHelper sSingleton = null;      

public static synchronized CalendarDatabaseHelper getInstance(Context context) {  

    if (sSingleton == null) {  

        sSingleton = new CalendarDatabaseHelper(context);  

    }  

    return sSingleton;  

}  

能够看出，这是用到了2中的单例模式B.

 

2.Collator类

文件:libcore/luni/src/main/java/com/ibm/icu4jni/text/Callator.java

libcore/luni/src/main/java/com/ibm/icu4jni/text/RuleBasedCallator.java

单例代码：

public static Collator getInstance(Locale locale) {  

    return new RuleBasedCollator(locale);  

}  

 

RuleBasedCollator(Locale locale) {  

    m_collator_ = NativeCollation.openCollator(locale.toString());  

   }  

 

 

static native int openCollator(String locale);  

这就是上面给出的单例模式E，可带参数的单例模式

 

3.Editable类

文件:frameworks/base/core/java/android/text/Editable.java

private static Editable.Factory sInstance = new Editable.Factory();  

/** 

* Returns the standard Editable Factory. 

*/  

public static Editable.Factory getInstance() {  

    return sInstance;  

}  

可见这是单例模式D是实例应用

4.AccessibilityManager类

文件:frameworks/base/core/java/android/view/accessibility/AccessibilityManager.java

public static AccessibilityManager getInstance(Context context) {  

    synchronized (sInstanceSync) {  

    if (sInstance == null) {  

            sInstance = new AccessibilityManager(context);  

        }  

    }  

    return sInstance;  

}  

这是单例模式C的应用。

android使用单例模式的地方不少，特别是数据库建立时，就会使用到单例模式。因每种单例模式试用场景不同，因此android在不一样地方使用了不一样的单例模式实现方式。