深入理解单例模式

最新推荐文章于 2022-05-12 00:07:32 发布

丁俏

最新推荐文章于 2022-05-12 00:07:32 发布

阅读量215

点赞数

分类专栏：设计模式文章标签： java 多线程设计模式

本文链接：https://blog.csdn.net/qq_41108091/article/details/108167758

版权

设计模式专栏收录该内容

2 篇文章 0 订阅

订阅专栏

深入理解DCL单例模式

什么是单例模式
饿汉式
懒汉式

什么是单例模式

单例模式（Singleton Pattern）属于创建型模式，它提供了一种创建对象的最佳方式。这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。
注意：

单例类只能有一个实例。
单例类必须自己创建自己的唯一实例。
单例类必须给所有其他对象提供这一实例。

关键代码：构造函数是私有的。

饿汉式

为什么叫做饿汉式呢？我先展示代码：

public class HungrySingleton {
    private static HungrySingleton instance = new HungrySingleton();
    private HungrySingleton() {
    }
    public static HungrySingleton getInstance() {
        return instance;
    }
}

结合代码分析：

一开始就在类中创建出了对象 instance
构造器私有，这样在类的外部就无法使用HungrySingleton hungrySingleton = new HungrySingleton();来创建对象，保证只有一个单例
对外提供静态方法getInstance，外部可以调用这个函数来得到对象。

现在知道为什么叫做饿汉式了吧！
优点：没有加锁，执行效率会提高。
缺点：类加载时就初始化，浪费内存。

懒汉式

懒汉式顾名思义就是“懒”，思想是：一开始就在类中定义出了对象 instance，需要的时候再创建

懒汉式1

public class LazySingleton1 {
    private static LazySingleton1 instance;
    private LazySingleton1(){

    }
    public static LazySingleton1 getInstance() {
    	//业务代码省略
        if (instance == null) {
            try {
                Thread.sleep(1);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            instance = new LazySingleton1();
        }
        return instance;
    }

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

先来看看结果：
在这里插入图片描述

显然不止创建了一个实例，原因分析如下：
第一个线程进入的时候，判断instance==null，在它还没来得及new出对象时，第二个线程进来了，此时instance仍然为null，它也去new对象了，所以不能保证单例，不支持多线程。

懒汉式2

既然上述懒汉式不支持多线程，那我们就加synchronized关键字，不就轻松解决问题了，先看代码：

public class LazySingleton2 {
    private static LazySingleton2 instance;
    private LazySingleton2(){

    }
    public static synchronized LazySingleton2 getInstance() {
    	//业务代码省略
        if (instance == null) {
            try {
                Thread.sleep(1);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            instance = new LazySingleton2();
        }
        return instance;
    }
    public static void main(String[] args) {
        for (int i = 0; i < 100; i++) {
            new Thread(()->{
                System.out.println(getInstance().hashCode());
            }).start();
        }
    }
}

结果：
在这里插入图片描述这种懒汉式在多线程下可以保证只有一个实例对象，但有的人认为锁的粒度太大了，getInstance()方法中的一些逻辑代码是不需要上锁的，这种方式印象影响了效率，于是有了懒汉式3。

懒汉式3

public class LazySingleton3 {
    private static LazySingleton3 instance;

    private LazySingleton3() {

    }
    public static LazySingleton3 getInstance() {
        //业务代码省略
        if (instance == null) {
            //妄图通过减小同步代码块的方法提高效率，然而不行
            synchronized (LazySingleton3.class) {
                try {
                    Thread.sleep(1);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                instance = new LazySingleton3();
            }
        }
        return instance;
    }
    public static void main(String[] args) {
        for (int i = 0; i < 100; i++) {
            new Thread(() -> {
                System.out.println(getInstance().hashCode());
            }).start();
        }
    }
}

看起来似乎没问题，来看运行结果：
在这里插入图片描述分析原因：
第一个线程进入的时候，判断instance==null成立，在它还未来得及执行synchronized代码块内容的时候，第二个线程来了，判断instance为空，然后申请锁，执行synchronized代码块内容，new出了对象，释放锁，这时第一个线程得到了锁，又new了一次。

懒汉式4

上述方式问题就在于，第一个线程在判断instance为空到得到锁的过程中，其他线程已经new出来了对象，而第一个线程还以为instance为空。于是有了著名的DCL（Double Checked Lock 双重检测锁）单例模式，在拿到锁之后再判断instance是否为空，保证线程安全性。

public class LazySingleton4 {
    private static LazySingleton4 instance;

    private LazySingleton4() {

    }
    public static LazySingleton4 getInstance() {
        //业务代码省略
        if (instance == null) {
            //双重检查
            synchronized (LazySingleton4.class) {
                if (instance == null) {
                    try {
                        Thread.sleep(1);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    instance = new LazySingleton4();
                }
            }
        }
        return instance;
    }
    public static void main(String[] args) {
        for (int i = 0; i < 100; i++) {
            new Thread(() -> {
                System.out.println(getInstance().hashCode());
            }).start();
        }
    }
}

“看起来”非常完美：既减少了阻塞，又避免了竞态条件。不错，但实际上仍然存在一个问题——当instance不为null时，仍可能指向一个"被部分初始化的对象"。

instance = new LazySingleton4();

这句代码并不是一个原子操作，它可以抽象为下面几条JVM指令：

memory = allocate();	//1：分配对象的内存空间
initInstance(memory);	//2：初始化对象
instance = memory;		//3：设置instance指向刚分配的内存地址

上面操作2依赖于操作1，但是操作3并不依赖于操作2，所以JVM可以以“优化”为目的对它们进行重排序，经过重排序后如下：

memory = allocate();	//1：分配对象的内存空间
instance = memory;		//3：设置instance指向刚分配的内存地址（此时对象还未初始化）
ctorInstance(memory);	//2：初始化对象

可以看到指令重排之后，操作 3 排在了操作 2 之前，即引用instance指向内存memory时，这段崭新的内存还没有初始化——即，引用instance指向了一个"被部分初始化的对象"。此时，如果另一个线程调用getInstance方法，由于instance已经指向了一块内存空间，从而if条件判为false，方法返回instance引用，用户得到了没有完成初始化的“半个”单例。

懒汉式5

解决上述问题，只需要将instance声明为volatile变量。

public class LazySingleton5 {
    private static volatile LazySingleton5 instance;

    private LazySingleton5() {

    }
    public static LazySingleton5 getInstance() {
        //业务代码省略
        if (instance == null) {
            //双重检查
            synchronized (LazySingleton5.class) {
                if (instance == null) {
                    try {
                        Thread.sleep(1);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    instance = new LazySingleton5();
                }
            }
        }
        return instance;
    }
    public static void main(String[] args) {
        for (int i = 0; i < 10000; i++) {
            new Thread(() -> {
                System.out.println(getInstance().hashCode());
            }).start();
        }
    }
}

volatile

volatile作用：

不保证原子性
保证可见性
禁止指令重排序

volatile是如何禁止指令重排序的

volatile关键字通过内存屏障来防止指令被重排序。
为了实现volatile的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。然而，对于编译器来说，发现一个最优布置来最小化插入屏障的总数几乎不可能，为此，Java内存模型采取保守策略。

下面是基于保守策略的JMM内存屏障插入策略：

在每个volatile写操作的前面插入一个StoreStore屏障。
在每个volatile写操作的后面插入一个StoreLoad屏障。
在每个volatile读操作的后面插入一个LoadLoad屏障。
在每个volatile读操作的后面插入一个LoadStore屏障。

volatile是如何保证可见性的

先谈谈java内存模型

JMM Java Memory Model java内存模型

作用：缓存一致性协议，用于定义数据读写的规则

JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存（Main Memory）中，每个线程都有一个私有的本地内存（Local Memory）

在这里插入图片描述多个线程操作同一变量时，就存在可见性问题

解决共享对象可见性这个问题：volatile

内存交互操作有8种，虚拟机实现必须保证每一个操作都是原子的，不可在分的（对于double和long类
型的变量来说，load、store、read和write操作在某些平台上允许例外），两两成对出现。

lock （锁定）：作用于主内存的变量，把一个变量标识为线程独占状态
unlock （解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量
才可以被其他线程锁定
read （读取）：作用于主内存变量，它把一个变量的值从主内存传输到线程的工作内存中，以便
随后的load动作使用
load （载入）：作用于工作内存的变量，它把read操作从主存中变量放入工作内存中
use （使用）：作用于工作内存中的变量，它把工作内存中的变量传输给执行引擎，每当虚拟机
遇到一个需要使用到变量的值，就会使用到这个指令
assign （赋值）：作用于工作内存中的变量，它把一个从执行引擎中接受到的值放入工作内存的变
量副本中
store （存储）：作用于主内存中的变量，它把一个从工作内存中一个变量的值传送到主内存中，
以便后续的write使用
write （写入）：作用于主内存中的变量，它把store操作从工作内存中得到的变量的值放入主内
存的变量中

两个线程操作主内存中的initFlag变量时，在线程2的工作内存中将initFlag由false改为了true，cpu总线嗅探机制监听到了这一改变，线程1中的值就失效了，会进行重新读取的操作，这样就保证了每次读到的都是最新值，保证了可见性。

静态内部类

public class SingleTon{
  private SingleTon(){}
 
  private static class SingleTonHoler{
     private static SingleTon INSTANCE = new SingleTon();
 }
 
  public static SingleTon getInstance(){
    return SingleTonHoler.INSTANCE;
  }
}

静态内部类的优点是：外部类加载时并不需要立即加载内部类，内部类不被加载则不去初始化INSTANCE，故而不占内存。即当SingleTon第一次被加载时，并不需要去加载SingleTonHoler，只有当getInstance()方法第一次被调用时，才会去初始化INSTANCE,第一次调用getInstance()方法会导致虚拟机加载SingleTonHoler类，这种方法不仅能确保线程安全，也能保证单例的唯一性，同时也延迟了单例的实例化。

那么，静态内部类又是如何实现线程安全的呢？首先，我们先了解下类的加载时机。

类加载时机：JAVA虚拟机在有且仅有的5种场景下会对类进行初始化。
1.遇到new、getstatic、setstatic或者invokestatic这4个字节码指令时，对应的java代码场景为：new一个关键字或者一个实例化对象时、读取或设置一个静态字段时(final修饰、已在编译期把结果放入常量池的除外)、调用一个类的静态方法时。
2.使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没进行初始化，需要先调用其初始化方法进行初始化。
3.当初始化一个类时，如果其父类还未进行初始化，会先触发其父类的初始化。
4.当虚拟机启动时，用户需要指定一个要执行的主类(包含main()方法的类)，虚拟机会先初始化这个类。
5.当使用JDK 1.7等动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。
这5种情况被称为是类的主动引用，注意，这里《虚拟机规范》中使用的限定词是"有且仅有"，那么，除此之外的所有引用类都不会对类进行初始化，称为被动引用。静态内部类就属于被动引用的行列。

我们再回头看下getInstance()方法，调用的是SingleTonHoler.INSTANCE，取的是SingleTonHoler里的INSTANCE对象，跟上面那个DCL方法不同的是，getInstance()方法并没有多次去new对象，故不管多少个线程去调用getInstance()方法，取的都是同一个INSTANCE对象，而不用去重新创建。当getInstance()方法被调用时，SingleTonHoler才在SingleTon的运行时常量池里，把符号引用替换为直接引用，这时静态对象INSTANCE也真正被创建，然后再被getInstance()方法返回出去，这点同饿汉模式。那么INSTANCE在创建过程中又是如何保证线程安全的呢？在《深入理解JAVA虚拟机》中，有这么一句话:

虚拟机会保证一个类的()方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的()方法，其他线程都需要阻塞等待，直到活动线程执行()方法完毕。如果在一个类的()方法中有耗时很长的操作，就可能造成多个进程阻塞(需要注意的是，其他线程虽然会被阻塞，但如果执行()方法后，其他线程唤醒之后不会再次进入()方法。同一个加载器下，一个类型只会初始化一次。)，在实际应用中，这种阻塞往往是很隐蔽的。

故而，可以看出INSTANCE在创建过程中是线程安全的，所以说静态内部类形式的单例可保证线程安全，也能保证单例的唯一性，同时也延迟了单例的实例化。

枚举单例

public enum  EnumSingleton {
    INSTANCE;

    public void print() {
        System.out.println(this.hashCode());
    }
}

class EnumTest {
    public static void main(String[] args) {
        for (int i = 0; i < 20; i++) {
            new Thread(()->{
                EnumSingleton.INSTANCE.print();
            }).start();
        }
    }
}

结果
在这里插入图片描述
枚举在java中与普通类一样，都能拥有字段与方法，而且枚举实例创建是线程安全的，在任何情况下，它都是一个单例。

丁俏

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
深入理解单例模式

深入理解DCL单例模式什么是单例模式饿汉式懒汉式懒汉式1懒汉式2懒汉式3懒汉式4懒汉式5volatilevolatile是如何禁止指令重排序的volatile是如何保证可见性的什么是单例模式单例模式（Singleton Pattern）属于创建型模式，它提供了一种创建对象的最佳方式。这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。注意：单例类只能有一个实例。单例类必须自己创建自己的唯一实
复制链接

扫一扫