【Java EE初阶 --- 多线程（初阶）】线程安全问题

线程不安全的原因

根本原因

多线程优点很明显，大大提高了线程的运行效率，但是它也有一个巨大的隐患：线程是并发执行的，而且调度是随机的（根本原因）。也就是说，随机调度使⼀个程序在多线程环境下, 执⾏顺序存在很多的变数 程序猿必须保证 在任意执⾏顺序下 , 代码都能正常⼯作。

看下面的代码，利用多线程求和，我们的想法是两个线程各自增5000，最后结果就是10000，但是我们多次运行发现，每一次执行的结果都不同。

在我们看来count++是一个递增操作，但是在CPU眼里，它有三个指令：

1. load -> 把内存中count数据读到 CPU寄存器 2. add -> 在指定寄存器中进行+1操作 3. save -> 把寄存器中数据写回到内存

CPU在执行这三条指令时，随时会触发线程的随机调度。。。

在这里插入图片描述

非原子性操作

我依稀记得，原子性这个特性是数据库中的东西，具有不可再分的特性。

如果修改操作只是对应到一个CPU指令，不会出现“一条指令执行一半”的情况，就可以认为是原子的；相反如果对应多个CPU指令，就不是原子的。

随机到正确的调度

在这里插入图片描述

随机到错误的调度

在这里插入图片描述

经过讨论:

如果两个线程load到的数据都是0，意味着一定会少加一次。 必须严格一个load到0，一个load到1，结果才正确；也就是一个线程的load必须在另一个线程的save后面

多个线程修改同一个变量

如果一个线程修改一个变量---- 可以 如果多个线程，不是同时修改同一个变量— 可以 如果多个线程修改不同变量— 可以 如果多个线程读取同一个变量— 可以

在这里插入图片描述

内存可见性

如果某一个线程针对共享变量值修改，能够及时被其他线程看到

在这里插入图片描述

此时虽然输入了非0的值，但是t1线程还没有执行完。 由运行结果可知，t2线程已经修改，但是t1线程没有读到已经修改后的值，这里就出现了bug.

解决线程安全问题

内存可见性问题

为什么会出现内存不能及时读取这种问题？我们来看看Java 内存模型 (JMM): Java虚拟机规范中定义了Java内存模型的解释（翻译后）：

如果学过计算机组成原理，这里稍微解释一下就会很清楚：工作内存不是内存，而是CPU的寄存器；主内存才是我们平时所说的内存。文档中之所以没有明确使用“寄存器”，而是用work memory来描述，主要是为了“一次编译，到处运行”。⽬的是屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到⼀致的并发效果。

在语法中，引入 volatile 关键字，通过这个关键字来修饰变量，编译器对这个变量的读取操作，就不会轻易被优化到寄存器中…（因为会得“易变”）

在这里插入图片描述

volatile关键字只是解决了内存可见性问题，解决原子性问题还需要加锁来完成。

加锁（打包原子性）

根本原因是操作系统的底层设计，无法改变… 主要解决方案，通过加锁（封装）一个原子特性，让不是原子的操作，打包为一个原子操作。

针对之前count++的操作，先给t1中count++加锁，等待t1计算完毕，再计算t2中的count++(给t2同样加锁)。

在这里插入图片描述

这里加锁比较抽象，不是禁止线程被调度走，而是禁止其他线程重新加这个锁，避免其他线程的插队。

加锁\解锁

加锁 \ 解锁 本身是操作系统提供的api，大多数都是对这样的api进行封装。 但是Java是通过synchronized 这样的关键字，来实现类似效果

synchronized(){//加锁
    //代码块
    //count++
}//解锁

锁对象

在Java中，任何一个对象都能叫做“锁”

在这里插入图片描述

这个锁的类型不重要，重要的是，是否有多个线程尝试针对这同一个对象加锁。 （这种时候才会产生互斥），如果是不同的锁对象，不会有互斥效果，线程安全没有解决。（一个对象只有一个用途比较好）

使用synchronized修饰方法

锁任意对象

private Object locker = new Object();
    public void method() {
        synchronized (locker) {
        }
    }

锁当前对象

private Object locker = new Object();
    public void method() {
        synchronized (this) {
        }
    }

直接修饰普通方法：锁的Demo对象

public class Demo {
    public synchronized void methond() {
    }
}

修饰静态方法：锁的Demo类的对象

public class Demo {
    public synchronized static void methond() {
    }
}

总结： 多个线程针对同一个对象加锁，才会产生互斥（锁冲突）。 synchronized修饰普通方法，相当于给this加锁 synchronized修饰静态方法，相当于给类对象加锁

监视器锁monitor lock

比较少见

Lock locker=new locker();
locker.lock();
.....
locker.unlock();
//容易忘记unlock;

可重入性

在这里插入图片描述

在这里插入图片描述

观察上面两个代码块，我们发现对add()方法加了两次锁。 我们分析一下，针对第一次加锁，可以成功（锁没有人使用）；第二次加锁，锁对象已经被占用，那么第二次加锁就会阻塞等待。

这个时候为了要解除阻塞等待（继续执行），只能使第一次加锁被释放；但是第一次加锁要释放必须执行到红色方框，为了执行到红色方框又必须执行第二次解锁，此时就陷入了死循环（死锁）。

反转来了：当你运行此程序时，发现它结果完全正确。 因为Java中的 synchronized 是可重⼊锁（内在）, 因此没有上⾯的问题.

在这里插入图片描述

值得注意的是，这里可重入特性有一个前提：所有锁都掌握在同一个线程手中，也就是锁对象内部知道当前线程是哪一个，如果有非当前线程来加锁，还是会造成阻塞等待。

站在JVM的视角，如何才知道哪个 “{” 是真正的加锁、哪个 “}” 是真正的解锁呢？

在可重⼊锁的内部, 包含了 “线程持有者” 和 “计数器” 两个信息. • 如果某个线程加锁的时候, 发现锁已经被⼈占⽤, 但是恰好占⽤的正是⾃⼰（“{”）, 那么仍然可以继续获取到锁, 并让计数器⾃增. • 解锁（”}“）的时候计数器递减为 0 的时候, 才真正释放锁. (才能被别的线程获取到)

死锁

第一种死锁：一个线程，一把锁，连续加锁两次（正常会造成死锁，synchronized有可重入特性避免出现死锁） 第二种死锁：两个线程，两把锁，每个线程获得一把锁后，都想要对方的锁。

Thread t1=new Thread(()->{
            //舰长拿出钥匙
            synchronized (locker1){
                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线程拿到两个锁");
                }
            }
        });

在这里插入图片描述

运行程序发现，两个线程都以BLOCKED（竞争锁）阻塞了

总结一下死锁出现的原因：

1. 锁是互斥的，一个线程拿到锁后，另一个线程再尝试获得锁，必须要阻塞等待（锁的基本特性）
2. 锁是不可剥夺的，一个线程拿到锁后，另一个线程再尝试获得锁，不能直接去抢，必须要阻塞等待（锁的基本特性）
3. 请求和保持，一个线程拿到锁后，不释放锁1的情况下，去获得锁2 （嵌套）
4. 循环等待，多个线程，多个锁之间构成”循环“

避免死锁

结合死锁出现的原因，1和2都是锁的基本特性，无法改变，那么只有对3和4下功夫了。

3.请求和保持：一个线程拿到锁后，不释放锁1的情况下，再由一个线程去获得锁2（并列） 4.循环等待：对加锁的顺序做出约定

Java标准可中的线程安全类

在这里插入图片描述

虽然有加锁来保证线程安全，但是万事没有绝对，而且加锁是要付出相应的代价（代码可能因为锁竞争，造成阻塞等待，影响程序执行效率）

Java中String虽然没有加锁，但是它内部具有不可修改的特性，使其天然的保证了线程安全。

线程协调

我们知道**，线程之间是抢占式执行的**，如果我们程序员不加以干涉，我们很难得知线程之间执行的先后顺序。程序员对线程的设计都是具有逻辑顺序的，这时候就需要我们合理的协调多个线程之间的执行先后顺序。

回想之前有关等待的部分： join是等另一个线程彻底结束，才继续执行，不符合我们的需求。 锁对于等待随机性太复杂，也不符合需求。

wait(等待)

wait方法的作用： 1. 使当前线程代码的线程进行等待 2. 释放当前锁（这就意味着wait方法必须和synchronized配合使用，因为要解锁的前提是当前对象为加锁状态） 3. 满足一定条件被唤醒，重新尝试获取这个锁

Object object=new Object();
        synchronized (object){
            object.wait();
        }

详细的操作是：

在这里插入图片描述

这里等待其他线程逻辑执行完毕，就可以使用notify方法唤醒wait，当前线程继续执行。

notify(通知)

notify的作用; 1. 同步使用在等待代码块中，通知 等待该对象的对象锁的其他线程，使它们重新获取该对象的对象锁。 2. 如果有多个等待线程，那么随机挑选出有wait状态的线程 3. 注意：在notify方法结束后，当前线程线程不会立刻释放该对象锁，要等执行notify的线程执行完毕后才会释放对象锁

Object locker=new Object();
        Thread t1=new Thread(()->{
            synchronized (locker){
                try {
                    locker.wait();
                } catch (InterruptedException e) {
                    throw new RuntimeException();
                }
            }
        });

Thread t2=new Thread(()->{
            Scanner scan=new Scanner(System.in);
            scan.next();//等待输入:约等于阻塞
            synchronized (locker){
                locker.notify();
            }
        });

在这里插入图片描述

如果不是同一个对象，那么两个线程无法沟通，就不能相互作用

notifyAll

Thread t3=new Thread(()->{
            Scanner scan=new Scanner(System.in);
            scan.next();//等待输入:约等于阻塞
            synchronized (locker){
                locker.notifyAll();//一次性唤醒所有wait线程
            }
        });

注意: 虽然是同时唤醒 2 个线程, 但是这 2 个线程需要同时加锁.只有其中一个才能成功加锁，所以并不是同时执⾏, ⽽仍然是有先有后的执⾏.

完结

可以点一个免费的赞并收藏起来~ 可以点点关注，避免找不到我~ ，我的主页：optimistic_chen 我们下期不见不散 ~ ~ ~