Java单例模式分析

最新推荐文章于 2023-07-08 14:02:34 发布

宸明

最新推荐文章于 2023-07-08 14:02:34 发布

阅读量228

点赞数

分类专栏：技术学习源码研究文章标签： Java 单例模式 double check

本文链接：https://blog.csdn.net/W331405750/article/details/79360689

版权

技术学习同时被 2 个专栏收录

4 篇文章 0 订阅

订阅专栏

源码研究

3 篇文章 0 订阅

订阅专栏

一、问题引出

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

（1）对于频繁使用的对象实例，可以省略创建对象实例所花费的时间，这对于那些重量级的对象而言，是一笔非常可观的系统开销。

（2）由于new操作的次数减少，可以减轻GC压力，缩短GC停顿时间。

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

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

二、单例模式实现与分析

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()方法中，判断当前单例是否已经存在，若存在则返回，不存在再建立单例。

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构造完成之前就是用了这个实例，程序就会出现错误了！

5、最终实现

（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保证的线程安全

6、破坏代理模式

对象的创建方式有如下四中方式：（1）new （2）克隆（3）序列化（4）反射在上面实现的方式中，由于构造函数是private的，因此第一种方式无法破坏目前我们实现的单例模式。那么是否还有可以通过其他的三种方式创建对象呢，但其他三种方式会不会破坏单例模式：

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

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

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

序列化一是可以实现数据的持久化；二是可以对象数据的远程传输。如果过该类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

宸明

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
Java单例模式分析

一、问题引出单例模式是设计模式中使用比较普遍的模式之一，它是一种对象创建模式，用于产生一个对象的实例，并能确保系统中一个类只产生一个实例，这样可以带来两大好处：（1）对于频繁使用的对象实例，可以省略创建对象实例所花费的时间，这对于那些重量级的对象而言，是一笔非常可观的系统开销。（2）由于new操作的次数减少，可以减轻GC压力，缩短GC停顿时间。综上可知，对于系统关键组件和被频繁使用的对象实例，使用...
复制链接

扫一扫