2023.10.10 关于线程安全问题

茂大师

已于 2023-10-31 00:05:01 修改

阅读量168

点赞数 1

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

于 2023-10-12 20:14:25 首次发布

本文链接：https://blog.csdn.net/weixin_63888301/article/details/133758215

版权

多线程专栏收录该内容

14 篇文章 0 订阅

订阅专栏

抢占式执行

指令重排序

对于实例一

对于实例二

volatile 关键字

Java 内存模型 JMM（Java Memory Model）

修改后运行结果

Java 标准库中线程安全的类

多线程环境使用 ArrayList

线程安全问题实例一

class Counter {
    public int count = 0;
    
    public void add() {
        count++;
    }
}

public class ThreadDemo13 {
    public static void main(String[] args) throws InterruptedException {
        Counter counter = new Counter();
//        搞两个线程，这两个线程分别针对 counter 来调用 5w 次的 add 方法
        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 50000; i++) {
                counter.add();
            }
        });
        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 50000; i++) {
                counter.add();
            }
        });
//        启动线程
        t1.start();
        t2.start();
//        等待两个线程结束
        t1.join();
        t2.join();
//        打印最终的 count 值
        System.out.println("count = " + counter.count);
    }
}
运行结果：

我们通过两个线程各执行 5000 次 count 自增操作，count 的理想结果应为 100000，但是运行结果却相差甚大
我们运行两次该代码，发现两次运行的结果也不同

了解 count++ 操作

该操作本质上要分成三步
先把内存中的值，读取到 CPU 寄存器中（load）
再把 CPU 寄存器里的数值进行 +1 运算（add）
最后把得到的结果写回到内存中（save）

引发线程安全的原因

抢占式执行

多线程的调度是随机且毫无规律的
抢占式执行是线程不安全的主要原因

多线程修改同一变量

依据开头实例，两个线程并发执行对同一变量进行自增 5000 的操作，运行结果与期望值不符

出现问题的关键是线程t1 和线程t2 的 load 指令
两个线程 load 的 count 值均为对方修改 count 之后的值，此时是安全的，否则不安全

补充：

String 是不可变对象，其天然就是线程安全的
erlang 这个编程语言，其语法中就不存在变量这一概念，所有的数据都是不可变的，这样的语言更适合并发编程，其出现线程安全问题的概率大大降低

操作的原子性

针对解决线程安全问题，从操作原子性入手是主要的手段
原子为不可被拆分的基本单位
count++ 操作分为三个 CPU 指令，像 load、add、save 这样的 CPU 执行指令符合原子性的特点
也正是因为 count++ 操作不是原子性的，从而会导致线程不安全的情况
但是如果将 count++ 操作的三个CPU指令，包装成一个原子操作，这三个要么全部一起执行，要么不执行，在执行这三个指令时，CPU不能调度执行其他指令，从而就能很好的解决上述实例所出现的问题

指令重排序

本质是编译器优化出现 bug
编译器会根据你写的代码，在保持逻辑不变的前提下，进行相应的优化，调整代码的执行顺序，从而加快程序的执行效率

内存可见性问题

指一个线程在使用对象状态时另一个线程在同时修改该状态
我们需要确保当一个线程修改了对象状态后，其他线程能够看到发生的状态变化
如果看不到修改后的变化，便会出现安全问题
编译器优化也会造成内存可见性问题

总结：

以上五种为典型原因，并不是全部原因
一个代码的线程安全与否，主要应该具体对其进行分析，不能一概而论
运行多线程代码，只要其没有 bug，就是安全的

线程安全问题实例二

该实例基于指令重排序和内存可见性问题
import java.util.Scanner;

class Test {
    public int count = 0;
}

public class ThreadDemo14 {
    public static void main(String[] args) {
        Test test = new Test();

        Thread t1 = new Thread(() -> {
                while (test.count == 0) {
                }
        });

        Thread t2 = new Thread(() -> {
                System.out.println("请输入一个数字，改变 count 值");
                Scanner scanner = new Scanner(System.in);
                test.count = scanner.nextInt();
        });

        t1.start();
        t2.start();
    }
}
运行结果：

代码整体逻辑：

线程t1 的工作内容是通过 while 循环快速且不断对 count 值进行读取并与 0 进行大小比较
线程t2 的工作内容是读取控制台输入的数字 1，并将其赋值给 count 变量
预期结果：当线程t2 将 count 值改变时，此时线程t1 读取到 count != 0 ，从而能够直接结束 while 循环，线程t1 和线程t2 均运行完成，程序停止运行
实际结果：线程t2 将 count 值改为 1 后，程序仍未停止，说明线程t1 并未结束 while 循环

预期结果与实际结果不一致原因：

线程t1 的 while(test.count == 0) 分为两个步骤
从内存中读取 count 的值到寄存器中（load 指令）
在寄存器中的 count 与 0 进行值比较（cmp 指令）
因为 while 内无额外逻辑代码，所以这两个指令会十分快速的循环执行
CPU 读写数据最快，内存次之，硬盘最慢，且他们之间均相差 3~4个数量级
所以相比 load 指令要不断从内存中读取数据，cmp 指令直接在 CPU 上进行执行就要慢了很多很多
编译器快速频繁的 load 读取 count 值，且多次 load 的 count 值还是一样的
因为一般没有人能修改该代码，所以此时编译器就会认为反正读到的结果都是固定的，直接将代码优化为仅读取一次 count 值，此时代码的效率就会显著提高
这时我们的线程t2 读取控制台输入的数字 1 并赋值给了 count
但是因为编译器将 while(test.count == 0) 代码优化成了仅读取一次 count 值，所以程序并不会因为线程t2 将 count 值修改为了 1 从而结束循环、结束程序执行
从而上述是一个典型的内存可见性问题和指令重排序问题（编译器优化问题）

总结：

编译器优化在多线程情况下可能存在误判的情况

如何解决上述线程安全问题

对于实例一

为了将 count++ 操作的三个指令包装成一个原子操作，我们可以进行加锁操作
使用 synchronized 关键字来修饰普通方法 add ，当执行进入该方法时，就会加锁，直到该方法执行完毕，就会解锁

如果两个线程同时尝试加锁，此时一个能获取锁成功，另一个只能阻塞等待（BLOCKED）一直阻塞到刚才的线程释放锁（解锁），当前线程才能加锁成功

synchronized 关键字的引入，每次执行 add 方法时都多了加锁和解锁的操作，有原来的并发执行转变为串行执行，从而减慢了执行效率，但是保证了线程的安全性
所以我们需要根据需求进行分析取舍，只追求校率，不再乎准确率，可以不加锁，如果以准确率为前提条件，加锁操作就显得十分有必要了

修改后运行结果

注意：

在加锁区间（lock -> unlock 区间）中，CPU 不是一定要一口气执行完，中间也是可以有调度切换的，即使执行到一半 CPU 调度切换执行其他，当其余线程要想获取该方法时，还是会被阻塞（BOLCKED），无法获取该方法
虽然加锁之后，代码执行效率降低了，但是还是要比单线程执行要快
因为加锁仅针对 count++ 加锁，但除了 count++ 外还有 for 循环代码，for循环代码可以并发执行，只是 count++ 变为串行执行，还是要比单线程全串行执行要快

对于实例二

volatile 关键字

volatile 关键字有两大作用
禁止指令重排序：保证指令执行的顺序，防止编译器优化而修改指令执行顺序，引发线程安全问题
保证内存可见性：保证了读取到的数据时内存中的数据，而不是缓存，简单来说就是当一个线程修改一个共享变量时，另一个线程能读到这个修改的值

Java 内存模型 JMM（Java Memory Model）

JMM 定义了Java 程序中多线程并发访问共享内存（主存）的行为规范
volatile 关键字禁止了编译器优化，避免了直接读取 CPU 寄存器中缓存的数据，而是每次重新读内存
站在 JMM 角度看 volatile
正常程序执行过程中，会把主内存的数据，先加载到工作内存中，再进行计算处理
编译器优化可能会导致不是每次都真的取读取主内存，而直接读取工作内存中的缓存数据（导致内存可见性问题）
而 volatile 的作用就是保证每次读取内存都是真的从主存中重写读取

修改后运行结果

Java 标准库中线程安全的类

Java 标准库中很多类都是线程不安全的，这些类可能会涉及到多线程修改共享数据，又没有任何加锁措施

ArrayList

LinkedList

HashMap

TreeMap

HashSet

TreeSet

StringBuilder

无线程安全问题时，可以放心使用
有线程安全问题时，可以手动加锁
相对于下方自带锁的类，不带锁的类拥有更多可选择的空间

多线程环境使用 ArrayList

自己使用 synchronized 或者 ReentrantLock 来进行加锁
Collections.synchronizedList，这里会提供一些 ArrayList 相关的方法，同时是带锁的，使用这个方法把集合类套一层
CopyOnWriteArrayList 简称 COW，也叫做 "写时拷贝"

COW 基本思路

如果针对这个 ArrayList 进行读操作，不做任何额外的工作
如果进行写操作，则拷贝一份新的 ArrayList，针对新的进行修改，修改过程中如果有读操作，就继续读旧的这份数据，当修改完毕了，使用新的替换旧的（本质上就是一个引用之间的赋值，原子的）
很明显，这种方案的优点时不需要加锁，缺点是要求这个 ArrayList 不能太大
只是适用于这种数组比较小的情况下

COW 适用场景

服务器程序的配置、维护

注意：

服务器程序的配置文件，可能会需要进行修改
修改配置可能就需要重启服务器才能生效
但重启操作可能成本比较高，如果有 20 台服务器，每台重启用时 5 分钟，总的重启时间就是 100分钟
此处的 20 台服务器绝对不能同时重启，如果全部同时重启，此时就会出现 5 分钟的服务中断，此时用户发起的请求就会没有任何响应，这是严重的事故
所以很多服务器都提供了 " 热加载"（reload）功能，通过这样的功能就能实现可以不重启服务器，实现配置的更新
新的配置放到新的对象中，加载过程中，请求任基于旧配置完成工作
当新的对象加载完毕，使用新的对象代替旧对象，旧对象也随之释放

以下是线程安全的类，使用了一些锁机制来控制，自己内置了 synchronized 加锁，相对更加安全

Vector（不推荐）
HashTable（不推荐）
ConcurrentHashMap
StringBuffer

强行加锁，无选择空间

还有虽然没有加锁，但是无法修改值为不可变对象，所以也是线程安全的

String

注意：

加锁这个操作有副作用，它会引入额外的时间开销
我们需根据实际需求进行分析取舍，从而选择出适合的类

茂大师

关注

1
点赞
踩
1

收藏

觉得还不错? 一键收藏
打赏
1
评论
2023.10.10 关于线程安全问题

线程安全问题实例一引发线程安全的原因抢占式执行多线程修改同一变量操作的原子性指令重排序内存可见性问题线程安全问题实例二对于实例一对于实例二volatile 关键字Java 内存模型 JMM（Java Memory Model）修改后运行结果Java 标准库中线程安全的类多线程环境使用 ArrayList
复制链接

扫一扫