并发问题的三大根源：揭秘多线程编程的隐形陷阱

无理 Java

已于 2024-07-18 15:46:47 修改

阅读量1.4k

点赞数 34

分类专栏： # Java 文章标签： java spring 后端架构 spring boot spring cloud 安全

于 2024-07-12 09:00:00 首次发布

本文链接：https://blog.csdn.net/weixin_68020300/article/details/140364462

版权

Java 专栏收录该内容

58 篇文章 1 订阅

订阅专栏

文章目录

引言
1.CPU缓存导致的可见性
2.线程切换导致的原子性问题
3.编译优化导致的有序性问题

引言

在数字时代，高性能计算已成为推动科技进步的关键引擎。随着CPU核心数的激增以及硬件性能的飞跃，多线程编程技术应运而生，旨在最大化硬件资源的利用率，实现任务并行处理，从而大幅提升应用程序的运行效率。然而，在享受多线程带来的性能红利的同时，程序员们也面临着前所未有的挑战——并发问题。

想象一下，你正在指挥一场宏大的交响乐演出，每个乐器代表一个独立的线程，它们共同演奏出和谐的旋律。但若没有精心设计的乐谱和严格的指挥，音乐家们可能会各自为政，导致乐章杂乱无章，甚至完全失去控制。同样地，当多个线程试图同时访问共享资源时，如果没有恰当的同步机制，系统的行为将变得不可预测，甚至引发严重的错误。

本文将深入探讨并发问题的三大根源，揭示多线程编程中的隐形陷阱，并提供应对策略，帮助你在多线程环境中编写更安全、更高效的代码。

1.CPU缓存导致的可见性

在早期CPU是单核的时候，所有线程都在一个CPU上执行，CPU的缓存与内存之间的数据一致性就很好解决了。CPU高速缓存是用于减少CPU访问内存所需的时间，提高CPU的使用率，一个线程的操作对于另一个线程来说是一定可以看到的。一个线程对共享变量的修改，另外一个线程能够立刻看到，我们称为可见性
在这里插入图片描述
随着时间的发展，CPU变为多核的时候，由于CPU都有自己独立的缓存，当多个线程分别在不同的CPU上执行时，会把内存中操作的变量复制到自己的CPU缓存中，处理完成后在写入内存，这样线程之间的可见性就无法保障了。
在这里插入图片描述

public class Test {
    private static long sum = 0;

    public static void main(String[] args) throws InterruptedException {
        //创建两个线程，每个线程对sum进行加10000的操作
        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 10000; i++) {
                sum++;
            }
        });
        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 10000; i++) {
                sum++;
            }
        });
        tl.start();
        t2.start();
        //等待两个线程执行结束
        t1.join();
        t2.join();
        System.out.println(sum);
    }
}

通过看代码，直觉告诉我们最后输出结果是20000，但是当实际运行时，我们发现每次的输出结果都是小于20000的。我们假设两个线程同时执行，把 sum=0加载到自己的CPU缓存中，t1 t2两个线程进行 sum++的操作，此时各自缓存中的sum值都是1，这时候把sum写入到内存的时候，我们发现不是我们期望的2，而是1。

2.线程切换导致的原子性问题

我们知道线程是通过获取CPU时间片来进行调度的，线程只有得到CPU时间片才能执行指令，处于执行状态，没有得到时间片的线程处于就绪状态，等待系统分配下一个CPU时间片。
线程的调度模型目前主要分为两种:分时调度模型和抢占式调度模型。

分时调度模型:系统平均分配CPU时间片，所有线程轮流获取CPU时间片
抢占式调度:系统按照线程优先级分配CPU时间片。优先级高的线程优先分配CPU时间片，如果所有就绪线程的优先级相同，那么会随机选择一个，优先级高的线程获取的CPU时间片相对多一些。

Java的线程调度模型采用的就是抢占式调度。

我们知道所有的高级编程语言，都需要转换成CPU指令，这样CPU才能执行操作。就对于上述 sum++ 这一行操作，转换成CPU指令后，至少有三条:

将sum变量从内存中加载到CPU寄存器,
在寄存器中执行+1操作。
将sum变量写入到缓存中
当执行第1步的时候，一个线程的时间片消耗完了，发生了线程切换，最后也会导致最终的结果是1而不是2。

我们看代码是一行，就感觉是一步就完成了，其实被分成这么多条CPU指令，上述问题中的任务切换，还有可能发生在任何一步，所以我们在编程时需要注意代码层面的原子性:一个或者多个操作在 CPU 执行的过程中不被中断的特炷。

3.编译优化导致的有序性问题

之前我们了解到CPU增加高速缓存，进程中诞生线程等等为了提高CPU利用率的方式，其实在CPU内部执行CPU指令时，会调整每一步CPU指令的执行顺序，来提升CPU的效率，指令顺序优化可能发生在编译、CPU指令执行、缓存优化几个阶段，其优化原则就是只要能保证重排序后不影响单线程的运行结果，那么就允许指令重排序的发生,

一个对象的new操作，也不是原子性的，他分为下面三步:

给对象分配内存
在这块内存上初始化对象
将这块地址赋值给变量

public class Singleton {
    private static Singleton instance;

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                    return instance;
                }
            }
        }
        return instance;
    }
}

在这个不正确的单例模式中，我们假设A B两个线程同时调用 getinstance 方法，同时发现 instance ==nul ，但是有可能因为指令优化，导致并不是按照正常123的顺序，当发生132的顺序时，可能会出现下面的情况
在这里插入图片描述
这时候可能就会发生空指针异常了，我们使用idea时，idea会提醒你为instance变量添加volatile 变量，主要是为了解决上述的问题。
之后我们再详细介绍Java是如何解决这三大问题的。