【JavaEE】多线程 (2) --线程安全

偏执的太偏执、 2024-02-17 10:29 36阅读 0赞

## ![6958f8aef5ca4318a0dc8eee7cde55c6.gif][] ##

**目录**

1. 观察线程不安全

2. 线程安全的概念

3. 线程不安全的原因

4. 解决之前的线程不安全问题

5. synchronized 关键字 - 监视器锁 monitor lock

5.1 synchronized 的特性

5.2 synchronized 使⽤⽰例

--------------------

## **1. 观察线程不安全** ##

package thread;
    public class ThreadDemo19 {
        private static int count = 0;
        public static void main(String[] args) throws InterruptedException {
            //创建两个线程,每个线程都针对上面的count变量循环自增5w次
            Thread t1 = new Thread(()-> {
                for(int i = 0; i<50000; i++) {
                    count++;
                }
            });
            Thread t2 = new Thread(()-> {
                for(int i = 0; i<50000; i++) {
                    count++;
                }
            });
            t1.start();
            t2.start();
            t1.join();
            t2.join();
            System.out.println(count);
        }
    }

执行上面的代码,我们发现结果并不是100000, 并且多次运行, 每次的结果都有所不同:

![9a4e3c34be214650b16d649965d202fb.png][]

这就是线程不安全的一个例子.

## 2. 线程安全的概念 ##

想给出⼀个线程安全的确切定义是复杂的，但我们可以这样认为：

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

## 3. 线程不安全的原因 ##

**线程调度是随机的**

*  这是线程安全问题的罪魁祸⾸
 *  随机调度使⼀个程序在多线程环境下, 执⾏顺序存在很多的变数.
 *  程序猿必须保证在任意执⾏顺序下 , 代码都能正常⼯作.

**修改共享数据**

多个线程修改同⼀个变量

上⾯的线程不安全的代码中, 涉及到多个线程针对 count 变量进⾏修改. 此时这个 count 是⼀个多个线程都能访问到的 "共享数据"

**原⼦性**

![c2474c2420484fbf84de157d6bd5f194.png][]

**什么是原⼦性**

> 我们把⼀段代码想象成⼀个房间，每个线程就是要进⼊这个房间的⼈。如果没有任何机制保证，A进⼊ 房间之后，还没有出来；B 是不是也可以进⼊房间，打断 A 在房间⾥的隐私。这个就是不具备原⼦性的。

那我们应该如何解决这个问题呢？是不是只要给房间加⼀把锁，A 进去就把⻔锁上，其他⼈是不是就进不来了。这样就保证了这段代码的原⼦性了。 有时也把这个现象叫做同步互斥，表⽰操作是互相排斥的。

**⼀条 java 语句不⼀定是原⼦的，也不⼀定只是⼀条指令**

⽐如刚才我们看到的 count++，其实是由三步操作组成的：

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

**不保证原⼦性会给多线程带来什么问题**

如果⼀个线程正在对⼀个变量操作，中途其他线程插⼊进来了，如果这个操作被打断了，结果就可能是错误的。

这点也和线程的抢占式调度密切相关. 如果线程不是 "抢占" 的, 就算没有原⼦性, 也问题不⼤.

**可⻅性**

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

## 4. 解决之前的线程不安全问题 ##

使用 synchronized 关键字将一条指令的多个操作, 打包成一个原子的操作.

![aaf67ea12cc24f3c96ecff41f7f31ee3.png][]

下面是使用 synchronized 来解决上面代码的问题:

![5c1dcd1ffad146338bff754fa865971b.png][]

![00955838cabd4eef95eb5c79ca26f3c3.png][]

**如果两个线程, 针对不同的对象加锁, 也会存在线程安全问题.**

![632cfc4c4bae42e784e88134098fb160.png][]

**如果一个线程加锁, 一个线程不加锁, 是否会存在线程安全问题?**

![a66d3988b209473b9c85950c1d3d35b8.png][]

**针对加锁操作的一些混淆理解**

**把count 放到一个Test t对象中, 通过类方法add 来进行修改, 加锁的时候锁对象写作 this**

package thread;
    class Test {
        public int count = 0;
        public void add() {
            synchronized (this) {
                count++;
            }
        }
    }
    public class ThreadDemo20 {
        public static void main(String[] args) throws InterruptedException {
            Test t = new Test();
            Thread t1 = new Thread(()->{
                for (int i = 0; i < 50000; i++) {
                    t.add();
                }
            });
            Thread t2 = new Thread(()->{
                for (int i = 0; i < 50000; i++) {
                    t.add();
                }
            });
            t1.start();
            t2.start();
            t1.join();
            t2.join();
            System.out.println("count = " + t.count);
        }
    }

也可以使用类对象:

![0c9838ac480f47f881bafa6694664733.png][]

![589ded932a9141d1a35af6b4a32600d4.png][]

## 5. synchronized 关键字 - 监视器锁 monitor lock ##

### 5.1 synchronized 的特性 ###

**1) 互斥**

synchronized 会起到互斥效果, 某个线程执⾏到某个对象的 synchronized 中时, 其他线程如果也执⾏ 到同⼀个对象 synchronized 就会阻塞等待

*  进⼊ synchronized 修饰的代码块, 相当于 加锁
 *  退出 synchronized 修饰的代码块, 相当于 解锁

![129d22bf521c4a3f9ad086f1324160f7.png][]

synchronized⽤的锁是存在Java对象头⾥的。

> 可以粗略理解成, 每个对象在内存中存储的时候, 都存有⼀块内存表⽰当前的 "锁定" 状态(类似于厕所 的 "有⼈/⽆⼈").
> 
> 如果当前是 "⽆⼈" 状态, 那么就可以使⽤, 使⽤时需要设为 "有⼈" 状态.
> 
> 如果当前是 "有⼈" 状态, 那么其他⼈⽆法使⽤, 只能排队

理解 "阻塞等待".

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

**2) 可重⼊**

synchronized 同步块对同⼀条线程来说是可重⼊的，不会出现⾃⼰把⾃⼰锁死的问题；

**理解 "把⾃⼰锁死"**

> ⼀个线程没有释放锁, 然后⼜尝试再次加锁.
> 
> // 第⼀次加锁, 加锁成功
> 
> lock();
> 
> // 第⼆次加锁, 锁已经被占⽤, 阻塞等待.
> 
> lock();
> 
> 按照之前对于锁的设定, 第⼆次加锁的时候, 就会阻塞等待. 直到第⼀次的锁被释放, 才能获取到第⼆ 个锁. 但是释放第⼀个锁也是由该线程来完成, 结果这个线程已经躺平了, 啥都不想⼲了, 也就⽆法进 ⾏解锁操作. 这时候就会 **死锁**

![124f1e4bb13449b3a696799c26a73314.png][]

这样的锁称为 不可重⼊锁.

**Java 中的 synchronized 是可重⼊锁, 因此没有上⾯的问题.**

### 5.2 synchronized 使⽤⽰例 ###

synchronized 本质上要修改指定对象的 "对象头". 从使⽤⻆度来看, synchronized 也势必要搭配⼀个 具体的对象来使⽤.

**1) 修饰代码块: 明确指定锁哪个对象.**

锁任意对象

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

锁当前对象

public class SynchronizedDemo {
        public void method() {
            synchronized (this) {
                
            }
        }
    }

**2) 直接修饰普通⽅法: 锁的 SynchronizedDemo 对象**

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

**3) 修饰静态⽅法: 锁的 SynchronizedDemo 类的对象**

public class SynchronizedDemo {
         public synchronized static void method() {
         }
    }

**我们重点要理解，synchronized 锁的是什么.** 两个线程竞争同⼀把锁, 才会产⽣阻塞等待.

两个线程分别尝试获取两把不同的锁, 不会产⽣竞争

##  ##

## 6.由内存可见性引起的线程安全问题 ##

这个代码中, 预期通过 t2 线程输入整数, 只要输入的整数不为 0 , 就可以使 t1 线程结束:

package thread;
    import java.util.Scanner;
    public class ThreadDemo23 {
        private static int flag = 0;
        public static void main(String[] args) {
            Thread t1 = new Thread(()->{
                while(flag == 0) {
                }
                System.out.println("t1 线程结束");
            });
    
            Thread t2 = new Thread(()->{
                System.out.println("请输入flag的值:");
                Scanner scanner = new Scanner(System.in);
                flag = scanner.nextInt();
            });
    
            t1.start();
            t2.start();
        }
    }

但是, 当我启动线程, 输入一个非0的值, t1 并没有结束:

![64a25d5cd8a94c60870f5745fbaade59.png][]

![da9f30850c194246a89de4d9c2507167.png][]

**解决方法一: 避免快速重复读取内存, 防止编译器触发优化:**

![c6f556f8e82749e1b4e3c156e7a9d54f.png][]

解决方法二: 使用 volatile 关键字:

![3fad65bca8ae451abed4a3e5898bfe3a.png][]

### volatile 关键字 ###

**volatile 能保证内存可⻅性**

volatile 修饰的变量, 能够保证 "内存可⻅性".

![162d66370e0e484e858d4e0e625110a6.png][]

代码在写⼊ volatile 修饰的变量的时候,

> • 改变线程⼯作内存中volatile变量副本的值
> 
> • 将改变后的副本的值从⼯作内存刷新到主内存

代码在读取 volatile 修饰的变量的时候,

> • 从主内存中读取volatile变量的最新值到线程的⼯作内存中
> 
> • 从⼯作内存中读取volatile变量的副本

前⾯我们讨论内存可⻅性时说了, 直接访问⼯作内存(实际是 CPU 的寄存器或者 CPU 的缓存), 速度⾮常快, 但是可能出现数据不⼀致的情况. 加上 volatile , 强制读写内存. 速度是慢了, 但是数据变的更准确了.

### 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.

![437bb446c0a14639a1fbfffc16029801.gif][]

[6958f8aef5ca4318a0dc8eee7cde55c6.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/3e8e7a1b7722469fa45beca6ff1d03b8.png
[9a4e3c34be214650b16d649965d202fb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/80991aa8b6cd4812a63cd76a6bcc271f.png
[c2474c2420484fbf84de157d6bd5f194.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/76af4ec22a494d2c8305ae1cd38e00cf.png
[aaf67ea12cc24f3c96ecff41f7f31ee3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/376288d5af6746d2a441c09962b2ea68.png
[5c1dcd1ffad146338bff754fa865971b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/bfeb91edb4604d4e9913d90f4b615385.png
[00955838cabd4eef95eb5c79ca26f3c3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/c3ef7334557b409d909e1cff4f708c7f.png
[632cfc4c4bae42e784e88134098fb160.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/dbda6a3587a8465ea0cbe34c0070a723.png
[a66d3988b209473b9c85950c1d3d35b8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/54d1b189c993486dbb706a4d683f8929.png
[0c9838ac480f47f881bafa6694664733.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/4db922f9b9374f8884d5a1dd4befafd1.png
[589ded932a9141d1a35af6b4a32600d4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/a0440aa075584f3e832307c20beba97c.png
[129d22bf521c4a3f9ad086f1324160f7.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/301ab90f16734231a47d2d43dd62e5dc.png
[124f1e4bb13449b3a696799c26a73314.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/253dfded53114f31b4b018e6d86c3dd6.png
[64a25d5cd8a94c60870f5745fbaade59.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/31c24c23d1c74144b9497a59cfa8ddd5.png
[da9f30850c194246a89de4d9c2507167.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/a214cca5c0d641a99663e1cfcf708dd3.png
[c6f556f8e82749e1b4e3c156e7a9d54f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/e3ef7bfa6be043769db0ec5fb1fbf698.png
[3fad65bca8ae451abed4a3e5898bfe3a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/1c2995019c6745b291859a167a599e23.png
[162d66370e0e484e858d4e0e625110a6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/a4216a84593047a1890ab608489b72c8.png
[437bb446c0a14639a1fbfffc16029801.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/06/33b9b7fa3adf445f9cb70c904a8b5844.png