【线程安全(重点) 】

卷我没对象、

已于 2023-03-23 15:53:42 修改

阅读量55

点赞数

分类专栏：多线程文章标签： java 开发语言

于 2023-03-19 13:33:41 首次发布

本文链接：https://blog.csdn.net/qq_64317046/article/details/129647054

版权

多线程专栏收录该内容

10 篇文章 0 订阅

订阅专栏

本文介绍了线程安全的概念，强调在多线程环境中代码执行结果应与单线程环境相同。线程不安全主要由修改共享数据、原子性问题、内存可见性和代码重排序引起。通过示例解释了自增操作可能产生的不一致结果，并提出了解决方案，如使用synchronized和volatile关键字来确保原子性和内存可见性，防止代码重排序导致的问题。文章最后指出，加锁虽然能解决线程安全问题，但也可能影响并发性能，需要权衡使用。

摘要由CSDN通过智能技术生成

一、线程安全的概念

想给出一个线程安全的确切定义是复杂的，但我们可以这样认为：

如果多线程环境下代码运行的结果是符合我们预期的，即在单线程环境应该的结果，则说这个程序是线程安全的。

二、线程不安全的原因

2.1 修改共享数据

使用两个线程对同一个变量进行自增操作，每个线程自增5W次

运行一下代码并观察结果：

static class Counter {
    public int count = 0;

    void increase() {
        count++;
    }
}

    public static void main(String[] args) throws InterruptedException {
        final Counter counter = new Counter();
        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 50000; i++) {
                counter.increase();
            }
        });
        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 50000; i++) {
                counter.increase();
            }
        });
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println(counter.count);
    }

结果为：
在这里插入图片描述

我们预期的结果是自增达到10w次，但是这里的结果确相差甚远，是什么原因造成的呢？我们从CPU的角度来分析单个线程中的count++，如下：

在这里插入图片描述

下面我们来观察两个线程的情况(count从0开始)，如下：

在这里插入图片描述

但是，由于线程之间是抢占式执行的，导致上述三条指令可能会出现顺序错乱，从而影响到结果。如下：

在这里插入图片描述

其他错乱顺序类似，就不一一举例！！

在线程抢占式执行的情况下，t1和t2的这三个指令的相对顺序充满随机性，并且上述的错乱顺序都可能发生，且哪种情况出现多少次都是无法预测的！！所以对于count++，即使自增了10w次，结果并不能达到预期值。

解决办法：

处理上述不安全情况，我们可以对其加锁！至于什么是锁，以及如何加锁我们后面会详细谈到！

示例：

static class Counter {
    public int count = 0;
    synchronized void increase() {
        count++;
    }
}

图解：

在这里插入图片描述
总结：

针对涉及到count++的方法进行加锁，此时进入该方法就会自动上锁，离开时就会自动解锁。而当一个线程加锁成功时，其他线程如果尝试加锁就会触发阻塞等待，并且阻塞会持续到占用锁的线程把锁释放为止！！

注意：

多个线程针对不同变量进行修改，以及多个线程对同一个变量进行读都不会涉及到线程不安全

2.2 原子性

在这里插入图片描述

什么是原子性？

我们把一段代码想象成一个房间，每个线程就是要进入这个房间的人。如果没有任何机制保证，A进入房间之后，还没有出来；B 是不是也可以进入房间，打断 A 在房间里的隐私。这个就是不具备原子性的

那我们应该如何解决这个问题呢？是不是只要给房间加一把锁，A 进去就把门锁上，其他人是不是就进不来了。这样就保证了这段代码的原子性了

有时也把这个现象叫做同步互斥，表示操作是互相排斥的

一条 java 语句不一定是原子的，也不一定只是一条指令。比如刚才我们看到的 count++，其实是由三步操作组成的：

从内存把数据读到 CPU
进行数据更新
把数据写回到 CPU

不保证原子性会给多线程带来什么问题？

如果一个线程正在对一个变量操作，中途其他线程插入进来了，如果这个操作被打断了，结果就可能是错误的。这点也和线程的抢占式调度密切相关. 如果线程不是 “抢占” 的, 就算没有原子性, 也问题不大

而通过加锁就可以保证原子性！将多个操作打包成一个原子的操作

2.3 内存可见性

一、举个例子先：

针对同一个变量，一个线程循环进行读操作，另一个线程随机的执行一次修改操作，如下：

在这里插入图片描述

在之前的介绍中我们知道，此时的读操作就是t1从内存中读取数据。而循环的读取内存其实是一个非常低效的操作，并且如果t2迟迟不修改该值，t1读到的值又始终是一样的。为了避免这种情况，java编译器进行了代码优化，让t1不再从内存中读取数据了，而是直接从寄存器中。但是，此时存在一个非常大的问题，如果t2修改了该值，t1就感知不到了从而产生错误！！

注意： 编译器优化操作是圈内大佬设计的，在保证原有逻辑不变的情况下，能够大大的提高程序执行效率。但是在多线程中进行的优化可能会产生误判

二、下面我们学习下什么是内存可见性：

可见性指, 一个线程对共享变量值的修改，能够及时地被其他线程看到

Java 内存模型 (JMM): Java虚拟机规范中定义了Java内存模型.

目的是屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的并发效果.

在这里插入图片描述

线程之间的共享变量存在主内存 (Main Memory)即内存
每一个线程都有自己的 “工作内存” (Working Memory) 即CPU寄存器
当线程要读取一个共享变量的时候, 会先把变量从主内存拷贝到工作内存, 再从工作内存读取数据.
当线程要修改一个共享变量的时候, 也会先修改工作内存中的副本, 再同步回主内存.

由于每个线程有自己的工作内存, 这些工作内存中的内容相当于同一个共享变量的 “副本”. 此时修改线程1 的工作内存中的值, 线程2 的工作内存不一定会及时变化

初始情况下, 两个线程的工作内存内容一致
一旦线程1 修改了 a 的值, 此时主内存不一定能及时同步. 对应的线程2 的工作内存的 a 的值也不一定能及时同步.

上述情况就是前面所说的如果t2修改了该值，此时主内存的值不一定能及时同步，t1就感知不到也不能及时同步，从而产生错误，产生了线程不安全。

解决办法：

使用 volatile 关键字，它能够保证内存可见性，禁止编译器做出上述优化，而 synchronized 不能保证内存可见性！

拓展：synchronized 不能保证内存可见性的体现

在这里插入图片描述

2.4 代码重排序

一段代码是这样的：

去前台取下 U 盘
去教室写 10 分钟作业
去前台取下快递

如果是在单线程情况下，JVM、CPU指令集会对其进行优化，比如，按 1->3->2的方式执行，也是没问题，可以少跑一次前台。这种叫做指令重排序

编译器对于指令重排序的前提是 “保持逻辑不发生变化”. 这一点在单线程环境下比较容易判断, 但是在多线程环境下就没那么容易了, 多线程的代码执行复杂程度更高, 编译器很难在编译阶段对代码的执行效果进行预测, 因此激进的重排序很容易导致优化后的逻辑和之前不等价

注意：

代码重排序也是编译器优化的一种操作，同样在多线程中会出现误判

解决办法：

使用 volatile 关键字进行加锁

至于为什么不用 synchronized 不能禁止重排序？请参考！！

三、总结

线程不安全的万恶之源是由于线程是抢占式执行的，随机无序的，我们无法避免，只能通过方案来应对。以上介绍的几种情况都可能造成线程不安全，并且也是我们日常写代码高频出现的问题。对其解决办法就是进行一系列的加锁操作，但是加锁后会降低线程的并发程度，降低效率所以我们也需要结合实际，考虑如何适当加锁。上面的加锁操作我们会在后面仔细讲解