单例设计模式

作者: 愤怒的奶牛 | 来源:发表于2019-12-04 23:15 被阅读0次

1. 基本概念

java 进程内存中只有一个对象实例。

实现的基本原则：

构造器私有化，不允许外部创建对象。

提供public static 的访问点，返回创建的对象。

应用场景：

spring ioc 容器默认单例。
全局配置对象，全局一份
框架封装，结合其他设计模式一起使用。

2. 实现方式

1. 饿汉式
1. 懒汉式

双重检查锁
静态内部类

3.ThreadLocal
1. 枚举
1. CSA 原子类
1. 注册式单例

3. 破坏单例的方式

1. 暴力反射
1. 序列化和反序列化

4.代码实现

上面我们简单的总结了一下有关单例模式的相关知识点，接下来我们就来用代码实现一下常见单例的几种写法。以及如何保证单例的线程安全。

4.1 饿汉式

public class HungarySingleton {

    //类加载时进行初始化
    private static final  HungarySingleton instance = new HungarySingleton();
    
    // 构造器初始化
    private HungarySingleton() {}

    // 全局访问点
    public static HungarySingleton getInstance() {
        return instance;
    }
}

优点：饿汉式在类加载时就初始对象，并且只初始化一次，所以是线程安全的。
缺点：这种写法是强引用，在JVM 里面永远不会被回收。同时在jvm 启动时也会消耗一定的资源，不管是否使用，都已经创建了，存在资源的浪费，如果在jvm 里面饿汉式单例太多了，就很浪费资源了，并且被创建的对象也无法被垃圾回收。后面我们会讲懒加载，这里我们首先来测试一下单例破坏的反射和序列化。

反射破坏：

 /**
     * 反射破坏
     * @throws Exception
     */
    public static void test2() throws Exception {
        //得到默认构造器
        Constructor<HungarySingleton> declaredConstructor = HungarySingleton.class.getDeclaredConstructor();
        //强制访问
        declaredConstructor.setAccessible(true);
        // 创建对象
        HungarySingleton hungarySingleton = declaredConstructor.newInstance();
        System.out.println(hungarySingleton);
        HungarySingleton instance = HungarySingleton.getInstance();
        System.out.println(instance);
    }

测试结果

com.example.designpattern.singleton.HungarySingleton@7440e464
com.example.designpattern.singleton.HungarySingleton@49476842

Process finished with exit code 0

从上面的测试结果看出来，饿汉式创建的单例可以被发射破坏。为了解决这个问题我们可以在构造器那里做一下手脚：因为是反射调用构造器，所以我们可以在构造器中判断一下，如果对象已经存在了就抛出异常，防止再创建一次对象。

修改构造器：

public class HungarySingleton {

    //类加载时进行初始化
    private static final  HungarySingleton instance = new HungarySingleton();

    // 构造器初始化
    private HungarySingleton() {
        if (instance!=null) {//判断对象是否已经被创建
            throw new RuntimeException("请不要重复创建对象");
        }
    }

    // 全局访问点
    public static HungarySingleton getInstance() {
        return instance;
    }
}

测试结果：

Exception in thread "main" java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
    at com.example.designpattern.singleton.HungarySingleton.test2(HungarySingleton.java:62)
    at com.example.designpattern.singleton.HungarySingleton.main(HungarySingleton.java:48)
Caused by: java.lang.RuntimeException: 请不要重复创建对象
    at com.example.designpattern.singleton.HungarySingleton.<init>(HungarySingleton.java:22)
    ... 6 more

Process finished with exit code 1

从上面的测试结果我们可以看出，反射是可以破坏单例的，当然针对饿汉式单例的反射破坏我们也可以有一些措施。接下来我们来看看序列化和反序列化是如何破坏单例的。

序列化和反序列化破坏单例

/**
     * 序列化和反序列化破坏单例
     * */
    public static void test3() throws IOException, ClassNotFoundException {

        //将对象写到磁盘
        HungarySingleton hungarySingleton = HungarySingleton.getInstance();
        ObjectOutputStream outputStream = new ObjectOutputStream(new FileOutputStream("hungarySingleton.obj"));
        outputStream.writeObject(hungarySingleton);

        System.out.println(hungarySingleton);

        //然后再将对象从磁盘读取出来
        ObjectInputStream inputStream = new ObjectInputStream(new FileInputStream("hungarySingleton.obj"));
        HungarySingleton object = (HungarySingleton)inputStream.readObject();

        System.out.println(object);
    }

测试结果

饿汉式=com.example.designpattern.singleton.HungarySingleton@5451c3a8
序列化和反序列化=com.example.designpattern.singleton.HungarySingleton@3d494fbf

上述测试结果表明序列化和反序列化也能够对单例造成破坏，可以阅读源码找到原因。注意这里我是实现了 Serializable 接口的。

应对策略

不要实现 Serializable 接口。序列化和反序列化要求必须实现 Serializable 接口，所以为了防止序列化和反序列化对单例的破坏，可以不要实现 Serializable 接口。
如果业务要求必须要实现Serializable 接口，那么就只有下面这一种方式可以应对：重写 readResolve() 方法。

   /**
     * 防止序列化和反序列化对单例的破坏，返回单例对象
     * @return
     */
    public Object readResolve() {
        return instance;
    }

上面这个返回会在 HungarySingleton object = (HungarySingleton)inputStream.readObject(); 这句话执行的时候回调，直接就返回你自己返回的对象，所以可以应对对单例的破坏。具体的可以看看 jdk 的源码，不能够找到答案。上面我们实现了饿汉式单例，并且分析了饿汉式单例的优缺点，以及反射和序列化，反序列化对单例的破坏。以及相应的应对策略。下面的内容我们就只针对单例的一些实现展开谈论，对单例的破坏就不做分析了，可以自己去测试。

4.2 懒加载

双重检查锁

在double check 之前我们先来看看为什么会出现 double check 这种写法。

最简单的懒加载：

public class SimpleSingleton {

    //1.静态成员
    private static SimpleSingleton instance;

    //2. 构函数私有化
    private SimpleSingleton() {}

    //3. 提供全局访问方法
    public static SimpleSingleton getInstance() {

        if (instance == null) {
            instance = new SimpleSingleton();
        }
        return instance;
    }
}

单线程测试：

 //单线程测试
    public static void test() {
        SimpleSingleton instance = SimpleSingleton.getInstance();
        SimpleSingleton instance2 = SimpleSingleton.getInstance();
        SimpleSingleton instance3 = SimpleSingleton.getInstance();
        System.out.println(instance);
        System.out.println(instance2);
        System.out.println(instance3);
    }

com.example.designpattern.singleton.SimpleSingleton@7440e464
com.example.designpattern.singleton.SimpleSingleton@7440e464
com.example.designpattern.singleton.SimpleSingleton@7440e464

从上面的单线程测试中没有发现问题，接下来进行多线程测试，这里我们就使用简单的多线程测试，也可以并发测试。

多线程测试

//多线程测试
    public static void test2() {
        for (int i=0 ;i<3; i++) {
            new Thread(()->{
                try {
                    TimeUnit.SECONDS.sleep(2);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                SimpleSingleton instance = SimpleSingleton.getInstance();
                System.out.println(instance);
            }).start();
        }
    }

com.example.designpattern.singleton.SimpleSingleton@21279f82
com.example.designpattern.singleton.SimpleSingleton@25f209f5
com.example.designpattern.singleton.SimpleSingleton@6e154e44

这里我们看到直接就产生了3个不同的对象，显然违背单例的设计思想。针对线程安全问题，我们可以使用锁来解决这个问题。于是就有了下面几种线程安全的写法。

静态同步方法和同步代码块

// 静态方法上面 加 synchronized  关键字
public static synchronized SimpleSingleton getInstance() {

        if (instance == null) {
            instance = new SimpleSingleton();
        }
        return instance;
    }

// 同步代码块
public static  SimpleSingleton getInstance() {
        synchronized(SimpleSingleton.class) {//这里的锁 一般这样写，但也可以是 静态对象 作为锁
            if (instance == null) {
                instance = new SimpleSingleton();
            }
            return instance;
        }
        
    }

上面的两种写法效果完全一样，效率也一样，锁的范围也一样，都是类锁。至于为什么是类级别的锁，不是对象级别的，有下面几个原因：
1.静态方法本身是可以使用类直接调用，也就在类级别，在静态方法上面加锁的化自然也就是类级别的锁了；
2 . 静态方法里面的同步代码块为啥是类级别的锁。注意这里因为我用的 SimpleSingleton.class 作为锁，所以说上面的两种写法是等效的。一般使用 SimpleSingleton.class作为锁是避免创建其他锁对象，这里是不能使用 this 作为锁的，这也是因为有 static 关键字的原因。
3 . 在这里能不能使用对象锁呢？答案是可以的，但是必须是 static 对象如：

// 创建一个对象作为锁
    final static Object object = new Object();
    public static  SimpleSingleton getInstance() {
        synchronized(object) {// 使用对象锁
            if (instance == null) {
                instance = new SimpleSingleton();
            }
            return instance;
        }

    }
//显然这样的写法没有 SimpleSingleton.class 作为锁简单，
//因为你自己又单独 创建了一个 Object 对象，而且还是 饿汉式创建的。

分析完了上面的锁的问题，我们再来分析一下这种写法的优缺点，是否值得我们平时的项目中使用：
1 .优点：synchronized 关键字保证了线程安全，同时也是懒加载的。
2 .缺点：从上面的代码中我们可以看到我们的锁都是全局锁，也就是说每一个线程来访问我们的方法的时候被要先去获得锁，方法执行完了以后再去释放锁。我们知道，单例对象只在第一次访问的时候创建就ok 了，也就是下面这个逻辑只在第一次访问该方法的时候 instance == null ,然后创建对象。如果在线程安全的情况下后续的线程的 instance 都是不为空的，就不会去创建对象了，也就保证了线程安全了，那么我们对整个方法都加上锁就很低效了。

   if (instance == null) {// 第一次访问的时候 满足
            instance = new SimpleSingleton();
        }

上面我们分析出静态同步方法和同步代码块虽然能够保证线程安全，但是也带来可一些性能问题，那么我们就优化一下性能就ok 了。既然instance 只有在第一次访问的时候是 null 那么我们就在 if 里面来加一个锁也就是在第一次创建的时候保证线程安全就ok了，后面的线程都不会进入 if ，所以就有了下面的优化方案：

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

测试：

public static void test2() {
        for (int i=0 ;i<3; i++) {
            new Thread(()->{
                try {
                    TimeUnit.SECONDS.sleep(2);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                SimpleSingleton instance = SimpleSingleton.getInstance();
                System.out.println(instance);
            }).start();
        }
    }

com.example.designpattern.singleton.SimpleSingleton@6e154e44
com.example.designpattern.singleton.SimpleSingleton@2fd04fd1
com.example.designpattern.singleton.SimpleSingleton@21279f82

测试结果我们发现，我擦，怎么会呢？不是加了锁了吗？？我们仔细来分析一下为啥会是这样的：

public static  SimpleSingleton getInstance() {
            if (instance == null) {// 1. 当第一次 到这里的就只有一个 线程 1 ，那么这个是线程安全的；2 . 当线程 1 和线程 2 同时到 这里了，不管是线程1 和线程 2 谁获得了锁 都会是 执行 创建对象的 语句，也就有了多个对象。
                synchronized (SimpleSingleton.class) {
                    instance = new SimpleSingleton();
                }
            }
            return instance;
    }

针对上面的问题我们自然就有了下面的写法，也就是我们在同步代码块里面再判断一次，就可以保证线程安全了，也就有了双重检查锁的写法：

public static  SimpleSingleton getInstance() {
            if (instance == null) {// 当线程1 和线程2 都执行到了这里，假设线程 1 获取了锁
                synchronized (SimpleSingleton.class) {
                    if (instance == null) {
                        instance = new SimpleSingleton();// 线程1 创建了 对象，执行完毕 退出 同步代码块，释放锁，这时候 线程 2 获取了锁，然后 读取了 instance 的值 发现 不为空 ，第二个 if 条件就不满足了，不会执行 对象创建的语句。
                    }
                }
            }
            return instance;
    }

到这里我们就把为啥会出现 double check 的过程分析了一下，但是上面的写法都还不是线程安全的，因为 instance = new SimpleSingleton(); 在jvm 创建对象的指令中不是原子的，也就说 jvm 创建对象至少有下面几条指令：1. 申请一块内存空间； 2. 创建一个对象；3. 将地址值赋值个变量；在并发量高的情况下，可能会发生可见性问题和指令重排序问题，

https://www.cnblogs.com/goodAndyxublog/p/11356402.html

为了解决这个问题我们可以使用 volatile 来修饰 instance。下面我们来看看完整的 double check 是怎么写的。

public class DoubleCheckSingleton {
// volatile  保证可见性，防止指令重排序
   private static volatile DoubleCheckSingleton singleton;
    public static DoubleCheckSingleton doubleCheckSingleton() {
        if (singleton == null) {
            synchronized (DoubleCheckSingleton.class) {
                if (singleton == null ) {//为了防止 两个线程都进了 第一个if导致的线程安全问题，所以可以再加一次判断
                    singleton = new DoubleCheckSingleton();
                }
            }
        }
        return singleton;
    }
}

上面我们分析了double check ，一切看上去都很完美，但是就是有一点，使用了线程同步机制，来保证线程的安全性，那么有没有一种不使用线程同步机制也可以实现线程安全和懒加载呢？答案是肯定的，那就是静态内部类。另外，在这里我们没有分析反射，序列化和反序列化对单例的破坏。答案是这两种都是可以破坏 double check 的单例，可以自己测试一下。接下来我们来分析一下静态内部类的单例。

4.2静态内部类

public class InnerStaticSingleton {

    private InnerStaticSingleton() {}

    //但外部调用 SingletonHolder.innerStaticSingleton 时才会加载这里的静态内部类
     private static class SingletonHolder{
        private final static InnerStaticSingleton innerStaticSingleton = new InnerStaticSingleton();

     }

     public static InnerStaticSingleton getInstance() {
        return SingletonHolder.innerStaticSingleton;
     }
}

上面是静态内部类的实现方式，这里我解释一下，为什么是懒加载的。在外部类加载到jvm 时，静态内部类是不会被加载的，也就不会执行 private final static InnerStaticSingleton innerStaticSingleton = new InnerStaticSingleton(); 只有当外部类的 static 方法被调用时，才会加载内部类，并实例化对象。静态在整个 jvm 运行周期中都只加载一次，所以是可以保证单例的，根据前面的分析，只有在调用时才会去初始化对象，所以是懒加载的。至于线程安全，也是利用jvm 内部机制保证的，到底是如何保证的，由于笔者水平有限，暂无法解释，希望大家留言谈论。该方式通常被认为是最优的单例实现方式，但是也有一个缺点，就是参数传递的问题。所以到底要使用哪一种实现方式，是取决于实际应用场景的。虽然该方式优雅，但是同样可以被反射和序列化破坏。那么到底有没有一种单例是能够防止反射和序列化的破坏，答案是肯定的，那就是枚举式单例，终极杀招。

4.3枚举式单例

public enum EnumSingleton {

    INSTANCE;
}

这就是枚举式单例，是不是非常简单。下面我们来测试一下反射和序列化得破坏结果，看看是否能达到我们的预期。

反射破坏

public static void test() throws Exception{
        Constructor<EnumSingleton> declaredConstructor = EnumSingleton.class.getDeclaredConstructor();
        declaredConstructor.setAccessible(true);
        EnumSingleton enumSingleton = declaredConstructor.newInstance();
        System.out.println(enumSingleton);
    }

测试结果

Exception in thread "main" java.lang.NoSuchMethodException: com.example.designpattern.singleton.EnumSingleton.<init>()
at java.lang.Class.getConstructor0(Class.java:3082)
at java.lang.Class.getDeclaredConstructor(Class.java:2178)
at com.example.designpattern.singleton.EnumSingleton.test(EnumSingleton.java:23)
at com.example.designpattern.singleton.EnumSingleton.main(EnumSingleton.java:18)

上面是反射的测试结果，直接给我们异常了，说没有默认构造器，后面我们会分析一下底层的原来，看看枚举单例到底是怎么回事。这里我们再来测试一下序列化。

序列化测试

public static void test2() throws Exception{
        ObjectOutputStream outputStream = new ObjectOutputStream(new FileOutputStream("EnumSingleton.obj"));
        EnumSingleton instance = EnumSingleton.INSTANCE;
        System.out.println(instance);
        outputStream.writeObject(instance);
        ObjectInputStream objectInputStream = new ObjectInputStream(new FileInputStream("EnumSingleton.obj"));

        EnumSingleton enumSingleton =(EnumSingleton)objectInputStream.readObject();
        System.out.println(enumSingleton);
    }

测试结果：

INSTANCE
INSTANCE

结果返回了同一个对象，说明jdk 也为我们屏蔽了序列化对单例的影响。到这来是不是觉得很牛叉，枚举都帮我们做了，首先是线程安全的，其次反射和序列化也不能破坏它，但是是不是懒加载的呢？肯定不是，因为枚举也是在jvm 加载的时候就会初始化的。在 Effective java 那本书里面，作者就推荐使用枚举式单例。当然到底使用哪一种，我们还是要根据业务场景来选择。好了，既然枚举这么牛掰，我们能不能看看jvm 在加载枚举的时候，到时是怎么做到的？接下来我们就来看看枚举的神秘面纱。首先，从代码层面看不出啥东西，那么，我们就要想办法看看他编译后的样子。

反编辑工具 jad

反编译 EnumSingleton.class

jad EnumSingleton.class 。会生成一个 EnumSingleton.jad 的文件。

// Decompiled by Jad v1.5.8g. Copyright 2001 Pavel Kouznetsov.
// Jad home page: http://www.kpdus.com/jad.html
// Decompiler options: packimports(3) 
// Source File Name:   EnumSingleton.java

package com.example.designpattern.singleton;

import java.io.*;
import java.lang.reflect.Constructor;

public final class EnumSingleton extends Enum
{
    public static final EnumSingleton INSTANCE;
    private static final EnumSingleton $VALUES[];
// 构造器，私有化，没有无参构造器，所以我们在测试的时候 会抛出异常，说没有无参构造器。
 private EnumSingleton(String s, int i)
     {
            super(s, i);
     }
// 静态代码块初始化对象，饿汉式写法，是线程安全的。
    static
    {
        INSTANCE = new EnumSingleton("INSTANCE", 0);
        $VALUES = (new EnumSingleton[] {
            INSTANCE
        });
    }
    public static EnumSingleton[] values()
    {
        return (EnumSingleton[])$VALUES.clone();
    }
    public static EnumSingleton valueOf(String name)
    {
        return (EnumSingleton)Enum.valueOf(com/example/designpattern/singleton/EnumSingleton, name);
    }
}

上面是 EnumSingleton.class 反编译的结果。我们看到 EnumSingleton 枚举继承的 Enum 对象，该对象是 jdk 自带的java.lang下面的抽象类

public abstract class Enum<E extends Enum<E>>
        implements Comparable<E>, Serializable {
 protected Enum(String name, int ordinal) {//只有这一个构造函数
        this.name = name;
        this.ordinal = ordinal;
    }
}

上面解释了我们在反射调用无参构造函数的时候，为啥会有异常抛出，那是因为枚举本身就没有无参构造函数。好了，到这里可能你又发现了，虽然没有无参构造函数，但是有两个带参数的构造函数，我们能不能调用呢？我们来测试一下就知道了。

public static void test() throws Exception{
        Constructor<EnumSingleton> declaredConstructor = EnumSingleton.class.getDeclaredConstructor(String.class,int.class); //得到带有参数的构造函数
        declaredConstructor.setAccessible(true);
        EnumSingleton enumSingleton = declaredConstructor.newInstance("测试",007);// 调用，创建对象
        System.out.println(enumSingleton);
    }

测试结果：

Exception in thread "main" java.lang.IllegalArgumentException: Cannot reflectively create enum objects
at java.lang.reflect.Constructor.newInstance(Constructor.java:417)
at com.example.designpattern.singleton.EnumSingleton.test(EnumSingleton.java:25)
at com.example.designpattern.singleton.EnumSingleton.main(EnumSingleton.java:18)

上面结果说，不能通过反射来创建枚举对象。他说在 java.lang.reflect.Constructor.newInstance(Constructor.java:417) 417行抛出的异常。我们就去看一下：

Constructor

@CallerSensitive
    public T newInstance(Object ... initargs)
        throws InstantiationException, IllegalAccessException,
               IllegalArgumentException, InvocationTargetException
    {
        if (!override) {
            if (!Reflection.quickCheckMemberAccess(clazz, modifiers)) {
                Class<?> caller = Reflection.getCallerClass();
                checkAccess(caller, clazz, null, modifiers);
            }
        }
        if ((clazz.getModifiers() & Modifier.ENUM) != 0)// 这里的意思是 枚举的话 就 抛出异常。
            throw new IllegalArgumentException("Cannot reflectively create enum objects");
        ConstructorAccessor ca = constructorAccessor;   // read volatile
        if (ca == null) {
            ca = acquireConstructorAccessor();
        }
        @SuppressWarnings("unchecked")
        T inst = (T) ca.newInstance(initargs);
        return inst;
    }

好了，上面我们就解释了，为啥枚举能够防止反射破坏单例，原来是jdk 帮我们做了这个事情了。我们还有一个序列化破坏没有找到原因。接下来我们就来看看序列化的原因，由于篇幅太长，可能已经忘记了序列化测试代码，我们再来贴一下：

public static void test2() throws Exception{
        ObjectOutputStream outputStream = new ObjectOutputStream(new FileOutputStream("EnumSingleton.obj"));
        EnumSingleton instance = EnumSingleton.INSTANCE;
        System.out.println(instance);
        outputStream.writeObject(instance);
        ObjectInputStream objectInputStream = new ObjectInputStream(new FileInputStream("EnumSingleton.obj"));

        EnumSingleton enumSingleton =(EnumSingleton)objectInputStream.readObject();
        System.out.println(enumSingleton);
    }

上面代码就两个意思，1 . 把对象写到磁盘；2 . 从磁盘读出来对象。既然读的时候得到的是一个对象，那么我们就直观的先从读开始，看看能不能找到答案，如果不能，我们再去分析写。

EnumSingleton enumSingleton =(EnumSingleton)objectInputStream.readObject();

看看 readObject()里面

public final Object readObject()
        throws IOException, ClassNotFoundException
    {
        if (enableOverride) {// 这里是false 
            return readObjectOverride();
        }

        // if nested read, passHandle contains handle of enclosing object
        int outerHandle = passHandle;
        try {
            Object obj = readObject0(false); //那么 对象就是从这里出来的，我们进去看看
            handles.markDependency(outerHandle, passHandle);
            ClassNotFoundException ex = handles.lookupException(passHandle);
            if (ex != null) {
                throw ex;
            }
            if (depth == 0) {
                vlist.doCallbacks();
            }
            return obj;
        } finally {
            passHandle = outerHandle;
            if (closed && depth == 0) {
                clear();
            }
        }
}

----- enableOverride 我们使用的这个构造器
 public ObjectInputStream(InputStream in) throws IOException {
        verifySubclass();
        bin = new BlockDataInputStream(in);
        handles = new HandleTable(10);
        vlist = new ValidationList();
        serialFilter = ObjectInputFilter.Config.getSerialFilter();
        enableOverride = false; // false
        readStreamHeader();
        bin.setBlockDataMode(true);
    }


------ Object obj = readObject0(false);
private Object readObject0(boolean unshared) throws IOException {
        boolean oldMode = bin.getBlockDataMode();
        if (oldMode) {
            int remain = bin.currentBlockRemaining();
            if (remain > 0) {
                throw new OptionalDataException(remain);
            } else if (defaultDataEnd) {
                /*
                 * Fix for 4360508: stream is currently at the end of a field
                 * value block written via default serialization; since there
                 * is no terminating TC_ENDBLOCKDATA tag, simulate
                 * end-of-custom-data behavior explicitly.
                 */
                throw new OptionalDataException(true);
            }
            bin.setBlockDataMode(false);
        }

        byte tc;
        while ((tc = bin.peekByte()) == TC_RESET) {
            bin.readByte();
            handleReset();
        }

        depth++;
        totalObjectRefs++;
        try {
            switch (tc) {
                case TC_NULL:
                    return readNull();

                case TC_REFERENCE:
                    return readHandle(unshared);

                case TC_CLASS:
                    return readClass(unshared);

                case TC_CLASSDESC:
                case TC_PROXYCLASSDESC:
                    return readClassDesc(unshared);

                case TC_STRING:
                case TC_LONGSTRING:
                    return checkResolve(readString(unshared));

                case TC_ARRAY:
                    return checkResolve(readArray(unshared));

                case TC_ENUM: // 前面的 啥逻辑 我们也看不太懂，但是这里可以看到是和枚举相关的 ，那么我们 去看看 readEnum(unshared)
                    return checkResolve(readEnum(unshared));

                case TC_OBJECT:
                    return checkResolve(readOrdinaryObject(unshared));

                case TC_EXCEPTION:
                    IOException ex = readFatalException();
                    throw new WriteAbortedException("writing aborted", ex);

                case TC_BLOCKDATA:
                case TC_BLOCKDATALONG:
                    if (oldMode) {
                        bin.setBlockDataMode(true);
                        bin.peek();             // force header read
                        throw new OptionalDataException(
                            bin.currentBlockRemaining());
                    } else {
                        throw new StreamCorruptedException(
                            "unexpected block data");
                    }

                case TC_ENDBLOCKDATA:
                    if (oldMode) {
                        throw new OptionalDataException(true);
                    } else {
                        throw new StreamCorruptedException(
                            "unexpected end of block data");
                    }

                default:
                    throw new StreamCorruptedException(
                        String.format("invalid type code: %02X", tc));
            }
        } finally {
            depth--;
            bin.setBlockDataMode(oldMode);
        }
    }


------ readEnum(unshared)

private Enum<?> readEnum(boolean unshared) throws IOException {
        if (bin.readByte() != TC_ENUM) {
            throw new InternalError();
        }

        ObjectStreamClass desc = readClassDesc(false);// 这里就是得到对象的 描述 ObjectStreamClass 对象，
        if (!desc.isEnum()) {// 判断是否是枚举
            throw new InvalidClassException("non-enum class: " + desc);
        }

        int enumHandle = handles.assign(unshared ? unsharedMarker : null);
        ClassNotFoundException resolveEx = desc.getResolveException();
        if (resolveEx != null) {
            handles.markException(enumHandle, resolveEx);
        }

        String name = readString(false);
        Enum<?> result = null;
        Class<?> cl = desc.forClass();
        if (cl != null) {
            try {
                @SuppressWarnings("unchecked")
                Enum<?> en = Enum.valueOf((Class)cl, name); // 得到 Enum 对象，我们知道 枚举 是继承 Enum 的，这里也是 返回的 Enum 。通过 枚举 class 对象 和 name 就得到 了一个唯一的对象，这个name 就是 我们通常自己定义的 枚举的对象的name。我们可以继续 下去，看看 Enum.valueOf((Class)cl, name); 里面是啥
                result = en;
            } catch (IllegalArgumentException ex) {
                throw (IOException) new InvalidObjectException(
                    "enum constant " + name + " does not exist in " +
                    cl).initCause(ex);
            }
            if (!unshared) {
                handles.setObject(enumHandle, result);
            }
        }

        handles.finish(enumHandle);
        passHandle = enumHandle;
        return result;

----- name 枚举对象的name
System.out.println(EnumSingleton.INSTANCE.name()); // INSTANCE

----- Enum.valueOf((Class)cl, name); 
Enum :
 public static <T extends Enum<T>> T valueOf(Class<T> enumType,
                                                String name) {
        T result = enumType.enumConstantDirectory().get(name); // 是从这里取取来的。
        if (result != null)
            return result;
        if (name == null)
            throw new NullPointerException("Name is null");
        throw new IllegalArgumentException(
            "No enum constant " + enumType.getCanonicalName() + "." + name);
    }


-----------  T result = enumType.enumConstantDirectory().get(name); 
Class<T> enumType：
 Map<String, T> enumConstantDirectory() {
        if (enumConstantDirectory == null) {
            T[] universe = getEnumConstantsShared();
            if (universe == null)
                throw new IllegalArgumentException(
                    getName() + " is not an enum type");
            Map<String, T> m = new HashMap<>(2 * universe.length);
            for (T constant : universe)
                m.put(((Enum<?>)constant).name(), constant); // 保存 枚举对象
            enumConstantDirectory = m;
        }
        return enumConstantDirectory;
    }
// 该map 不能被序列化
private volatile transient Map<String, T> enumConstantDirectory = null;
// 到这里我们也就看到了 原来 他还是一个 map 集合，map 里面就保存了枚举对象,在被调用的时候，就判断一下，如果是空，就存储枚举对象，然后返回，然后通过name 取获取，每次都是获取到的一个 对象，这个也叫做 注册式单例，spring 就是典型的注册式单例。

上面我们分析了为啥反序列化得时候，得到的也是相同的枚举对象，就是要因为 jvm 自己讲枚举对象存在了一个map 集合里面，然后每次都是去 map 里面取，对象也就只创建了一次，后面都是读出来的自然也就是单例了，这也就注册式单例。到这里我们就分析完了，枚举能够防止反射和序列化破坏的原因了。

4.4 ThreadLocal 单例

上面枚举单例里面提及到了注册式单例，现在我们来看看另外一种注册式单例--ThreadLocal 单例。

ThreadLocalSingleton

public class ThreadLocalSingleton {

    private ThreadLocalSingleton () {}

    private static final ThreadLocal<ThreadLocalSingleton> threadLocal  = new ThreadLocal<ThreadLocalSingleton>() {
        @Override
        protected ThreadLocalSingleton initialValue() {//初始化值
            return new ThreadLocalSingleton();
        }
    };
    public static ThreadLocalSingleton getInstance() {
        return threadLocal.get();
    }
}

ThreadLocal 本身的特点是变量和线程存在绑定的映射关系，我们先来看测试结果，就明白是啥意思了。为了方便理解ThreadLocal 的特点，我们使用线程池来测试。

线程池测试

 public static void test() throws InterruptedException {
// 创建有5个线程的线程池
        ExecutorService executorService = Executors.newFixedThreadPool(5);
        CountDownLatch countDownLatch = new CountDownLatch(5);
        for (int i = 0 ;i<10; i++) {// 开启10 个线程，有线程池去处理。
            executorService.submit(()->{
                countDownLatch.countDown();
                try {
                    TimeUnit.SECONDS.sleep(3);
                } catch (InterruptedException e) {

                    e.printStackTrace();
                }

                ThreadLocalSingleton instance = ThreadLocalSingleton.getInstance();
                System.out.println(Thread.currentThread().getName() + "___" + instance);
            });
        }
        countDownLatch.await();
    }

测试结果

pool-1-thread-5___com.example.designpattern.singleton.ThreadLocalSingleton@6c1553f
pool-1-thread-1___com.example.designpattern.singleton.ThreadLocalSingleton@6f08d27f
pool-1-thread-5___com.example.designpattern.singleton.ThreadLocalSingleton@6c1553f
pool-1-thread-3___com.example.designpattern.singleton.ThreadLocalSingleton@3f46008f
pool-1-thread-2___com.example.designpattern.singleton.ThreadLocalSingleton@d85fdfa
pool-1-thread-4___com.example.designpattern.singleton.ThreadLocalSingleton@447a380d
pool-1-thread-5___com.example.designpattern.singleton.ThreadLocalSingleton@6c1553f
pool-1-thread-3___com.example.designpattern.singleton.ThreadLocalSingleton@3f46008f
pool-1-thread-1___com.example.designpattern.singleton.ThreadLocalSingleton@6f08d27f
pool-1-thread-2___com.example.designpattern.singleton.ThreadLocalSingleton@d85fdfa


/**
 * 注册式单例
 */
public class RegisterSingleton {

    private static Map<String,RegisterSingleton> map = new ConcurrentHashMap<>(1);

    private RegisterSingleton() {}
    private static volatile RegisterSingleton instance;
    public static RegisterSingleton getInstance() {
        instance = map.get("instance");
       if (null == instance) {
           synchronized (RegisterSingleton.class) {
               instance = map.get("instance");
               if (null == instance) {
                   instance = new RegisterSingleton();
                   map.put("instance",instance);
               }
           }
       }
       return instance;
    }

    public static void main(String[] args) {
        for (int i=0;i<100; i++) {
            new Thread(()->{
                RegisterSingleton instance = RegisterSingleton.getInstance();
                System.out.println(instance);
            }).start();
        }
    }
}

我们观察相同线程获取到的对象是一样的，这个就是ThreadLocal 本身的特点，也就说同一个线程获取到的对象始终是一个，对单个线程来说这也就是单例了。但是对于不同的线程来说是获取到不同的对象。这个和ThreadLocal 本身的数据结构有关系。我们可以去看一看jdk 的源码，这里我们就不展开了，内部是维护了一个 ThreadLocalMap 静态内部来存储当前线程的值，所以每个线程都有一个ThreadLocalMap 对象与之对应，获取到值也只自己线程的。到此，我们可以总结出一个结论：注册式单例就是对象创建一次，然后存放到 Map 中，后面去Map 里面直接获取就ok。

上面我们说了注册式单例和 ThreadLocal 的单例，注册式单例的实现方式有很多种，但是唯一不变的就是底层的数据结构一定是 Map 的，然后保证在访问Map 的时候是线程安全的就行。最后介绍一种CAS实现的单例。

CAS 单例--原子引用类

public class CASSingleton {

    private CASSingleton() {
    }

    private final static AtomicReference<CASSingleton> atomicReference = new AtomicReference<>();

    public static CASSingleton getInstance() {

        for (; ; ) {//自旋
            CASSingleton casSingleton = atomicReference.get();
            if (casSingleton != null) {
                return casSingleton;
            }
            casSingleton = new CASSingleton();
            // CSA 操作：如果当前的值是 null，就更新 为 casSingleton
            boolean compareAndSet = atomicReference.compareAndSet(null, casSingleton);
            if (compareAndSet) {
                return casSingleton;
            }
        }
    }

测试：

 public static void main(String[] args) {
        for (int i = 0; i < 5; i++) {
            new Thread(() -> {
                try {
                    TimeUnit.SECONDS.sleep(3);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                CASSingleton instance = CASSingleton.getInstance();
                System.out.println(Thread.currentThread().getName() + ":" + instance);
            }).start();
        }
        CASSingleton instance = CASSingleton.getInstance();
        CASSingleton instance2 = CASSingleton.getInstance();
        CASSingleton instance3 = CASSingleton.getInstance();
        CASSingleton instance4 = CASSingleton.getInstance();

        System.out.println(instance);
        System.out.println(instance2);
        System.out.println(instance3);
        System.out.println(instance4);
    }

com.example.designpattern.singleton.CASSingleton@52cc8049
com.example.designpattern.singleton.CASSingleton@52cc8049
com.example.designpattern.singleton.CASSingleton@52cc8049
com.example.designpattern.singleton.CASSingleton@52cc8049
Thread-1:com.example.designpattern.singleton.CASSingleton@52cc8049
Thread-0:com.example.designpattern.singleton.CASSingleton@52cc8049
Thread-3:com.example.designpattern.singleton.CASSingleton@52cc8049
Thread-2:com.example.designpattern.singleton.CASSingleton@52cc8049
Thread-4:com.example.designpattern.singleton.CASSingleton@52cc8049

有关CAS 相关知识如果不熟悉的话，可以去学习一下并发编程相关的知识。

总结一下：
到此就介绍了单例的常见的实现方式：double check ，静态内部类，枚举，饿汉式，ThreadLocal，CAS 单例，注册式单例，当然肯定还有其他的变种写法，但是根本的原则不会改变-- JVM 中整个生命周期中只存在一个对象实例。同时，也分析了单例被破坏的情况，反射和序列化。当然项目中不会故意去破坏，但是无意的破坏是可能的，比如反射破坏。好了，这就是笔者对单例模式的理解，如果不足之处，欢迎留言讨论！

单例设计模式

1. 基本概念

2. 实现方式

3. 破坏单例的方式

4.代码实现

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

设计模式