JavaEE-经典多线程样例

🕗 发布于 2024-12-02 09:40 java-ee java android

文章目录

单例模式
阻塞队列

单例模式

设计模式初步引入

啥是设计模式?

设计模式好⽐象棋中的 “棋谱”. 红⽅当头炮, ⿊⽅⻢来跳. 针对红⽅的⼀些⾛法, ⿊⽅应招的时候有⼀些固定的套路. 按照套路来⾛局势就不会吃亏.软件开发中也有很多常⻅的 “问题场景”. 针对这些问题场景, ⼤佬们总结出了⼀些固定的套路. 按照这个套路来实现代码, 也不会吃亏, 不针对某一种语言, 而是针对某种开发场景
设计模式并不是只有23种, 因为之前有些大佬写了一本书叫设计模式,重点讨论了23种, 但事实上存在更多种的设计模式
设计模式与框架的区别就是, 设计模式在开发中是软性要求(不一定遵守), 但是框架是硬性要求(一定要遵守)

简单点一句话总结

设计模式是前人根据一些开发场景给出的一些经验之谈, 所以设计模式并不针对某一种语言

为何存在单例模式

单例模式能保证某个类在程序中只存在唯⼀⼀份实例, ⽽不会创建出多个实例.
这⼀点在很多场景上都需要. 比如 JDBC 中的 DataSource 实例就只需要⼀个,再
比如如果一个类的创建需要加载的数据量非常的庞大(GB级别), 那我们不希望这
个类频繁的创建销毁(开销很大), 我们可能只是希望创建一次就可以了

饿汉式单例模式

顾名思义, 这种方式实现的单例模式十分"饥渴", 不管使用不使用都会提前new一个对象

流程如下

构造方法私有化
定义一个静态的类对象用以返回
提供一个公开的静态接口来获取唯一的对象

测试代码如下

/**
 * 下面定义一个类来测试饿汉式单例模式
 */
class HungrySingleton{
    // 提供一个静态的变量用来返回
    private static HungrySingleton hungrySingleton = new HungrySingleton();

    // 构造方法私有化(在外部不可以构造对象)
    private HungrySingleton(){

    }

    // 提供一个获取实例的静态公开接口
    public static HungrySingleton getInstance(){
        return hungrySingleton;
    }
}

public class DesignPatternTest {
    public static void main(String[] args) {
        // 对饿汉式单例的测试
        HungrySingleton instance1 = HungrySingleton.getInstance();
        HungrySingleton instance2 = HungrySingleton.getInstance();

        // 测试两者是不是一个对象
        System.out.println(instance1 == instance2);
    }
}

测试结果
在这里插入图片描述
很明显, 用这种方式创建的实例都是只有一份的…

饿汉式缺陷以及是否线程安全

首先饿汉式的单例模式缺陷是非常明显的

饿汉式不管我们使用这个对象与否, 都会在类加载的时期(因为是静态对象)构建一个这样的对象, 但我们想要达成的效果是, 在我们不需要这种类的实例的时候, 我们不去进行构造对象的操作(变主动为被动)来减少内存等相关资源的开销

但是饿汉式单例一定是线程安全的

构建对象的时期是类加载的时候, 后期不同线程对于这个实例的操作也仅仅是涉及到读操作, 不涉及修改操作, 所以当然是线程安全的, 不存在线程安全问题, 但是另一种实现的模式就不一定了

懒汉式单例模式

上面说了饿汉式单例模式的缺陷, 我们尝试使用懒汉式单例的方式去解决这个问题, 也就是仅仅在需要的时候进行new对象的操作

最基础的懒汉单例模式

构造的逻辑

构造方法私有化
提供一个静态的对象用来返回(暂时不new对象)
提供一个公开访问的静态接口来返回唯一的对象

代码测试(最基础的版本)

/**
 * 下面定义一个类来测试懒汉式单例模式
 */
class LazySingleton{
    // 提供一个静态的变量用来返回
    private static LazySingleton lazySingleton = null;

    // 构造方法私有化(不可以在外部new对象)
    private LazySingleton(){

    }

    // 提供一个公开的获取实例的接口
    public static LazySingleton getInstance(){
        if(lazySingleton == null){
            lazySingleton = new LazySingleton();
        }
        return lazySingleton;
    }
}

public class DesignPatternTest {
    public static void main(String[] args) {
        // 对懒汉式单例的测试
        LazySingleton instance1 = LazySingleton.getInstance();
        LazySingleton instance2 = LazySingleton.getInstance();

        // 测试两者是不是一个对象
        System.out.println(instance1 == instance2);
    }
}

基础懒汉式缺陷以及是否线程安全

这个就和上面饿汉有较大的区别了, 虽然解决了在需要的时候进行new对象, 上面的基础版本的懒汉式在单线程的环境下肯定是没问题的, 但是在多线程的环境下就不好说了…看下面的分析

如果在多线程的环境下(我们假设有t1, t2)是下图的执行顺序
在这里插入图片描述
很明显这是一种类似串行的执行策略

但是还可能是下图的情况
在这里插入图片描述
t1线程判断完毕之后没有来得及进行new对象, t2线程紧接着进行了一次完整的new对象的过程, 此时t1线程又进行了一次new对象的过程, 很明显, 我们上面的情况进行了两次构造对象的过程, 同时拿到的对象也不一致

我们通过Thread.sleep()的方式进行延迟观察看是否会发生

/**
 * 下面定义一个类来测试懒汉式单例模式
 */
class LazySingleton{
    // 提供一个静态的变量用来返回
    private static LazySingleton lazySingleton = null;

    // 构造方法私有化(不可以在外部new对象)
    private LazySingleton(){

    }

    // 提供一个公开的获取实例的接口
    public static LazySingleton getInstance() throws InterruptedException {
        if(lazySingleton == null){
            Thread.sleep(1000);
            lazySingleton = new LazySingleton();
        }
        return lazySingleton;
    }
}

public class DesignPatternTest {

    private static LazySingleton instance1 = null;

    private static LazySingleton instance2 = null;

    public static void main(String[] args) throws InterruptedException {
        // 创建两个线程获取实例
        Thread t1 = new Thread(() -> {
            try {
                instance1 = LazySingleton.getInstance();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });

        Thread t2 = new Thread(() -> {
            try {
                instance2 = LazySingleton.getInstance();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });

        // 开启两个线程
        t1.start();
        t2.start();

        // 睡眠等待一下
        Thread.sleep(2000);
        System.out.println(instance1 == instance2);
    }
}

在这里插入图片描述
很明显, 这样的懒汉式的代码是线程不安全的, 那要如何进行改进呢???

懒汉式单例模式的改进

之前我们说了, 要想保证线程是安全的, 有几种解决方式, 这里面我们就采取加锁, 因为其实
判断是不是null和对象应该是一个整体的原子性的操作

改进之后的代码

/**
 * 下面定义一个类来测试懒汉式单例模式(改进版)
 */
class LazySingleton{
    // 提供一个静态的变量用来返回
    private static LazySingleton lazySingleton = null;

    // 构造方法私有化(不可以在外部new对象)
    private LazySingleton(){

    }

    // 提供一个公开的获取实例的接口
    public static LazySingleton getInstance() {
        // 我们把if判断和new对象通过加锁打包为一个原子性的操作(这里使用类对象锁)
        synchronized (LazySingleton.class){
            if(lazySingleton == null){
                lazySingleton = new LazySingleton();
            }
        }
        return lazySingleton;
    }
}

public class DesignPatternTest {

    private static LazySingleton instance1 = null;

    private static LazySingleton instance2 = null;

    public static void main(String[] args) {
        // 在多线程中获取实例
        Thread t1 = new Thread(() -> {
            instance1 = LazySingleton.getInstance();
        });

        Thread t2 = new Thread(() -> {
            instance2 = LazySingleton.getInstance();
        });

        System.out.println(instance1 == instance2);
    }
}

这时候肯定是一个线程安全的代码了, 但是思考可不可以进一步改进呢???

当我们已经new个一次对象之后, 如果后续的线程想要获取这个对象, 那就仅仅是一个读操作了, 根本不涉及对对象的修改, 但是我们每次都使用锁这样的机制就会造成阻塞, 也就会导致程序的效率下降, 所以我们对代码进行了下面的修改在外层再加一个if判断

改进的方法如下

// 提供一个公开的获取实例的接口
    public static LazySingleton getInstance() {
        // 我们把if判断和new对象通过加锁打包为一个原子性的操作(这里使用类对象锁)
        if (lazySingleton == null) {
            synchronized (LazySingleton.class) {
                if (lazySingleton == null) {
                    lazySingleton = new LazySingleton();
                }
            }
        }
        return lazySingleton;
    }

我们的两个if的含义

第一个if: 判断对象是否创建完毕, 如果创建了, 只是一个读操作
第二个if: 判断是不是需要new对象

可能初学多线程的时候, 看上述代码觉得很迷惑, 但其实这是因为之前我们写的程序都是单线程的情况, 单线程中执行流只有一个, 两次相同的if判断其实是没有必要的, 但是多线程的条件下, 是多个执行流, 相同的逻辑判断条件也可能产生不同的结果

完整代码(变量volatile)

关于变量是否会产生指令重排序和内存可见性问题, 我们直接加上volatile即可

/**
 * 下面定义一个类来测试懒汉式单例模式(完整改进版)
 */
class LazySingleton {
    // 提供一个静态的变量用来返回
    private volatile static LazySingleton lazySingleton = null;

    // 构造方法私有化(不可以在外部new对象)
    private LazySingleton() {

    }

    // 提供一个公开的获取实例的接口
    public static LazySingleton getInstance() {
        // 我们把if判断和new对象通过加锁打包为一个原子性的操作(这里使用类对象锁)
        if (lazySingleton == null) {
            synchronized (LazySingleton.class) {
                if (lazySingleton == null) {
                    lazySingleton = new LazySingleton();
                }
            }
        }
        return lazySingleton;
    }
}

阻塞队列

生产者消费者模型

关于生产者消费者模型, 其实是生活中抽象出来的一个模型案例, 我们举一个包饺子的例子来简单解释一下

在包饺子的过程中, 存在一个擀饺子皮的人, 我们称之为生产者, 擀出来的饺子皮放到一个竹盘上, 这个竹盘相当于一个中间的媒介, 生产者生产的物质在上面与消费者进行交互, 而包饺子的人就是一个消费者, 从中间媒介中取出东西, 也就是消费的过程, 我们的中间的竹盘相当于一个缓冲, 如果包饺子的人包的快的话, 就需要等待做饺子皮的人, 如果做饺子皮的人做的快的话, 当竹盘放不下的时候就需要阻塞等待
上面的情景抽象成生产者消费者模型, 擀饺子皮的人是生产者, 竹盖是阻塞队列, 包饺子的人是消费者

生产者消费者模型的案例以及优点

请求与响应案例

生产者消费者模型我们举一个"请求响应的案例"

在这里插入图片描述
图中我们也有解释, 越靠上游的消耗的资源越少
假设我们现在出现一个秒杀的请求, 上游可能还可以运行, 但是下游的服务器由于并发量过大就直接崩溃了

在这里插入图片描述
所以我们一般会对上面提供服务的逻辑进行改变
添加一个中间的结构(阻塞队列, 或者说消息队列)进行缓冲

在这里插入图片描述

在真实的开发场景当中, 阻塞队列甚至会单独的部署为一台服务器, 这种独立的服务器结构叫做消息队列, 可见其重要性

解耦合

生产者消费者模型的一个重要的优点就是让消费者和生产者解耦合

根据上面的模型分析, 不管是生产者还是消费者都是面向阻塞队列来进行任务的执行的, 所以就降低了两者之间的耦合度, 将来想要修改这个模型的工作内容, 也只需要面向阻塞队列操作更改(其实相当于接口), 如果没有这种机制的话, 我们想要更改一个操作逻辑, 就需要同时修改消费者与生产者的代码结构…

原文地址：https://blog.csdn.net/2301_81486828/article/details/144172829

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！

上一篇：YOLOv8-ultralytics-8.2.103部分代码阅读笔记-instance.py
下一篇：【Maven系列】深入解析 Maven 常用命令

迅为瑞芯微RK3562开发板/核心板应用于人脸跟踪、身体跟踪、视频监控、自动语音识别(ASR)、图像分类驾驶员辅助系统(ADAS)、车牌识别、物体识别等
iTOP-3562开发板/核心板采用瑞芯微RK3562处理器，内部集成了四核A53+Mali G52架构，主频2GHZ，内置1TOPSNPU算力，RK809动态调频。支持几乎全格式的H.264解码，支
阅读更多2024-12-31
低精度只适用于未充分训练的LLM？腾讯提出LLM量化的scaling laws
尽管有一些研究声称原生的低比特LLM可以媲美fp16/bf16精度下的表现，但这些研究普遍都是在未充分语言模型上得到的结果从而推出的结论，研究人员认为在充分训练的情况下进行比较的话，低比特LLM也将很
阅读更多2024-12-31
医疗数仓配置Flume
Flume需要将Kafka中各topic的数据传输到HDFS，因此选用KafkaSource以及HDFSSink。对于安全性要求高的数据（不允许丢失）选用FileChannel，允许部分丢失的数据如日
阅读更多2024-12-31
Go中CAS算法
CAS算法常被用作乐观锁的实现方式，用于解决并发问题。例如，在计数器、缓存等场景中，可以使用CAS算法来确保数据的一致性和正确性。CAS操作会检查内存位置V的当前值是否与预期的旧值A相等。这一操作是原
阅读更多2024-12-31
Node.js 记账本项目总结
在使用Node.js结合Express框架构建记账本的过程中，遇到了一些常见的问题，这些问题主要集中在路径处理、包管理工具的选择、开发环境优化以及HTTP响应处理等方面。
阅读更多2024-12-31
Java 处理base64文件上传
在系统内有一个类似于公告的模块，如果里面添加的文章不是选择富文本上传图片的方式，而是选择复制别的文章直接粘贴到系统内的富文本，里面的图片就不会url，而是图片的base64格式，这样会导致数据库存储压
阅读更多2024-12-31
Tailwind CSS 实战：现代登录注册页面开发
基础结构搭建表单组件开发社交登录集成响应式适配深色模式支持动画效果表单验证性能优化可访问性增强通过合理使用 Tailwind CSS 的原子类，我们不仅实现了美观的界面，还确保了良好的用户体验和可维护
阅读更多2024-12-31
node.js下载、安装、设置国内镜像源（永久）（Windows11）
系统：Windows 11。
阅读更多2024-12-31
Slate文档编辑器-Decorator装饰器渲染调度
在这里我们主要讨论了slate中的decoration装饰器的实现，以及在实际使用中可能会遇到的问题，主要是在跨节点的情况下，我们需要将range拆分为多个range，然后分别进行处理，并且还分析了源
阅读更多2024-12-31
python去水印
请注意，这种方法仅适用于简单的水印去除，对于复杂的水印或嵌入到图像纹理中的水印，可能无法达到理想的效果。在实际应用中，还可以考虑使用深度学习的方法，如生成对抗网络（GAN）来去除水印，但需要大量的数据
阅读更多2024-12-31