【JUC并发编程】使用多线程可能带来什么问题?

文章目录

【JUC并发编程】使用多线程可能带来什么问题?
- 什么是多线程
- 并发为什么会出现
- 线程带来的安全性问题
- - 可见性问题
  - 原子性问题
  - 有序性问题
  - 活跃性问题
  - 性能问题
  - - 引起线程切换的几种方式

什么是多线程

多线程意味着你能够在同一个应用程序中运行多个线程，我们知道，指令是在 CPU 中执行的，多线程应用程序就像是具有多个 CPU 在同时执行应用程序的代码。

其实这是一种假象，线程数量并不等于 CPU 数量，单个 CPU 将在多个线程之间共享 CPU 的时间片，在给定的时间片内执行每个线程之间的切换，每个线程也可以由不同的 CPU 执行，如下图所示

并发为什么会出现

计算机世界的快速发展离不开 CPU、内存和 I/O 设备的高速发展，但是这三者一直存在速度差异性问题，我们可以从存储器的层次结构可以看出

CPU 内部是寄存器的构造，寄存器的访问速度要高于高速缓存，高速缓存的访问速度要高于内存，最慢的是磁盘访问。

程序是在内存中执行的，程序里大部分语句都要访问内存，有些还需要访问 I/O 设备，根据漏桶理论来说，程序整体的性能取决于最慢的操作也就是磁盘访问速度。

因为 CPU 速度太快了，所以为了发挥 CPU 的速度优势，平衡这三者的速度差异，计算机体系机构、操作系统、编译程序都做出了贡献，主要体现为：

CPU 使用缓存来中和和内存的访问速度差异
操作系统提供进程和线程调度，让 CPU 在执行指令的同时分时复用线程，让内存和磁盘不断交互，不同的 CPU 时间片 能够执行不同的任务，从而均衡这三者的差异
编译程序提供优化指令的执行顺序，让缓存能够合理的使用

线程带来的安全性问题

线程安全性是非常复杂的，在没有采用同步机制的情况下，多个线程中的执行操作往往是不可预测的，这也是多线程带来的挑战之一，下面我们给出一段代码，来看看安全性问题体现在哪

public class TSynchronized implements Runnable{

    static int i = 0;

    public void increase(){
        i++;
    }


    @Override
    public void run() {
        for(int i = 0;i < 1000;i++) {
            increase();
        }
    }

    public static void main(String[] args) throws InterruptedException {

        TSynchronized tSynchronized = new TSynchronized();
        Thread aThread = new Thread(tSynchronized);
        Thread bThread = new Thread(tSynchronized);
        aThread.start();
        bThread.start();
        System.out.println("i = " + i);
    }
}

这段程序输出后会发现，i 的值每次都不一样，这不符合我们的预测，那么为什么会出现这种情况呢？我们先来分析一下程序的运行过程。

TSynchronized 实现了 Runnable 接口，并定义了一个静态变量 i，然后在 increase 方法中每次都增加 i 的值，在其实现的 run 方法中进行循环调用，共执行 1000 次。

可见性问题

在单核 CPU 时代，所有的线程共用一个 CPU，CPU 缓存和内存的一致性问题容易解决，CPU 和内存之间

在多核时代，因为有多核的存在，每个核都能够独立的运行一个线程，每颗 CPU 都有自己的缓存，这时 CPU 缓存与内存的数据一致性就没那么容易解决了，当多个线程在不同的 CPU 上执行时，这些线程操作的是不同的 CPU 缓存

因为 i 是静态变量，没有经过任何线程安全措施的保护，多个线程会并发修改 i 的值，所以我们认为 i 不是线程安全的，导致这种结果的出现是由于 aThread 和 bThread 中读取的 i 值彼此不可见，所以这是由于 可见性 导致的线程安全问题。

原子性问题

看起来很普通的一段程序却因为两个线程 aThread 和 bThread 交替执行产生了不同的结果。但是根源不是因为创建了两个线程导致的，多线程只是产生线程安全性的必要条件，最终的根源出现在 i++ 这个操作上。

这个操作怎么了？这不就是一个给 i 递增的操作吗？也就是 「i++ => i = i + 1」，这怎么就会产生问题了？

因为 i++ 不是一个 原子性 操作，仔细想一下，i++ 其实有三个步骤，读取 i 的值，执行 i + 1 操作，然后把 i + 1 得出的值重新赋给 i（将结果写入内存）。

当两个线程开始运行后，每个线程都会把 i 的值读入到 CPU 缓存中，然后执行 + 1 操作，再把 + 1 之后的值写入内存。因为线程间都有各自的虚拟机栈和程序计数器，他们彼此之间没有数据交换，所以当 aThread 执行 + 1 操作后，会把数据写入到内存，同时 bThread 执行 + 1 操作后，也会把数据写入到内存，因为 CPU 时间片的执行周期是不确定的，所以会出现当 aThread 还没有把数据写入内存时，bThread 就会读取内存中的数据，然后执行 + 1操作，再写回内存，从而覆盖 i 的值，导致 aThread 所做的努力白费。

为什么上面的线程切换会出现问题呢？

我们先来考虑一下正常情况下（即不会出现线程安全性问题的情况下）两条线程的执行顺序

可以看到，当 aThread 在执行完整个 i++ 的操作后，操作系统对线程进行切换，由 aThread -> bThread，这是最理想的操作，一旦操作系统在任意 读取/增加/写入 阶段产生线程切换，都会产生线程安全问题。例如如下图所示

最开始的时候，内存中 i = 0，aThread 读取内存中的值并把它读取到自己的寄存器中，执行 +1 操作，此时发生线程切换，bThread 开始执行，读取内存中的值并把它读取到自己的寄存器中，此时发生线程切换，线程切换至 aThread 开始运行，aThread 把自己寄存器的值写回到内存中，此时又发生线程切换，由 aThread -> bThread，线程 bThread 把自己寄存器的值 +1 然后写回内存，写完后内存中的值不是 2 ，而是 1，内存中的 i 值被覆盖了。

我们上面提到 原子性 这个概念，那么什么是原子性呢？

并发编程的原子性操作是完全独立于任何其他进程运行的操作，原子操作多用于现代操作系统和并行处理系统中。

原子操作通常在内核中使用，因为内核是操作系统的主要组件。但是，大多数计算机硬件，编译器和库也提供原子性操作。

在加载和存储中，计算机硬件对存储器字进行读取和写入。为了对值进行匹配、增加或者减小操作，一般通过原子操作进行。在原子操作期间，处理器可以在同一数据传输期间完成读取和写入。这样，其他输入/输出机制或处理器无法执行存储器读取或写入任务，直到原子操作完成为止。

简单来讲，就是「原子操作要么全部执行，要么全部不执行」。数据库事务的原子性也是基于这个概念演进的。

有序性问题

在并发编程中还有带来让人非常头疼的 有序性 问题，有序性顾名思义就是顺序性，在计算机中指的就是指令的先后执行顺序。一个非常显而易见的例子就是 JVM 中的类加载

这是一个 JVM 加载类的过程图，也称为类的生命周期，类从加载到 JVM 到卸载一共会经历五个阶段 「加载、连接、初始化、使用、卸载」。这五个过程的执行顺序是一定的，但是在连接阶段，也会分为三个过程，即 「验证、准备、解析」 阶段，这三个阶段的执行顺序不是确定的，通常交叉进行，在一个阶段的执行过程中会激活另一个阶段。

有序性问题一般是编译器带来的，编译器有的时候确实是 「好心办坏事」，它为了优化系统性能，往往更换指令的执行顺序。