8.java并发编程之线程安全和单例模式

线程安全单例

饿汉单例

   // 问题1：为什么加 final // 防止被继承重写父类方法 public final class Singleton implements Serializable {    // 问题3：为什么设置为私有? 是否能防止反射创建新的实例?    // 不能防止反射创建新的实例,可以防止调用构造方法创建新实例。    private Singleton() {}    // 问题4：这样初始化是否能保证单例对象创建时的线程安全?    // 能    private static final Singleton INSTANCE = new Singleton();    // 问题5：为什么提供静态方法来获取实例INSTANCE,而不是直接将 INSTANCE设置为public,说出你知道的理由    // 懒惰初始化 封装性 泛型 初始化细节处理    public static Singleton getInstance() {        return INSTANCE;   }     // 问题2：如果实现了序列化接口, 还要做什么来防止反序列化破坏单例    // 添加readResolve方法    public Object readResolve() {        return INSTANCE;   } }

ReadResolve

JAVA对象流序列化时的readObject，writeObject，readResolve是怎么被调用的_supermanL的博客

简而言之就是，当我们通过反序列化readObject()方法获取对象时会去寻找readResolve()方法，

如果readResolve方法不存在则直接返回从文件中反序列化出来的对象。

如果readResolve方法存在则按该方法的内容返回对象。

package 序列化; ​ import java.io.FileInputStream; import java.io.FileOutputStream; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.util.HashSet; import java.util.Set; ​ public class ReadResolve<T> extends  HashSet<T> { ​  public Object readResolve() {        HashSet hashSet = new HashSet();        hashSet.add("你好");        return hashSet;   } ​    public static void main(String[] args) throws Exception {        Set<String> set = new ReadResolve<String>();        set.add("1");        set.add("2");        System.out.println( "解析之前:" + set); ​        try (ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("D:\set.obj"))) {            oos.writeObject(set);       } ​        set.clear(); ​ ​        try (ObjectInputStream ois = new ObjectInputStream(new FileInputStream("D:\set.obj"))) {            set = (Set<String>) ois.readObject();       } ​        System.out.println( "反序列化以后:" + set);   } ​ } ​

解析之前:[1, 2] 反序列化以后:[你好]

package 序列化; ​ import java.io.FileInputStream; import java.io.FileOutputStream; import java.io.ObjectInputStream; import java.io.ObjectOutputStream; import java.util.HashSet; import java.util.Set; ​ public class ReadResolve<T> extends  HashSet<T> { ​   //去掉readResolve    public static void main(String[] args) throws Exception {        Set<String> set = new ReadResolve<String>();        set.add("1");        set.add("2");        System.out.println( "解析之前:" + set); ​        try (ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("D:\set.obj"))) {            oos.writeObject(set);       } ​        set.clear(); ​ ​        try (ObjectInputStream ois = new ObjectInputStream(new FileInputStream("D:\set.obj"))) {            set = (Set<String>) ois.readObject();       } ​        System.out.println( "反序列化以后:" + set);   } ​ } ​

解析之前:[1, 2] 反序列化以后:[1, 2]

懒汉单例-不安全版

package com.interview.bintest.singleton; ​ /** * 下面是DCL单例懒汉式的demo */ public class DCLSingleton { ​    /**     * 因为是单例式，所以构造方法肯定是私有化     * 无法通过new的方式来创建对象     */    private DCLSingleton(){ ​   } ​    /**     * 创建一个私有化静态成员变量，用于指向创建出来的单例     */    private static DCLSingleton dclSingleton; ​    /**     * 创建一个 公共静态 方法，提供给外部类调用     * 方法则返回单例式(方法内创建)     */    public static DCLSingleton getInstance(){        //因为是懒汉式创建，所以我们需要判断一下是否已经被创建了        //没有则创建一个，有则直接返回该实例        if(dclSingleton==null){//A            dclSingleton = new DCLSingleton();//B       }        return dclSingleton;   } }

上面的代码在遇到多线程的时候就会产生问题，当x线程到达注释A处，判断完毕，条件成立，此时JVM把cpu的资源切换给y线程。

y线程同样到达A处，因为x线程并没有创建实例，所以y执行了注释B处的代码，即完成了单例的创建。之后线程x被重新唤醒。

因为x线程已经判断完了if中的条件，并且成立，于是x线程也执行了注释B处的代码，又创建了一个单例。

这样就产生了线程不安全的问题。这样问题就来了，new出了两个instance，这还能叫单例吗？

懒汉单例-安全版

于是我们通过synchronized同步代码块来解决这个问题，代码如下

package com.interview.bintest.singleton; ​ /** * 下面是DCL单例懒汉式的demo */ public class DCLSingleton { ​    /**     * 因为是单例式，所以构造方法肯定是私有化     * 无法通过new的方式来创建对象     */    private DCLSingleton(){ ​   } ​    /**     * 创建一个私有化静态成员变量，用于指向创建出来的单例     */    private static DCLSingleton dclSingleton; ​    /**     * 创建一个 公共静态 方法，提供给外部类调用     * 方法则返回单例式(方法内创建)     */    public static DCLSingleton getInstance(){        //因为是懒汉式创建，所以我们需要判断一下是否已经被创建了        //没有则创建一个，有则直接返回该实例        synchronized (DCLSingleton.class){            if(dclSingleton==null){//A                dclSingleton = new DCLSingleton();//B           }       }        return dclSingleton;   } }

此时解决了上面的问题。但是新问题来了。

如果在方法上加上synchronized修饰符，可以保证不会出线程问题了。但是这里有个很大(至少耗时比例上很大)的性能问题。

除了第一次调用时是执行了Singleton的构造函数之外，以后的每一次调用都是直接返回instance对象。

返回对象这个操作耗时是很小的，绝大部分的耗时都用在synchronized修饰符的同步准备上，因此从性能上来说很不划算。

因为synchronized的存在，每个线程在执行注释A的判断之前都会争抢锁，并且每个线程都要锁住了才能判断是否有实例存在。这样就导致了阻塞，因为同一时间下只能有一个线程执行synchronized里的语句，其余的线程都阻塞住。

我们能不能将注释A出的if条件判断提到外面将synchronized代码块包裹住?

问题还是一样的，假设2个线程都通过了判断。

其中一个线程先获得锁进行了创建，后一个线程因为过了判断，所以获得前一个线程释放的锁，又进行一次创建。

为了解决以上的问题，我们就需要进行两次判断，即双重检查锁定。代码如下

DCL懒汉单例

DCL单例模式

public final class Singleton {        private Singleton() {       }        // 问题1：解释为什么要加 volatile ?   // 防止指令重排序        private static volatile Singleton INSTANCE = null;                    public static Singleton getInstance() {            //问题2：对比懒汉单例, 说出这样做的意义                //提高效率:除第一次创建对象之外，其它的线程在访问在第一个if中就返回了，因此不会走到同步块中。            if (INSTANCE != null) {           return INSTANCE;           }              synchronized (Singleton.class) {            // 问题3：为什么还要在这里加非空判断, 之前不是判断过了吗            // 防止第一次并发创建多个实例化需要。            if (INSTANCE != null) { // t2                return INSTANCE;           }            INSTANCE = new Singleton();                return INSTANCE;           }   } }

问题1:解释为什么要加volatile ?

除了第一次创建对象之外，其它的线程在访问在第一个if中就返回了，因此不会走到同步块中，已经完美了吗？ 如上代码段中的注释：假设线程一执行到instance = new Singleton()这句，这里看起来是一句话，但实际上其被编译后在JVM执行的对应会变代码就发现，这句话被编译成8条汇编指令，大致做了三件事情： ​ 　　1)给instance实例分配内存； ​ 　　2)初始化instance的构造器； ​ 　　3)将instance对象指向分配的内存空间(注意到这步时instance就非null了) ​ 　　如果指令按照顺序执行倒也无妨，但JVM为了优化指令，提高程序运行效率，允许指令重排序。如此，在程序真正运行时以上指令执行顺序可能是这样的： ​ 　　a)给instance实例分配内存； ​ 　　b)将instance对象指向分配的内存空间； ​ 　　c)初始化instance的构造器； ​ 　　这时候，当线程一执行b)完毕，在执行c)之前，被切换到线程二上，这时候instance判断为非空，此时线程二直接来到return instance语句，拿走instance然后使用，接着就顺理成章地报错(对象尚未初始化)。 ​ 　　具体来说就是synchronized虽然保证了线程的原子性(即synchronized块中的语句要么全部执行，要么一条也不执行)，但单条语句编译后形成的指令并不是一个原子操作(即可能该条语句的部分指令未得到执行，就被切换到另一个线程了)。

根据以上分析可知，解决这个问题的方法是：禁止指令重排序优化，即使用volatile修饰变量。

问题2:为什么要使用2次判断?

说说双重检查加锁单例模式为什么两次if判断？ 去掉内层判断：如果去掉内层if判断，就会实例化多次，这是显而易见的，这就违背了单例模式的单例二字。 ​ 去掉外层判断： 1.整个代码都加上了synchronzed,每次访问get方法都会进入同步代码块。效率太低。 ​ 2.当线程1走完了内层判断，对象实例化完成后。线程3也调用了getInstace函数，如果没有加外层的判断线程3还是要继续等待线程2的完成，而加上外层判断，就不需要等待了，直接返回了实例化的对象。 ​ 我的理解：外层的判断是为了提高效率，里层的判断就是防止第一次并发创建多个实例化需要。

静态内部类懒汉单例

内部类简单介绍

内部类分为对象级别和类级别。

类级内部类指的是，有static修饰的成员变量的内部类,静态内部类。

如果没有static修饰的成员变量的内部类被称为对象级内部类,非静态内部类。

类级内部类相当于其外部类的static成员，它的对象与外部类对象间不存在依赖关系，相互独立，因此可直接创建。

而对象级内部类的实例，是必须绑定在外部对象实例上的。

类级内部类只有在第一次被使用的时候才被会装载。

要想很简单地实现线程安全，可以采用静态初始化器的方式，它可以由JVM来保证线程的安全性，如恶汉式单例，这种实现方式，会在类装载的时候就初始化对象，有可能浪费一定的内存(假设你不需要的话)，有一种方法能够让类装载的时候不去初始化对象，就是采用类级内部类，在这个类级内部类里面去创建对象实例。

　有上面我们进行的测试可以得出结论，静态内部类和非静态内部类一样，都不会因为外部内的加载而加载(所以是懒汉)，同时静态内部类的加载不需要依附外部类，在使用时才加载，不过在加载静态内部类的过程中也会加载外部类

代码如下：

public final class Singleton { private Singleton() { }    // 问题1：属于懒汉式还是饿汉式    // 懒汉    private static class LazyHolder {   static final Singleton INSTANCE = new Singleton();   }    // 问题2：在创建时是否有并发问题    // no    public static Singleton getInstance() {   return LazyHolder.INSTANCE;   } }

Cas实现单例模式

public class Singleton {    private static final AtomicReference<Singleton> INSTANCE           = new AtomicReference<Singleton>();    private Singleton() {        System.out.println("我被初始化了");        CasSingletonTest.objectcount.getAndIncrement();   }    public static Singleton getInstance() {        for (;;) {            Singleton singleton = INSTANCE.get();            if (null != singleton) {                return singleton;           }            singleton = new Singleton();            if (INSTANCE.compareAndSet(null, singleton)) {                return singleton;           }       }   } }

这是网上一位大牛的实现，他的这种非锁 CAS 实现的单例，挺好的。但是平时可能没有人使用，比用锁稍微复杂了一点，这也是为什么没有被列入单例模式的 7 大写法之中了。我在他的基础上，也就是他的构造方法里添加了两行代码。

我主要是想看看它到底是实例化了几次。加上这两行代码，可以方便我观察控制台，和统计实例化的总次数。

然后，我的测试代码如下：

package com.xttblog.canal.test; import java.util.concurrent.CountDownLatch; import java.util.concurrent.atomic.AtomicInteger; /** * CasSingletonTest * @author www.xttblog.com * @date 2019/2/27 下午2:39 */ public class CasSingletonTest {    public static AtomicInteger objectcount = new AtomicInteger();    public static void main(String[] args) throws InterruptedException {        final CountDownLatch begin = new CountDownLatch(1);        final CountDownLatch last = new CountDownLatch(1000);        for(int i=0;i<1000;i++){            new Thread(new Runnable() {                @Override                public void run() {                    try {                        //1.所有的线程都会阻塞在这                        begin.await();                        System.out.println                           (Thread.currentThread().getName()+":begin...");                        //3.阻塞的1000个线程并发执行                        Singleton sba = Singleton.getInstance();                        System.out.println(Thread.currentThread().getName()+":OK");                        //4.释放门栓                        last.countDown();                   } catch (InterruptedException ex) {                        ex.printStackTrace();                   }               }           }).start();       }        //2.释放门栓        begin.countDown();        //5.等待1000个线程执行完毕        last.await();        System.out.println("new objects: "+objectcount.get());   } }

关于 CountDownLatch 有不会的，可以看《CountDownLatch 压测教程》一文。

我这里主要是想压测一下，非锁 CAS 单例模式是否会创建多次对象。

运行上面的 main 方法，我截图了一下最终结果。

结论：CAS 以原子方式更新内存中相应的值，从而保证了多线程环境下共享变量更新操作的同步。的确，这种方式可以保证每次调用getInstance() 方法得到的一定是同一个实例。因此，从功能实现的角度来看，这种做法达到了预期的目的。

但是，经过分析和测试，却发现这种方式有一些预期之外的弊病：可能会创建不止一个对象。

CAS 本身的操作的确是原子方式，但是包装 CAS 指令的方法并非是全程同步的，当然，在包含 CAS 指令的方法开始调用之前，参数计算过程中更不是互斥执行的！当一个线程测试 instance.get() == null 得到 true 之后，往下它就一定会调用 new Singleton()。因为，这并不是 CAS 方法的一部分，而是它的参数。在调用一个方法之前，需要先将其参数压入栈，当然，需要先计算参数表达式，因此，产生如上结果也就不难预料了。

CAS 与锁的区别在于，它是非阻塞的，也就是说，它不会去等待一个条件，而是一定会去执行，结果要么成功，要么失败。它的操作时间是可预期的。如果我们的目的是一定要成功执行 CAS，那就需要不断循环执行直至成功，同时，建立在成功预期之上大量的准备工作是值得的，但是，如果我们不希望操作一定成功，那为成功操作而做的准备工作就浪费掉了。

枚举单例

// 问题1：枚举单例是如何限制实例个数的 // 问题2：枚举单例在创建时是否有并发问题 // 问题3：枚举单例能否被反射破坏单例 // 问题4：枚举单例能否被反序列化破坏单例 // 问题5：枚举单例属于懒汉式还是饿汉式 // 问题6：枚举单例如果希望加入一些单例创建时的初始化逻辑该如何做 enum Singleton { INSTANCE; }

#