设计模式-单例模式(双重检查)

1. 概念

  • 保证一个类只有一个实例
  • 并为该实例提供一个全局唯一的访问节点

2. 双重检查

2.1 代码示例

示例
java 复制代码
public class Singleton06 {

    private Singleton06() {}

    private static volatile Singleton06 INSTANCE;

    // 加入双重检查代码,解决线程安全问题,同时解决懒加载问题
    public static Singleton06 getInstance() {
        if (INSTANCE == null) {
            synchronized (Singleton06.class) {
                // 进到这里只有一个线程
                if (INSTANCE == null) {
                    INSTANCE = new Singleton06();
                }
            }
        }
        return INSTANCE;
    }
}
java 复制代码
public class SingletonTest06 {
    public static void main(String[] args) {
        Singleton06 instance = Singleton06.getInstance();
        Singleton06 instance1 = Singleton06.getInstance();
        System.out.println(instance == instance1);
        System.out.println("instance.hashCode= " + instance.hashCode());
        System.out.println("instance1.hashCode= " + instance1.hashCode());
    }
}

2.2 优缺点

  1. Double-Check概念是多线程开发中常使用到的,如代码中所示,我们进行了两次if(singleton==null)检查,这样就可以保证线程安全了。
  2. 这样实例化代码只用执行一次,后面再次访问时,判断if (singleton == null),直接return实例化对象,也避免的反复进行方法同步。
  3. 线程安全,延迟加载,效率较高。

2.3 结论

  • 双重检查线程安全,延迟加载,效率较高,在实际开发中,推荐使用这种单例设计模式。

3. 题外篇:volatile关键字

3.1 介绍

  1. volatile是一种同步机制,类似于 Lock 和 Synchronized ,但是他更轻量级,因为使用 volatile 并不会发生上下文切换等开销很大的行为。
  2. 如果一个变量被volatile修饰,那么JVM会认为这个变量可能会被并发修改,会保证关于这个变量的修改能立即被其他线程看到。
  3. 因为开销小,所以能力也小;他做不到像 synchronized 那样的原子保护,使用的场景比较有限。

3.2 作用

  • 可见性
    • 读一个volatile修饰的变量之前,需要先使相应的本地缓存失效,这样就必须到主内存读取最新的值;写一个volatile属性会立刻刷入到主内存。这里的"可见性"是指当一个线程修改了这个变量的值,新值对于其他线程来说是可以立即得知的。
  • 防止指令重排序
    • 在没有volatile修饰的情况下,编译器和处理器可能会对指令进行重排序以优化性能。但是,如果代码中存在对volatile变量的读写操作,那么这些操作不会被重排序,从而保证了有序性。

3.3 场景

  • 适用的场景
    • 直接赋值
      • 由于赋值操作具有原子性,所以能够保证变量执行完赋值操作能立即被其他线程看到,保证了可见性。
    • 作为刷新之前变量的触发器
      • volatile 具有可见性和防止重排序的特性,所有由它修饰的变量 x 在执行某个操作之后,x 之前的代码已经被执行过了(防止重排序),因为 x 会被其它线程立即看到(可见性),所以 x 之前的代码中的变量也会被其他线程看到(happens-before原则,也可以说是 近朱者赤 原则,近朱者赤是 volatile 的一个特性)
      • volatile 的特性:近朱者赤。他不仅可以帮助自己可见性,也可以帮助在他进行赋值之前进行的操作也具有可见性
  • 不适用的场景
    • 于 i++ 的操作,即使使用volatile 修饰了 i,也不能保证 i++ 的并发安全
    • 对于依赖之前的状态的操作,比如对 boolean 类型的变量取反,就需要先获取该变量之前的值,然后再取反

3.3 使用 volatile 的意义

  • 它能让我们的代码比使用其他的同步工具更快吗?
  • 在某些情况下,volatile 的同步机制的性能确实要优于锁,但由于虚拟机对锁实行的许多消除和优化,使得我们很难量化地认为 volatile 就会比 synchronized 快多少。
  • 如果让 volatile 变量与普通变量比较,那可以确定一个原则:volatile 变量读操作的性能消耗与普通变量几乎没有什么差别,但是写操作则可能会慢一些,因为他需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。不过即便如此,大多数场景下 volatile 的总开销仍然要比锁低,我们在 volatile 与锁之间选择的唯一依据仅仅是 volatile 的语义能否满足使用场景的需求。
相关推荐
2601_9621066410 小时前
【Java Set综合实战】商品管理系统 + 图书收藏系统|Product、Book自定义类全套代码
java
RuoyiOffice10 小时前
SpringBoot+Vue3 凭证生命周期设计:审核、过账、冲销与反过账怎样保持账目一致
java·spring boot·事务·springboot3·财务系统·会计凭证·ruoyi office
2601_9621066411 小时前
HashMap入门|工号-姓名键值存储、两种遍历方式、根据key/value查
java
杨凯凡11 小时前
Spring Framework 7 API 版本管理实战:请求头路由、兼容迁移与废弃策略
java·rest api·springframework·spring boot 4·api版本管理
T_Wizard12 小时前
同一个问题写了 4 遍:官方 SDK / HTTP / Spring AI / LangChain4j,到底该选哪个
java·ai编程
hai_android12 小时前
AudioTrack 深度解析:从原理到实战
android·java·kotlin
百思不得小李12 小时前
一个复杂的动态表单是如何实现的
前端·设计模式
斯维赤12 小时前
限流、熔断、降级,你真的分得清吗?
java·后端·架构
aiks_yuan15 小时前
Java CPU 100% 怎么排查:JDK 11 起 jstack 自带线程 CPU 时间,不用再 top -H 换算十六进制(JDK 8、11、17 实测)
java
爱你真是太好了15 小时前
上下文组成以及如何压缩
设计模式