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

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 的语义能否满足使用场景的需求。
相关推荐
.生产的驴1 小时前
Maven 公司内部私服中央仓库搭建 局域网仓库 资源共享 依赖包构建共享
java·maven
Auc241 小时前
OJ判题系统第6期之判题逻辑开发——设计思路、实现步骤、代码实现(策略模式)
java·开发语言·docker·容器·策略模式
快乐肚皮1 小时前
深入解析Docker:核心架构与最佳实践
java·运维·docker·容器
zhou1851 小时前
MySQL保姆级安装教程(附资源包+5分钟极速配置+环境变量调试技巧)
java·python·mysql·php
小雅痞2 小时前
[Java][Leetcode middle] 55. 跳跃游戏
java·leetcode
com未来2 小时前
使用 NSSM 安装 Tomcat 11.0.6 为 Windows 服务
java·windows·tomcat
TDengine (老段)2 小时前
基于 TSBS 标准数据集下 TimescaleDB、InfluxDB 与 TDengine 性能对比测试报告
java·大数据·开发语言·数据库·时序数据库·tdengine·iotdb
养军博客2 小时前
spring boot3.0自定义校验注解:文章状态校验示例
java·前端·spring boot
lgily-12252 小时前
常用的设计模式详解
java·后端·python·设计模式
IT成长史2 小时前
deepseek梳理java高级开发工程师微服务面试题
java·微服务