【多线程】线程安全问题原因与解决方案

这篇具有很好参考价值的文章主要介绍了【多线程】线程安全问题原因与解决方案。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录

线程安全的概念

线程不安全示例

线程不安全的原因 

    多个线程修改了同一个变量

    线程是抢占式执行的

    原子性

    内存可见性

    有序性

线程不安全解决办法

 synchronized 关键字-监视器锁monitor lock

    synchronized 的特性

        互斥

        刷新内存

        可重入

    synchronized 使用示例

    Java 标准库中的线程安全类

volatile 关键字

    volatile 能保证内存可见性

    volatile 不保证原子性

    synchronized 也能保证内存可见性


线程安全的概念

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

线程不安全示例

public class Insecurity {

    // 定义自增操作的对象
    private static Counter counter = new Counter();

    public static void main(String[] args) throws InterruptedException {
        // 定义两个线程,分别自增5万次
        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 50000; i++) {
                counter.increment();
            }
        });

        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 50000; i++) {
                counter.increment();
            }
        });

        // 启动线程
        t1.start();
        t2.start();
        // 等待自增完成
        t1.join();
        t2.join();
        // 打印结果
        System.out.println("count = " + counter.count);

    }
}

class Counter {
    public int count = 0;
    // 自增方法
    public void increment () {
        count++;
    }
}

【多线程】线程安全问题原因与解决方案

线程不安全的原因 

    多个线程修改了同一个变量

上面的线程不安全的代码中 , 涉及到多个线程针对 counter.count 变量进行修改。
counter.count 这个变量就是在堆上. 因此可以被多个线程共享访问.

    线程是抢占式执行的

多个线程在CPU上调度是随机的,顺序是不可预知的。

    原子性

要么都执行,要么都不执行。

  1. 从内存把数据读到 CPU
  2. 进行数据更新
  3. 把数据写回到 CPU

【多线程】线程安全问题原因与解决方案

    内存可见性

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

Java 内存模型 (JMM) : Java 虚拟机规范中定义了 Java 内存模型 .
目的是屏蔽掉各种硬件和操作系统的内存访问差异,以实现让 Java 程序在各种平台下都能达到一致的并发效果.

【多线程】线程安全问题原因与解决方案

  • 线程之间的共享变量存在 主内存 (Main Memory).
  • 每一个线程都有自己的 "工作内存" (Working Memory) .
  • 当线程要读取一个共享变量的时候, 会先把变量从主内存拷贝到工作内存, 再从工作内存读取数据.
  • 当线程要修改一个共享变量的时候, 也会先修改工作内存中的副本, 再同步回主内存.
由于每个线程有自己的工作内存 , 这些工作内存中的内容相当于同一个共享变量的 " 副本 ". 此时修改线程1 的工作内存中的值 , 线程 2 的工作内存不一定会及时变化

    有序性

有序性是指编译过程中,JVM调用本地接口,CPU执行指令过程中,指令的有序性。

指令在特殊情况下会打乱顺序,并不是按程序员的预期去执行的。

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

线程不安全解决办法

对于多线程修改同一个变量,在真实业务中都是修改同一个变量,无法避免。

对于线程是抢占式执行的,CPU调度是随机的,这里CPU是硬件层面,没办法处理。

剩下就是解决其他三个原因:

public class Main {

    // 定义自增操作的对象
    private static Counter counter = new Counter();

    public static void main(String[] args) throws InterruptedException {
        // 定义两个线程,分别自增5万次
        Thread t1 = new Thread(() -> {
            for (int i = 0; i < 50000; i++) {
                counter.increment();
            }
        });

        Thread t2 = new Thread(() -> {
            for (int i = 0; i < 50000; i++) {
                counter.increment();
            }
        });

        // 启动线程
        t1.start();
        t2.start();
        // 等待自增完成
        t1.join();
        t2.join();
        // 打印结果
        System.out.println("count = " + counter.count);

    }
}

class Counter {
    public volatile int count = 0;
    // 自增方法
    public synchronized void increment () {
        count++;
    }
}

【多线程】线程安全问题原因与解决方案文章来源地址https://www.toymoban.com/news/detail-461668.html

 synchronized 关键字-监视器锁monitor lock

    synchronized 的特性

        互斥

synchronized 会起到互斥效果 , 某个线程执行到某个对象的 synchronized 中时 , 其他线程如果也执行到同一个对象 synchronized 就会 阻塞等待
  • 进入 synchronized 修饰的代码块, 相当于 加锁
  • 退出 synchronized 修饰的代码块, 相当于 解锁
synchronized 用的锁是存在 Java 对象头里的。
可以粗略理解成 , 每个对象在内存中存储的时候 , 都存有一块内存表示当前的 " 锁定 " 状态 ( 类似于厕所的 " 有人 / 无人 ").
如果当前是 " 无人 " 状态 , 那么就可以使用 , 使用时需要设为 " 有人 " 状态 .
如果当前是 " 有人 " 状态 , 那么其他人无法使用 , 只能排队
理解 " 阻塞等待 ".
针对每一把锁 , 操作系统内部都维护了一个等待队列 . 当这个锁被某个线程占有的时候 , 其他线程尝试进行加锁, 就加不上了 , 就会阻塞等待 , 一直等到之前的线程解锁之后 , 由操作系统唤醒一个新的线程, 再来获取到这个锁 .
注意 :
  • 上一个线程解锁之后, 下一个线程并不是立即就能获取到锁. 而是要靠操作系统来 "唤醒". 这也就是操作系统线程调度的一部分工作.
  • 假设有 A B C 三个线程, 线程 A 先获取到锁, 然后 B 尝试获取锁, 然后 C 再尝试获取锁, 此时 B和 C 都在阻塞队列中排队等待. 但是当 A 释放锁之后, 虽然 B C 先来的, 但是 B 不一定就能获取到锁, 而是和 C 重新竞争, 并不遵守先来后到的规则.
synchronized 的底层是使用操作系统的 mutex lock 实现的 .

        刷新内存

synchronized 的工作过程 :
  1. 获得互斥锁
  2. 从主内存拷贝变量的最新副本到工作的内存
  3. 执行代码
  4. 将更改后的共享变量的值刷新到主内存
  5. 释放互斥锁
所以 synchronized 也能保证内存可见性 . 具体代码参见后面 volatile 部分 .

        可重入

synchronized 同步块对同一条线程来说是可重入的,不会出现自己把自己锁死的问题;
理解 " 把自己锁死 "
一个线程没有释放锁 , 然后又尝试再次加锁 .
代码示例
在下面的代码中 ,
  • increase increase2 两个方法都加了 synchronized, 此处的 synchronized 都是针对 this 当前对象加锁的.
  • 在调用 increase2 的时候, 先加了一次锁, 执行到 increase 的时候, 又加了一次锁. (上个锁还没释放, 相当于连续加两次锁)
这个代码是完全没问题的 . 因为 synchronized 是可重入锁 .
static class Counter {
    public int count = 0;
    synchronized void increase() {
        count++;
   }
    synchronized void increase2() {
        increase();
   }
}
在可重入锁的内部 , 包含了 " 线程持有者 " " 计数器 " 两个信息 .
  • 如果某个线程加锁的时候, 发现锁已经被人占用, 但是恰好占用的正是自己, 那么仍然可以继续获取到锁, 并让计数器自增.
  • 解锁的时候计数器递减为 0 的时候, 才真正释放锁. (才能被别的线程获取到)

    synchronized 使用示例

synchronized 本质上要修改指定对象的 " 对象头 ". 从使用角度来看 , synchronized 也势必要搭配一个具体的对象来使用.
1) 直接修饰普通方法 : 锁的 SynchronizedDemo 对象
public class SynchronizedDemo {
    public synchronized void methond() {
   }
}
2) 修饰静态方法 : 锁的 SynchronizedDemo 类的对象
public class SynchronizedDemo {
    public synchronized static void method() {
   }
}
3) 修饰代码块 : 明确指定锁哪个对象
锁当前对象
public class SynchronizedDemo {
    public void method() {
        synchronized (this) {
            
       }
   }
}
锁类对象
public class SynchronizedDemo {
    public void method() {
        synchronized (SynchronizedDemo.class) {
       }
   }
}

    Java 标准库中的线程安全类

Java 标准库中很多都是线程不安全的 . 这些类可能会涉及到多线程修改共享数据 , 又没有任何措施 .
  • ArrayList
  • LinkedList
  • HashMap
  • TreeMap
  • HashSet
  • TreeSet
  • StringBuilder
但是还有一些是线程安全的 . 使用了一些锁机制来控制 .
  • Vector (不推荐使用)
  • HashTable (不推荐使用)
  • ConcurrentHashMap
  • StringBuffer
StringBuffer 的核心方法都带有 synchronized
还有的虽然没有加锁 , 但是不涉及 " 修改 ", 仍然是线程安全的
  • String

volatile 关键字

    volatile 能保证内存可见性

volatile 修饰的变量 , 能够保证 " 内存可见性 ".
代码在写入 volatile 修饰的变量的时候 ,
  • 改变线程工作内存中volatile变量副本的值
  • 将改变后的副本的值从工作内存刷新到主内存
代码在读取 volatile 修饰的变量的时候 ,
  • 从主内存中读取volatile变量的最新值到线程的工作内存中
  • 从工作内存中读取volatile变量的副本
前面我们讨论内存可见性时说了 , 直接访问工作内存 ( 实际是 CPU 的寄存器或者 CPU 的缓存 ), 速度非常快, 但是可能出现数据不一致的情况 .
加上 volatile , 强制读写内存 . 速度是慢了 , 但是数据变的更准确了 .
代码示例
在这个代码中
  • 创建两个线程 t1 t2
  • t1 中包含一个循环, 这个循环以 flag == 0 为循环条件.
  • t2 中从键盘读入一个整数, 并把这个整数赋值给 flag.
  • 预期当用户输入非 0 的值的时候, t1 线程结束.
static class Counter {
    public int flag = 0;
}
public static void main(String[] args) {
    Counter counter = new Counter();
    Thread t1 = new Thread(() -> {
        while (counter.flag == 0) {
            // do nothing
       }
        System.out.println("循环结束!");
   });
    Thread t2 = new Thread(() -> {
        Scanner scanner = new Scanner(System.in);
        System.out.println("输入一个整数:");
        counter.flag = scanner.nextInt();
   });
    t1.start();
    t2.start();
}
// 执行效果
// 当用户输入非0值时, t1 线程循环不会结束. (这显然是一个 bug)
t1 读的是自己工作内存中的内容 .
t2 flag 变量进行修改 , 此时 t1 感知不到 flag 的变化 .
如果给 flag 加上 volatile
static class Counter {
    public volatile int flag = 0;
}
// 执行效果
// 当用户输入非0值时, t1 线程循环能够立即结束.

    volatile 不保证原子性

volatile synchronized 有着本质的区别 . synchronized 能够保证原子性 , volatile 保证的是内存可见性.
代码示例
这个是最初的演示线程安全的代码 .
  • increase 方法去掉 synchronized
  • count 加上 volatile 关键字.
static class Counter {
    volatile 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);
}
此时可以看到 , 最终 count 的值仍然无法保证是 100000.

    synchronized 也能保证内存可见性

synchronized 既能保证原子性 , 也能保证内存可见性 .
对上面的代码进行调整 :
  • 去掉 flag volatile
  • t1 的循环内部加上 synchronized, 并借助 counter 对象加锁.
static class Counter {
    public int flag = 0;
}
public static void main(String[] args) {
    Counter counter = new Counter();
    Thread t1 = new Thread(() -> {
        while (true) {
            synchronized (counter) {
                if (counter.flag != 0) {
                    break;
               }
           }
            // do nothing
       }
        System.out.println("循环结束!");
   });
    Thread t2 = new Thread(() -> {
        Scanner scanner = new Scanner(System.in);
        System.out.println("输入一个整数:");
        counter.flag = scanner.nextInt();
   });
    t1.start();
    t2.start();
}

到了这里,关于【多线程】线程安全问题原因与解决方案的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 主从同步的延迟问题、原因及解决方案

    主从同步的延迟问题、原因及解决方案 MySQL的主从同步在实际使用过程中会有从库延迟的问题,那么为什么会有这种问题呢? 如何避免这种问题呢? 情况一: 从服务器配置过低导致延迟 这类延迟场景的出现往往是主节点拥有较大规格的配置,而只读节点却购买了一个最小规格的

    2024年02月16日
    浏览(46)
  • 从原因到解决方案,深入剖析网络错误问题

    当计算机系统中的客户端(例如浏览器、应用程序等)尝试连接到远程服务器时,网络连接错误是一种常见的问题。这种错误可能会对用户造成很大的困扰,因为它可能导致无法访问网站或无法使用某些在线应用程序。而网络错误其实是我们日常开发中很难完全避免掉的一个

    2024年02月07日
    浏览(63)
  • 【多线程基础】 线程安全及解决方案(看这一篇就够了)

    🎉🎉🎉 点进来你就是我的人了 博主主页: 🙈🙈🙈戳一戳,欢迎大佬指点! 欢迎志同道合的朋友一起加油喔 🦾🦾🦾 目录 前言 1. 造成线程不安全的原因有哪些呢? 1.1什么是原子性 1.2什么是内存可见性 1.3共享变量可见性实现的原理  1.4 什么是指令重排序 2.解决线程安全

    2024年02月02日
    浏览(47)
  • 安卓之导致ANR的原因分析,问题定位以及解决方案

            在Android应用开发中,Application Not Responding(ANR)是一种常见的性能问题,它直接关系到用户体验的质量。当应用在特定时间段内无法及时响应用户的交互或者系统事件时,系统将会抛出ANR错误,提示用户应用已停止响应。为了确保应用的流畅性和用户满意度,理解

    2024年03月13日
    浏览(53)
  • 鸿蒙ArkTS Web组件加载空白的问题原因及解决方案

    初学鸿蒙开发,按照官方文档Web组件文档《使用Web组件加载页面》示例中的代码照抄运行后显示空白,纠结之余多方搜索后扔无解决方法。 无意间gitee搜索鸿蒙web组件项目代码时看到 Web组件抽奖案例(ArkTS) Readme文档中有一句话,如下: 本篇Codelab使用了在线网页,需要在配

    2024年02月04日
    浏览(73)
  • 电脑启动后出现白屏问题的可能原因及解决方案

    电脑开机后出现白屏问题是一种常见的故障,可能由多种原因引起。在本文中,我将介绍一些可能的原因,并提供相应的解决方案,以帮助您解决这个问题。 显示器故障:首先,检查显示器是否正常工作。可以尝试连接另一个显示器或电视,看看是否仍然出现白屏问题。如果

    2024年02月04日
    浏览(46)
  • Kafka重复消费以及消费线程安全关闭的解决方案

    Kafka消费程序每次重启都会出现重复消费的情况,考虑是在kill掉程序的时候,有部分消费完的数据没有提交offsect。 此处表明自动提交,即延迟提交(poll的时候会根据配置的自动提交时间间隔去进行检测并提交)。当kill掉程序的时候,可能消费完的数据还没有到达提交的时间

    2024年02月13日
    浏览(50)
  • 外部navicat无法连接mysql数据库的问题原因及解决方案

    问题起因是这样:在linux操作中的docker中部署了一个数据库,数据库启动之后,端口也映射了(创建容器时用 -p 30036:3306进行的映射),但是在外不想使用navicat连接时,怎么都连不上,本人遇到的问题如下 一、端口虽然映射了,但是服务器上的30036端口并未对外开放,因此要先开

    2024年02月07日
    浏览(56)
  • Class path contains multiple SLF4J bindings.问题原因及解决方案

    问题背景 在进行logback的日志输出测试时,显示如下错误 2、原因 根据上面的错误提示,存在多个SLF4J bindings绑定,即存在多个slf4j的实现类,按上图所示这两个实现分别是 logback-classic-1.2.6和slf4j-log4j12-1.6.1 ,我们需要的是logback而不是log4j, 3、解决方案 因此,我们去掉log4j的

    2024年02月11日
    浏览(44)
  • 【网络连接】ping不通的常见原因+解决方案,如何在只能访问网关时诊断,并修复IP不通的问题

    🌈你好呀!我是 是Yu欸 🌌 2024每日百字篆刻时光,感谢你的陪伴与支持 ~ 🚀 欢迎一起踏上探险之旅,挖掘无限可能,共同成长! 前些天发现了一个人工智能学习网站,内容深入浅出、易于理解。如果对人工智能感兴趣,不妨点击查看。 粉丝交流贴:网关能通IP不通可能有

    2024年03月09日
    浏览(205)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包