[多线程】线程安全问题

最新推荐文章于 2024-05-21 10:23:42 发布

老cu

最新推荐文章于 2024-05-21 10:23:42 发布

阅读量113

点赞数 5

文章标签： java 前端开发语言

本文链接：https://blog.csdn.net/weixin_64173948/article/details/134615867

版权

4.解决线程的不安全问题-（synchronized）

1.举个栗子

我们用两个线程来分别计算同一个数值各自自增5000次，在理想状态下，两次分别自增。这个数值应该是10000。那么实际情况呢？我们通过代码来演示一下：

class Counter {
    public int count = 0;
    void increase() {
        count++;
    }
}
public class TheadDdemo1 {
    public static void main(String[] args) throws InterruptedException {
         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);
    }
}

可以看出，实际结果和我们预期的不一样。那么为什么会出现这种情况呢？

2.线程安全的概念

我们可以这样认为，如果在多线程环境下代码运行的结果是符合我们预期的，即在单线程环境下应该有的结果，那么就说明这个线程是安全的。

3.线程不安全的原因

上述线程不安全的代码中，涉及到了多个线程对于count的修改。

此时这个count是一个多个线程都可以访问到的共享数据。

3.1原子性

那么什么是原子性呢？我们把一段代码想象成一个房间，每个线程都是可以进入这个房间的人，如果没有任何机制的保证，那么这个房间任何人任何时候都可以进去。这就不具备原子性了。

但是如果我们给这个房间加上一把锁，在一个人（线程）进入了这个房间以后，其它的人就进不来了，这样就保证了这段代码的原子性了。

一条Java语句不一定是原子的，也不一定只有一条指令。

比如刚才的count++,实际上是由三步操作组成的：

1.从内存中获取到数据存到cpu寄存器中

2.通过cpu寄存器给数据+1

3.把数据写回到内存中

如果一个线程正在对一个数据操作，中途其它的线程插进来了，那么这个操作就有可能被打断了，结果就有可能是错误的。这点也和线程的抢占试运行调度有关。

3.2Java内存模型（jvm）

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

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

2) 一旦线程1 修改了 a 的值, 此时主内存不一定能及时同步. 对应的线程2 的工作内存的 a 的值也不一定能及时同步.
这个时候代码中就容易出现问题.

这个时候我们就有两个疑问:

1.为什么要有这么多内存

2.为什么要这么麻烦的拷来拷去

问题1：
实际上并没有这么多内存，这只是Java规范中的一个术语，是属于抽象的叫法：

所谓的主内存才是硬件角度真正的内存，而工作内存，则是CPU中的寄存器和高速缓存。

问题2：

因为 CPU 访问自身寄存器的速度以及高速缓存的速度, 远远超过访问内存的速度(快了 3 - 4 个数量级, 也就是几千倍, 上万倍).
比如某个代码中要连续 10 次读取某个变量的值, 如果 10 次都从内存读, 速度是很慢的. 但是如果
只是第一次从内存读, 读到的结果缓存到 CPU 的某个寄存器中, 那么后 9 次读数据就不必直接访问
内存了. 效率就大大提高了.
那么接下来问题又来了, 既然访问寄存器速度这么快, 还要内存干啥??
答案就是一个字: 贵

3.3代码重排序

一段代码是这样的

1.去菜鸟驿站取水果

2.去图书馆学习

3.去菜鸟驿站取衣服

如果是在单线程情况下，JVM、CPU指令集会对其进行优化，比如，按 1->3->2的方式执行，也是没问题，可以少跑一次菜鸟驿站。这种叫做指令重排序。
编译器对于指令重排序的前提是 "保持逻辑不发生变化". 这一点在单线程环境下比较容易判断, 但
是在多线程环境下就没那么容易了, 多线程的代码执行复杂程度更高, 编译器很难在编译阶段对代
码的执行效果进行预测, 因此激进的重排序很容易导致优化后的逻辑和之前不等价。

4.解决线程的不安全问题-（synchronized）

在Java中我们使用了synchronized关键字来解决线程安全问题。

我们先用一段代码来演示一下：

class Counter {
    public int count = 0;
   synchronized void increase() {
        count++;
    }
}
public class TheadDdemo1 {
    public static void main(String[] args) throws InterruptedException {
         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);
    }
}

可以看出，加了sychronized关键字以后，程序运行结果和我们预期中的一样了。

4.1sychronized的特性

1.互斥

synchronized 会起到互斥效果, 某个线程执行到某个对象的 synchronized 中时, 其他线程如果也执行到同一个对象 synchronized 就会阻塞等待
进入 synchronized 修饰的代码块, 相当于加锁
退出 synchronized 修饰的代码块, 相当于解锁

synchronized用的锁是存在Java对象头里的。
可以粗略理解成, 每个对象在内存中存储的时候, 都存有一块内存表示当前的 "锁定" 状态(类似于厕
所的 "有人/无人").
如果当前是 "无人" 状态, 那么就可以使用, 使用时需要设为 "有人" 状态.
如果当前是 "有人" 状态, 那么其他人无法使用, 只能排队

针对每一把锁, 操作系统内部都维护了一个等待队列. 当这个锁被某个线程占有的时候, 其他线程尝试进行加锁, 就加不上了, 就会阻塞等待, 一直等到之前的线程解锁之后, 由操作系统唤醒一个新的线程, 再来获取到这个锁.
注意:
1.上一个线程解锁之后, 下一个线程并不是立即就能获取到锁. 而是要靠操作系统来 "唤醒". 这
也就是操作系统线程调度的一部分工作.
2.假设有 A B C 三个线程, 线程 A 先获取到锁, 然后 B 尝试获取锁, 然后 C 再尝试获取锁, 此时 B
和 C 都在阻塞队列中排队等待. 但是当 A 释放锁之后, 虽然 B 比 C 先来的, 但是 B 不一定就能
获取到锁, 而是和 C 重新竞争, 并不遵守先来后到的规则.

synchronized的底层是使用操作系统的mutex lock实现的.

4.2刷新内存

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

4.3可重入

synchronized 同步块对同一条线程来说是可重入的，不会出现自己把自己锁死的问题
一个线程没有释放锁, 然后又尝试再次加锁

把自己锁死：
/ 第一次加锁, 加锁成功
lock();
// 第二次加锁, 锁已经被占用, 阻塞等待.
lock();

按照之前对于锁的设定, 第二次加锁的时候, 就会阻塞等待. 直到第一次的锁被释放, 才能获取到第
二个锁. 但是释放第一个锁也是由该线程来完成, 结果这个线程已经躺平了, 啥都不想干了, 也就无
法进行解锁操作. 这时候就会死锁，，这样的锁被称为不可重入锁。

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

在可重入锁的内部, 包含了 "线程持有者" 和 "计数器" 两个信息.
如果某个线程加锁的时候, 发现锁已经被人占用, 但是恰好占用的正是自己, 那么仍然可以继续获取
到锁, 并让计数器自增.
解锁的时候计数器递减为 0 的时候, 才真正释放锁. (才能被别的线程获取到)

5.synchornized使用实例

synchornized本质上是要修改指定对象的“对象头”，从使用角度来看，synchronized也要搭配一个具体的对象来使用

在上面我们直接写在方法前面

和下面这种写法本质上是一样的

它们都是代表对象的引用。

锁类对象：

Object对象：

synchronized 锁的是什么. 两个线程竞争同一把锁, 才会产生阻塞等待.
两个线程分别尝试获取两把不同的锁, 不会产生竞争.

5.1Java标准库中的线程安全类

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

老cu

关注

5
点赞
踩
4

收藏

觉得还不错? 一键收藏
打赏
4
评论
[多线程】线程安全问题

针对每一把锁, 操作系统内部都维护了一个等待队列. 当这个锁被某个线程占有的时候, 其他线程尝试进行加锁, 就加不上了, 就会阻塞等待, 一直等到之前的线程解锁之后, 由操作系统唤醒一个新的线程, 再来获取到这个锁.这点也和线程的抢占试运行调度有关。我们可以这样认为，如果在多线程环境下代码运行的结果是符合我们预期的，即在单线程环境下应该有的结果，那么就说明这个线程是安全的。2) 一旦线程1 修改了 a 的值, 此时主内存不一定能及时同步. 对应的线程2 的工作内存的 a 的值也不一定能及时同步.
复制链接

扫一扫