前言：线程安全是整个多线程中，最为复杂的部分，也是最重要的部分。

什么是线程安全问题？

线程不安全的原因

⁜⁜总结：线程安全问题的原因 ⁜⁜

解决方法1 ——加锁 synchronized （监视器锁monitor lock）

synchronized 的特性

—— 互斥

—— 可重入

死锁

可重入锁

死锁拓展

哲学家就餐问题

如何解决或者避免死锁？

死锁的的成因

解决死锁（重点⁜⁜）

—— 3. 请求保持

—— 4. 循环等待/环路等待

解决方法2 —— volatile 关键字

内存可见性

volatile

什么是线程安全问题？

有些代码，在单个线程中执行，完全正确，但如果同样的代码，让多个线程同时执行，就可能会出现bug。代码运行的结果不符合我们预期，

这种情况我们就称为 “线程安全问题” 或 “线程不安全”。

接下来我们结合具体的代码示例来理解一下：

注意：这两个 join 必须得有，不然上面两个线程还没自增完，就开始打印了，count很有可能就打印个0

ps: join在之前的博客中有介绍，线程等待那部分，链接https://blog.csdn.net/iiiiiihuang/article/details/132587614?spm=1001.2014.3001.5501

那我们来看看上述代码的执行结果是否是我们所预期的：

很明显，这不是我们预期的结果100000，那我们把这个代码再执行一遍，发现这个结果又变了

每次运行结果都不一样。

上述的情况就是典型的线程安全问题。

这个代码如果放在单个线程中执行，那一定是对的，但是当两个线程并发执行了上述循环，此时逻辑就可能出现问题了

线程不安全的原因

----- 上述代码为什么会出现这样的情况呢？

因为两个线程并发执行了。

当我们把join 的位置换一下

这意味着当 t1 正在运行的过程中，t2 是不会启动的，也就是说，虽然上述代码是写在两个线程中的，但是并不是 “同时” 执行的。

此时结果就是预期的100000

---- 那为什么同时（并发）执行时就出问题了呢？

因为count++, 这个操作，本质上是分三步执行的，（站在CPU的角度上，count++ 是由CPU通过三个指令来实现的）

指令一： load 把数据从内存读到 CPU寄存器中。
指令二： add 把寄存器中的数据进行 +1.
指令三： save 把寄存器中的数据，保存到内存中。

上述过程单个线程肯定是没什么问题，

但是多个线程就要出问题了，因为当多个线程执行上述代码时，由于线程之间的调度顺序时随机的，就会导致在有些调度顺序下，上述的逻辑会出现问题。

接下来我们画图看一下多个线程执行的情况。

还有其他情况

............

--- 上面已经有7种情况了，那这里到底有多少种情况呢？

无数种

因为也可能存在，t1 执行一次 count++ 的时候，t2执行了 2 次，3次 ......

结合了上述的讨论，我们意识到了，在多线程程序中，最困难的一点：线程的随机调度，

使两个线程执行逻辑的顺序有诸多可能（不一定都是对的）。我们必须保证在所有可能的情况下，代码都是正确的！

⁜⁜总结：线程安全问题的原因 ⁜⁜

1.在操作系统中，线程的调度顺序是随机的（抢占式执行）。【万恶之源】

2.两个线程，针对同一个变量进行修改。

3.修改操作，不是原子的。

（前面的 count++, 就属于是非原子的操作。（先读，再修改），类似的，如果一段逻辑中，需要根据一定的条件来决定是否修改，也是存在类似的问题）

4.内存可见性问题。

5.指令重排序问题。

（4，5后面会介绍）

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

解决方法1 ——加锁 synchronized （监视器锁monitor lock）

前两个原因，我们一般很难调整

那我们就集中在第三条了，我们可以想办法让 count++ 成为原子的。------ 加锁！

--- 那如何给 Java 中的代码加锁呢？

就是使用 synchronized 关键字，接下来我们就来介绍 synchronized 关键字.

synchronized 的特性

—— 互斥

synchronized 在使用时要搭配代码块{ }，进入 代码块{ } 就会加锁，出了代码块{ } 就会解锁。

在已经加锁的状态中，另一个线程尝试同样加这个锁，就会产生 “锁冲突/锁竞争”，后一个线程就会堵塞等待，一直到前一个线程解锁为止。（本质上是把 “并发执行” 改为 “串行执行”）。

接下来我们具体写一下代码

执行结果是100000 ，因为加锁的对象是同一个，此时就产生了 ”锁冲突“。

synchronized 除了修饰代码块之外，还可以修饰一个实例方法，或者修饰一个静态方法 。

----- 修饰一个实例方法

我们把count 搞成一个方法。

如果没有加什么锁，那结果仍然会出现线程安全问题

那我们现在就进行一个加锁的大动作：

直接在这个方法这加

这时候就是我们所期待的10000了。

这么看，synchronized 似乎没有锁对象，其实是有的，此时就相当于使用 this 作为锁对象。

这两种等价，可以认为 1 是 2 的简化版本。

----- 修饰一个静态方法

如果修饰静态方法，相当于是针对 类对象加锁。

这两个写法也是等价的，1 是 2 的简化版本。

但大家注意：我强调一下，这个锁对象是什么，不重要！！！重要的是两个线程中锁对象是否是同一个对象。

synchronized 用的锁是存在 Java 对象头里的。

Java 的一个对象，对应的内存空间中，除了我们自己定义的属性之外，还有一些自带的属性。

这些自带的属性就是 对象头。 在对象头中，就有属性表示当前对象是否加锁。

—— 可重入

所谓的可重入锁，指的是，一个线程连续针对一把锁加锁两次，不会出现死锁。

满足这个要求，就是 “可重入”，不满足这个要求，就是 “不可重入”。

我们上述内容中，涉及到了死锁，那我们接下来就来介绍一些什么是死锁：

死锁

类似下面的代码，针对同一个对象，连续加锁两次

假设第一次加锁成功，那 locker 就属于是 “被锁定” 的状态，

那接下来，进行第二次加锁，问题来了，此时locker 已经是锁定状态了，原则上来说，第二次加锁操作，应该是要 “阻塞等待” 的。应该要等待到，第一次的锁被释放之后，第二次才能加成功。

但是实际上，第二次加锁阻塞等待，那第一次加锁的代码块就走不完，锁就释放不了，那第二次加锁就加不上 ....... 无法进行了，这就死锁了（线程卡死了）。bug!!!

在日常开发中, 这种情况难以避免，当然不是像上边那样的啦~~~，举例：

可能一个加锁在func1里，一个在func4里，这些方法里，又存在调用关系，然后就死锁了

为了避免这种情况，我们就把 synchronized 设计成 “可重入锁” ，就能有效解决上述死锁问题了

可重入锁

就是让锁记录一下，是哪个线程把它锁住的，后续再加锁的时候，如果要加锁的线程已经是持有锁的线程了，那就直接加锁成功！！！

欸嘿：那在下面的代码中，如果 synchronized 是可重入锁，没有因为第二次加锁而死锁，但是当代码执行到 “ } ①”，此时，锁是否应该释放呢？进一步来讲，如果上述加锁过程有N层，释放的时机该如何判定？

不行哦~~~ ，不能释放哦，你想如果 “ } ①” 和 “ }② ” 中间还有代码呢，是不是这里的代码就没办法受到锁的保护了，就可能会出现线程安全问题。所有不能在“ } ①”，要在“ }② ”这释放。

所有假设有 N 层，我们应该要在最外层进行释放。

那如何知道多少层呢？ ———— 这里我们就 引用计数：

锁对象中，不光要记录是谁拿了锁，还要记录，锁被加了几次，

每加锁一次，计数器就 +1，每解锁一次，计数器就 - 1，

出了最后一个大括号，恰好就减成 0 了，这时才真正释放锁。

死锁拓展

1.一个线程，针对一把锁，连续加锁两次，如果是不可重入锁，就死锁了。 （我们Java这边的synchronized 不会出现不可重入锁，但是C++ 的 std::mutex 就是不可重入锁，就会出现死锁。）

2.两个线程两把锁，此时无论是不是可重入锁，都会死锁。

—— 2 是什么意思呢？

就假如现在有线程t1 和线程t2，还有两把锁 A，B

现在t1 获取锁A，t2 获取锁B，然后t1 尝试获取锁B，t2 尝试获取锁A, 这时候也死锁了

我们用代码来演示一下两把锁死锁情况：

此处的 sleep 很重要，它保证了 t1 和 t2 都分别拿到了一把锁之后，再进行后续动作

package thread;

/**
 * @Author: iiiiiihuang
 */
public class Demo18 {
    //两把锁
    private static Object locker1 = new Object();
    private static Object locker2 = new Object();

    public static void main(String[] args) {
        Thread t1 = new Thread(() -> {
            synchronized (locker1) {
                //此处的 sleep 很重要，它保证了 t1 和 t2 都分别拿到了一把锁之后，再进行后续动作
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (locker2) {
                    System.out.println("t1 加锁成功");
                }
            }
        });
        Thread t2 = new Thread(() -> {
            synchronized (locker2) {
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (locker1) {
                    System.out.println("t2 加锁成功");
                }
            }
        });

        t1.start();
        t2.start();
    }
}

我们运行看一下，啥也没有，死锁了

我们可以借助 jconsole 来看看两个线程的状态：

这个Thread-0 和 Thread-1 就是刚才两个线程

我们看看Thread-0线程具体的状态和调用栈，可以看到这个线程是 BLOCKED 状态（因为锁竞争导致的阻塞），这个要等待(竞争)的锁是 Thread-1 持有的

我们再看看Thread-1线程

BLOCKED 状态，这个要等待(竞争)的锁是 Thread-0 持有的

大家注意，上面的死锁代码，两个 synchronized 是嵌套关系，不是并列关系，

嵌套关系说明，是在占用一把锁的前提下，获取另一把锁（则是可能出现死锁），

并列关系，则是先释放前面的锁，再获取下一把锁（不会死锁）。

N个线程，M把锁，此时更容易出现死锁。

这里有个经典描述 N个线程，M把锁的死锁的模型———— 哲学家就餐问题

哲学家就餐问题

一个桌子上有一碗面，桌子周围坐这 5个哲学家，每两个哲学家中间放一根筷子（共五根）

规则（哲学家）：（1）思考人生，放下筷子，啥都不干

（2）吃面条，拿起左右两边的筷子，开始吃面条

（3）哲学家啥时候吃面条，啥时候思考人生，是随机的

（4）哲学家正在吃面条的过程中，会持有左右两侧的筷子，此时相邻的哲学家如果也想吃面条，就需要阻塞等待

(哲学家就等于线程 , 筷子就等于锁)

基于上述规则，通常情况下，整个系统，可以良好运转，但是极端情况下，就会出问题，

比如，同一时刻，五个哲学家都想吃面条，同时拿起了左手的筷子，此时，五个哲学家发现，他们的右手都没有筷子，于是他们就都得阻塞等待，等待过程中，他们都不会放下左手筷子，

那就谁都吃不了了，就进入死锁状态。

死锁，是属于严重的Bug，那如何解决或者避免死锁呢？

如何解决或者避免死锁？

死锁的的成因

首先我们要了解死锁的的成因，这里涉及四个 必要条件（数学里的必要条件）

互斥使用（上面讲到了，这里再说一遍）：锁的基本特性，当一个线程持有一把锁之后，另一个线程也想获取到同一把锁，就要阻塞等待。
不可抢占：锁的基本特性，当锁已经被线程1拿到之后，线程2 只能等线程1 主动释放，不能强行抢过来。
请求保持：代码结构，一个线程尝试获取多把锁，（先拿到锁1 之后，再尝试获取锁2，获取的时候，锁1 不会释放（吃着碗里的，看着锅里的））。
循环等待/环路等待：等待的依赖关系，形成环了，就像上面介绍的哲学家就餐极端情况

要想出现死锁，得把上面的4条全都占了，

所有解决死锁，核心就是破坏上诉必要条件，只要破坏一个，死锁就形成不了。

解决死锁（重点⁜⁜）

—— 3. 请求保持

1和2，无法破坏，对于 3 ，只需要调整代码结构，避免编写 “锁嵌套” 逻辑。

比如说我们把上面的代码变一下 ，把嵌套变为并列关系。

执行：

加锁成功了。

但是这个不一定好使，因为有时候，可能就需要进行“锁嵌套”的操作（获取多个锁），所有我们看看 4.

—— 4. 循环等待/环路等待

对于4来说，可以约定加锁的顺序，就可以避免循环等待。

比如，针对锁，进行编号，约定加多把锁的时候，先加编号小的锁，后加编号大的锁。（所有的线程都要遵守这个规则）

我们还拿哲学家就餐问题来看：

1.先给筷子（锁）编号

2.约定，每个滑稽都是先拿起编号小的筷子，后拿起编号大的筷子。

有一个哲学家，没有拿 5 号筷子，而是拿到 1 号筷子，（因为这个哲学家两边是 1 和 5，1 < 5, 所以他拿1 筷子，）但是1 被占了，那这个哲学家就得阻塞等待一下，这就给拿 4 号筷子的哲学家一个机会，拿起 5 号筷子，这样他就可以吃面了，他吃完了，就可以放下 4，5号筷子，那拿 3号筷子的人就可以拿起 4号了，以此类推。此时循环等待就破除了，这不就不死锁。

代码演示（从锁编号小的开始）