多线程（五）：死锁&内存可见性问题

对于这种情况下的死锁, 这里也举个例子:

有的人喜欢吃饺子蘸醋, 有的人喜欢吃饺子蘸酱油. 过年时吃饺子, 饺子端上来后, 我拿起了桌子上的醋, 我妹妹拿起了桌子上的酱油, 我对妹妹说: "你把酱油给我!" 妹妹对我说:"凭啥, 你把醋给我!" 我们两个人互不相让, 就会构成死锁.

又或者说: 门钥匙锁车里了, 车钥匙锁家里了. 这也构成了一个死锁~

注意, 这种情况下的死锁, 必须是拿到第一把锁后, 再去拿第二把锁(不能释放第一把锁).

注意:

每个线程拿到第一把锁后进行sleep休眠操作的目的是: 确保t1拿到locker1, t2拿到locker2.

如果不加sleep, t1可能一口气拿到了locker1和locker2; t2也可能一口气拿到了locker2和locker1. 这样就构不成死锁了~

2.2.1 BLOCKED

线程因为竞争锁的缘故而发生阻塞, 这种状态就为BLCOKED：

2.2.2 手写死锁代码 [经典面试题]

对于C/C++方向来说, 直接一个线程加锁两次就OK.

可是对于我们Java程序员, synchronized具有可重入的特性, 所以我们就得通过两个线程, 两把锁, 精确控制好加锁的顺序, 以达到死锁效果.

public class Demo16 {
    public static void main(String[] args) {
        Object locker1 = new Object();
        Object locker2 = new Object();
        Thread t1 = new Thread(() -> {
            synchronized (locker1) {
                System.out.println("t1 的第一把锁");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
                synchronized (locker2) {
                    System.out.println("t1 尝试获取 t2 的锁");
                }
            }
        });

        Thread t2 = new Thread(() -> {
            synchronized (locker2) {
                System.out.println("t2 的第一把锁");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
                synchronized (locker1) {
                    System.out.println("t2 尝试获取 t1 的锁");
                }
            }
        });
        t1.start();
        t2.start();
    }
}

2.3 死锁 --- 情况3

N个线程M把锁, 在极端情况下会出现死锁.

对于这种情况下的死锁, 这里以一个经典模型来举例 --- 哲学家就餐问题.

一张桌子, 桌子上有一碗面条, 桌子周围坐着5个哲学家, 每个哲学家之间有一支筷子.

哲学家会随机触发两种状态:1. 思考人生(放下筷子, 思考) 2. 吃面条(拿起两支筷子)

5个哲学家相等于5个线程, 5支筷子相当于5把锁.

在大多数情况下, 哲学家们可以互不影响, 很好的生活. 但是在一些极端的情况下, 可能导致哲学家们都吃不到面条, 构成死锁.

比如, 同一时刻,每个哲学家都想吃面条, 他们都拿起左手边的筷子, 此时, 每个线程都没有右手边的筷子, 他们又不肯放下左手边的筷子, 每个人都一直等待, 导致每一个人都吃不了面条, 导致死锁发生.

虽然是在极端的情况下才会出现死锁, 但对于我们服务器开发, 服务器每天的访问量是巨大的, 即使发生死锁的概率极小, 也会产生很大的影响.

用温家宝总理的话就是:‌“多么小的问题，乘以13亿，都会变得很大”

3. 避免死锁的出现

死锁是一个很严重的bug, 我们要想避免死锁的出现, 就需要先去了解死锁是怎样构成的.

3.1 构成死锁的四个必要条件 ★★★

1. 锁是互斥/排他的. 线程1拿到锁(加锁)后, 线程2再想尝试获取锁, 就必须要阻塞等待.

这是锁的基本特性. 我们无法修改锁的特性来去避免死锁.

2. 锁是不可抢占的. 线程1拿到锁后, 线程2再想尝试获取锁, 就必须要等待线程1将锁释放, 而不能直至把锁强过来.

这同样也是锁的基本特性. 我们无法修改.

3. 请求和保持. 即线程1拿到锁1后, 不释放锁1的前提下, 再去获取锁2.

构成死锁的这项原因, 我们是可以通过修改代码来避免的. 就如上文所说的哲学家就餐问题, 如果哲学家中有人放下左手的筷子, 就可以避免死锁.

但是这种解决死锁的方法, 不够通用, 有些情况下, 确实是需要通过多个锁嵌套来进行安全的保障(synchronized的嵌套是很难避免的....)

4. 循环等待. 多个线程间, 多把锁之间的等待过程, 构成了"循环". 例如: A等待B, B等待C, C等待A(上文的吃饺子问题, 哲学家就餐问题)

我们可以通过破除循环等待来避免死锁的出现.

3.2 破除循环等待

通过约定好加锁的顺序, 来破除循环等待.

还是以刚才哲学家就餐的模型为例.

如果给每一根筷子编号, 规定哲学家(线程)先获取编号小的筷子(锁), 再获取编号大的筷子(锁), 这样以来, 每个人都可以吃到面条, 就可以破除循环等待, 避免出现死锁.

同样, 在锁嵌套导致出现死锁时, 也可以规定先获取编号小的锁, 再获取编号大的锁, 以此避免死锁的出现:

4. 死锁小结

死锁小结:

1. 构成死锁的场景

a) 一个线程一把锁, 重复获取 --> 可重入锁

b) 两个线程两把锁, 尝试获取对方锁 --> 代码

c) N个线程M把锁 --> 哲学家就餐

2. 构成死锁的4个必要条件

a) 锁的互斥

b) 锁不可抢占

c) 请求和保持

d) 循环等待

3. 破除死锁

破除 c) --> 将嵌套锁改成并列锁(不通用)

破除 d) --> 规定加锁的顺序

5. Java标准库中的线程安全类

Java 标准库中很多都是线程不安全的, 下列结合类中没有进行任何加锁的限制:

ArrayList
LinkedList
HashMap
TreeMap
HashSet
TreeSet
StringBuilder

也有线程安全类, 在关键方法上加了synchronized来修饰:

Vector (不推荐使用)
HashTable (不推荐使用)
ConcurrentHashMap(HashTable 的高度优化版本)
StringBuffer

有的类虽然是线程安全的, 但是并不推荐使用(前两个).

因为加锁并不是没有代价的, 加上锁后, 意味着会发生锁冲突(锁竞争), 一旦发生锁竞争就会阻塞等待离开cpu的调度, 而再被调度回来需要多长时间就不得而知.

加锁一个是等价交换的买卖, 就是使用效率换取安全.

综上, 加锁意味着执行效率将大打折扣. 所以加锁时一定要思考清楚, 不要乱加锁.

还有一类, 虽然没有加锁操作, 但是不涉及修改, 依然是线程安全的:

String

6. 内存可见性问题 --- 线程安全问题的产生原因之一

在上篇博客中, 给大家提到了内存可见性问题是造成线程安全问题的原因之一.

这篇博客, 就来给大家详细分析一下内存可见性问题.

6.1 引入内存可见性问题

首先大家来看以下代码:

当t2线程中修改了flag值后, t1线程依旧继续执行, 说明t1线程没有读取到t2线程所修改的值:

很明显, 上述代码也是一个有线程安全问题的代码, 而这个bug的产生, 就是因为内存可见性问题引起的.

内存可见性问题: 一个线程读取值, 一个线程修改值, 修改线程修改的值, 没有被读取线程读到.

6.2 编译器优化

为了提高程序效率, 研发JDK的大佬们就对编译器/JVM 进行了这样的设置, 使其能够对我们程序员写的代码自动进行优化, 使程序的效率提高. 要知道程序员的水平是参差不齐的, 有的程序员写出的代码很长很冗余, 那JVM 就会在保证代码原有逻辑不变的基础上, 进行调整, 使程序的效率提高.

虽然声称是优化操作, 但仍避免不了错误的出现, 尤其是在多线程程序中, 编译器的判断可能会失误, 使得优化后的代码, 和优化前的代码, 出现偏差.

而我们上文提到的内存可见性问题, 就是由于编译器优化而产生的.

cmp是纯cpu寄存器操作, 而flag值的获取, 需要从内存读(load)到寄存器上. 而load的时间开销是cmp的几千倍, 所以此时t1线程中的读内存操作是影响效率的关键因素, 因此进行了编译器优化...

t1中, 循环的速度是很快的,1s就能转个几千万上亿次, 而过了很久后(对JVM来说),用户才对flag进行修改.JVM就会认为flag的值是不变的(一直为0), 而每次都要读内存, 太慢了~于是就将读取内存的操作, 优化成读取寄存器的操作(将值读到寄存器中, 下次直接从寄存器中取). 所以等好几秒后, flag的值被修改后, t1线程就感知不到了.(编译器优化, 使得读操作从读内存优化成读寄存器)

而, 如果我们对代码进行微调:

发现, t1中只需加了休眠1ms的操作后, 就能正常结束.

这是因为, 循环的速度很快,1s就能转个几千万上亿次, 而加了休眠操作后, 即使是1ms, 也将大幅度降低循环的速度, 此时的休眠操作成了影响程序效率的主要因素, 相比来说, flag读取操作的开销(ns级别)将不值一提, 对读内存操作的优化也将无足轻重, 于是JVM便不再对读内存的操作进行优化了~

举个例子:

如果你家里有一个亿, 你丢了100块钱, 那你会觉得无所谓, 不差那100块~~

但是如果你全部的家当只有500块, 那你丢了100块钱, 影响是非常大的~~

所以, 加了sleep后, 就解决了该代码的线程安全问题.

但是, 使用sleep将大大影响到程序的效率, 所以针对内存可见性问题, 并不是指望sleep来解决的.

于是在语法上, 引入了volatile关键字~

6.2.1 JMM --- Java内存模型

JMM是Java官方文档的术语:

JMM :

每个线程, 都有一个自己的"工作内存(work memory)", 同时这些线程又共有一个"主内存(main memory)". 当一个线程循环多次进行读取变量操作的时候, 就会把主内存中的数据, 拷贝到工作内存当中, 后续的读取操作就会直接从工作内存中读取(速度更快), 而不会从主内存中读取.

而后续另一个线程修改这个变量后(也是先修改自己的工作内存, 再拷贝到主内存中), 由于第一个线程仍然读的是自己的工作内存, 因此感知不到主内存的变化.

我们上文讲的编译器优化, 讲的是把读内存优化为读编译器. 而JMM说的是线程读自己的"工作内存".

其实, 这两者本质上是一个意思.

6.3 volatile关键字

通过volatile关键字("易变的")来修饰某个变量, 那么编译器对这个变量的读取操作, 就不会被优化成读寄存器了, JVM将会一直从内存中读取该变量的值, 一旦该变量的值被修改, 那么线程就会立刻感知.

当我们对上文的flag变量使用 volatile 修饰时, t1线程就能感知到 flag 的修改, 从而正常结束:

所以, 可以通过使用 volatile 修饰相关的变量, 从而可以解决内存可见性问题.

标签：重入,加锁,t1,死锁,线程,内存,多线程
From： https://blog.csdn.net/2401_83595513/article/details/142911975

多线程（五）：死锁&内存可见性问题

1. synchronized --- 监视器锁 monitor lock

2. 死锁

2.1 死锁 --- 情况1

2.1.1 可重入

2.1.2 如何实现一个可重入锁 [面试题]

2.2 死锁 --- 情况2