Java单例模式机制分析

时间  2019-11-17
标签 java 模式 机制 分析 栏目 Java 繁體版
原文   原文链接

1、问题引出

单例模式是设计模式中使用比较广泛的模式之一，它是一种对象建立模式，用于产生一个对象的实例，并能确保系统中一个类只产生一个实例，这样能够带来两大好处：java

（1）对于频繁使用的对象实例，能够省略建立对象实例所花费的时间，这对于那些重量级的对象而言，是一笔很是可观的系统开销。设计模式

（2）因为new操做的次数减小，能够减轻GC压力，缩短GC停顿时间。安全

综上可知，对于系统关键组件和被频繁使用的对象实例，使用单例模式能够有效的改善系统的性能。性能优化

下面分析单例模式的几种实现方式：多线程

2、单例模式实现与分析

1. 最简单的实现

 先看代码以下：并发

package com.jason.design.singleton;

/**
 * 简单的单例模式实现，可是不是懒加载形式
 */
public class SingletonClass1 {
    private static final SingletonClass1 instance = new SingletonClass1();
    private SingletonClass1(){}
    public static SingletonClass1 getInstance(){
        return instance;
    }
}

   首先，类的构造函数写成private的，从而保证别的类不能实例化此类。其次，在类中提供一个静态的实例instance并提供静态的getInstance方法给使用者。这样，使用者就能够经过这个引用使用到这个类的实例了。函数

2. 性能优化——延迟加载（懒加载lazy loaded)

    上述单例的实现方式很简单，而且很是可靠。可是有一个问题：不管这个类是否被使用，都会建立一个instance对象。若是这个建立过程很耗时，而且这个类还并不必定会被使用，那么这个建立过程就是无用的。咱们作延迟加载优化：性能

package com.jason.design.singleton;

/**
 * 延迟加载可是非线程安全的单例模式
 */
public class SingletonClass2 {
    private static SingletonClass2 instance = null;
    private SingletonClass2(){}
    public static SingletonClass2 getInstance(){
        if (instance == null){
            instance = new SingletonClass2();
        }
        return instance;
    }
}

    首先，把instance初始化为null，确保系统启动时没有额外的负载，由于建立过程不在声明处，因此那个final的修饰必须去掉。优化

    其次，在getInstance()方法中，判断当前单例是否已经存在，若存在则返回，不存在再创建单例。spa

3. 线程安全问题

    上述代码在单线程状况下，没有什么问题，但是若是是多线程，会有线程安全问题，在并发状况下，线程可能各自拥有一个SingletonClass2的对象。

    继续对其进行优化，首先想到的是加锁，在getInstance()加上同步锁，一个线程必须等待另一个线程建立完成后才能使用这个方法，这就保证了单例的惟一性。

package com.jason.design.singleton;

/**
 * 同步获取单例方法的单例模式，这样会致使每次获取单例时都是同步方法，粒度过大
 */
public class SingletonClass3 {
    private static SingletonClass3 instance = null;
    private SingletonClass3(){}
    public static synchronized SingletonClass3 getInstance(){
        if (instance == null){
            instance = new SingletonClass3();
        }
        return instance;
    }
}

4. 性能优化

   上述代码引入了synchronized锁，并且是加在整个方法上的，这样性能可能受到影响。分析一下不难发现出现3中线程安全问题缘由是检测null的操做和建立对象的操做分离了。若是这两个操做可以原子地进行就能保证线程安全。因此，能够将同步块进行缩小粒度，首先去掉getInstance()的同步操做，而后把同步锁加载if语句上，修改以下：

package com.jason.design.singleton;
public class SingletonClass4 {

    private static SingletonClass4 instance = null;

    private SingletonClass4() {
    }

    public static SingletonClass4 getInstance() {

        synchronized (SingletonClass4.class) {
            if (instance == null) {
                instance = new SingletonClass4();
            }
        }
        return instance;
    }
}

    继续分析发现，即便缩小了同步块的粒度，每次调用getInstance()的时候仍是须要每次都调用同步块中的内容，性能问题仍是存在。此时可用到Double-check的模式，继续修改以下：

package com.jason.design.singleton;

/**
 * Double-Check模式的单例模式实现
 */
public class SingletonClass5 {
    private static SingletonClass5 instance = null;
    private SingletonClass5(){}
    private static SingletonClass5 getInstance(){
        if (instance == null) {
            synchronized (SingletonClass5.class) {
                if (instance == null) {
                    instance = new SingletonClass5();
                }
            }
        }
        return instance;
    }
}

    首先判断instance是否是为null，若是为null，加锁初始化；若是不为null，直接返回instance。可是这样就够了吗？恰好最近在阅读Dubbo源码的时候看到了这种double-check的应用：在Dubbo源码com/jason/properties/ConfigUtils.java类的时候有这样一段代码：

private static volatile Properties PROPERTIES;

public static Properties getProperties() {
    if (PROPERTIES == null) {
        synchronized (ConfigUtils.class) {
            if (PROPERTIES == null) {
                String path = System.getProperty(Constants.DUBBO_PROPERTIES_KEY);
                if (path == null || path.length() == 0) {
                    path = System.getenv(Constants.DUBBO_PROPERTIES_KEY);
                    if (path == null || path.length() == 0) {
                        path = Constants.DEFAULT_DUBBO_PROPERTIES;
                    }
                }
                PROPERTIES = ConfigUtils.loadProperties(path, false, true);
            }
        }
    }
    return PROPERTIES;
}

    对比代码能够发现，dubbo中的实现对于PROPERTIES的修饰符多了一个volatile,这个区别在哪里？

    下面来想一下，建立一个变量须要哪些步骤呢？一个是申请一块内存，调用构造方法进行初始化操做，另外一个是分配一个指针指向这块内存。这两个操做谁在前谁在后呢？JVM规范并无规定。那么就存在这么一种状况，JVM是先开辟出一块内存，而后把指针指向这块内存，最后调用构造方法进行初始化。

    下面咱们来考虑这么一种状况：线程A开始建立SingletonClass的实例，此时线程B调用了getInstance()方法，首先判断instance是否为null。按照咱们上面所说的内存模型，A已经把instance指向了那块内存，只是尚未调用构造方法，所以B检测到instance不为null，因而直接把instance返回了——问题出现了，尽管instance不为null，但它并无构造完成，就像一套房子已经给了你钥匙，但你并不能住进去，由于里面尚未收拾。此时，若是B在A将instance构造完成以前就是用了这个实例，程序就会出现错误了！

五、最终实现

（1）同步+Double-check方式：

    在JDK 5以后，Java使用了新的内存模型。volatile关键字有了明确的语义——在JDK1.5以前，volatile是个关键字，可是并无明确的规定其用途——被volatile修饰的写变量不能和以前的读写代码调整，读变量不能和以后的读写代码调整！所以，只要咱们简单的把instance加上volatile关键字就能够了。

package com.jason.design.singleton;

/**
 * Double-Check模式的单例模式实现,而且加入了volatile的，可保证安全
 */
public class SingletonClass6 {
    private static volatile SingletonClass6 instance = null;
    private SingletonClass6(){}
    private static SingletonClass6 getInstance(){
        if (instance == null) {
            synchronized (SingletonClass6.class) {
                if (instance == null) {
                    instance = new SingletonClass6();
                }
            }
        }
        return instance;
    }
}

（2）静态内部类实现方式：

然而，这只是JDK1.5以后的Java的解决方案，那以前版本呢？其实，还有另外的一种解决方案，并不会受到Java版本的影响，即：Initialization on Demand Holder（IODH），详见 http://en.wikipedia.org/wiki/Initialization_on_demand_holder_idiom

package com.jason.design.singleton;
/**
 * 静态内部类实现的单例模式
 */
public class SingletonClass7 {
    private SingletonClass7(){}
    private static class SingletonInstance{
        private static final SingletonClass7 instance = new SingletonClass7();
    }
    public SingletonClass7 getInstance(){
        return SingletonInstance.instance;
    }
}

    由于SingletonClass7没有static的属性，所以在没有被调用时并不会被初始化，知足延迟加载的优势，直到调用getInstance()的时候，会首先加载SingletonClassInstance类，这个类有一个static的SingletonClass实例，所以须要调用SingletonClass的构造方法，而后getInstance()将把这个内部类的instance返回给使用者。因为这个instance是static的，所以并不会构造屡次。

    因为SingletonClassInstance是私有静态内部类，因此不会被其余类知道，一样，static语义也要求不会有多个实例存在。而且，JSL规范定义，类的构造必须是原子性的，非并发的，所以不须要加同步块。一样，因为这个构造是并发的，因此getInstance()也并不须要加同步。

    综上：使用内部类的方式实现单例，便可以作到延迟加载，也没必要使用同步，是一种比较好的实现方式。

（3）单元素枚举实现

代码以下：

package com.jason.design.singleton;

/**
 * 枚举的方式实现单例模式
 */
public enum EnumSingleton {
    INSTANCE;
    private SingletonClass8 instance = null;

    private EnumSingleton() {
        instance = new SingletonClass8();
    }
    public SingletonClass8 getInstance(){
        return instance;
    }
}

单例使用方式：

EnumSingleton.INSTANCE.getInstance();

下面咱们来看看单例是如何被保证的： 
首先，在枚举中咱们明确了构造方法限制为私有，在咱们访问枚举实例时会执行构造方法，同时每一个枚举实例都是static final类型的，也就代表只能被实例化一次。在调用构造方法时，咱们的单例被实例化。 
也就是说，由于enum中的实例被保证只会被实例化一次，因此咱们的INSTANCE也被保证明例化一次。 
能够看到，枚举实现单例仍是比较简单的，除此以外咱们再来看一下Enum这个类的声明：

public abstract class Enum<E extends Enum<E>>
        implements Comparable<E>, Serializable
/**
 * prevent default deserialization
 */
private void readObject(ObjectInputStream in) throws IOException,
    ClassNotFoundException {
    throw new InvalidObjectException("can't deserialize enum");
}
/**
 * Throws CloneNotSupportedException.  This guarantees that enums
 * are never cloned, which is necessary to preserve their "singleton"
 * status.
 *
 * @return (never returns)
 */
protected final Object clone() throws CloneNotSupportedException {
    throw new CloneNotSupportedException();
}

综上，单元素枚举实现单例模式有以下优势：（1)、自由序列化 (2)、保证只有一个实例（即便使用反射机制也没法屡次实例化一个枚举量）(3)、JVM保证的线程安全

六、破坏代理模式

    对象的建立方式有以下四中方式：（1）new （2）克隆（3）序列化（4）反射 在上面实现的方式中，因为构造函数是private的，所以第一种方式没法破坏目前咱们实现的单例模式。那么是否还有能够经过其余的三种方式建立对象呢，但其余三种方式会不会破坏单例模式：

一、克隆可能对单例模式的破坏

    由克隆咱们能够想到原型模式，原型模式就是经过clone方法实现对象的建立的，clone方式是Object方法，每一个对象都有，那我使用一个单例模式类的对象，调用clone方法，再建立一个新的对象了，那岂不是上面说的单例模式失效了。固然答案是否认，某一个对象直接调用clone方法，会抛出异常，即并不能成功克隆一个对象。调用该方法时，必须实现一个Cloneable 接口。这也就是原型模式的实现方式。还有即若是该类实现了cloneable接口，尽管构造函数是私有的，他也能够建立一个对象。即clone方法是不会调用构造函数的，他是直接从内存中copy内存区域的。因此单例模式的类是不能够实现cloneable接口的。

二、序列化可能对单例模式的破坏

    序列化一是能够实现数据的持久化；二是能够对象数据的远程传输。 若是过该类implements Serializable，那么就会在反序列化的过程当中再创一个对象。这个问题的解决办法就是在反序列化时，指定反序化的对象实例，代码以下：

package com.jason.design.singleton;

import java.io.Serializable;

/**
 * Double-Check模式的单例模式实现,而且加入了volatile的，可保证安全，可被串行化的单例
 */
public class SingletonClass8 implements Serializable {

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

    /**
     * 在反序列化时，指定反序化的对象实例
     * @return
     */
    private Object readResolve(){
        return instance;
    }
}

3.反射可能对单例模式的破坏

    反射是能够获取类的构造函数，再加一行 setAccessible(true);就能够调用私有的构造函数，建立对象了。那么防止反射破坏Java单例模式的方法就是：当第二次调用构造函数时抛出异常。代码以下：

package com.jason.design.singleton;

/**
 * 静态内部类实现的单例模式,防止反射机制破坏单例
 */
public class SingletonClass10 {
    private static volatile boolean flag = true;
    private SingletonClass10(){
        if (flag){
            flag = false;
        }else {
            throw new RuntimeException();
        }
    }
    private static class SingletonInstance{
        private static final SingletonClass10 instance = new SingletonClass10();
    }
    public SingletonClass10 getInstance(){
        return SingletonInstance.instance;
    }
}

 

参考文献：http://www.jb51.net/article/80201.htm

http://blog.51cto.com/devbean/203501

http://blog.csdn.net/yy254117440/article/details/52305175

http://blog.csdn.net/chao_19/article/details/51112962

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程