JavaEE-线程安全问题

1.多线程带来的的⻛险-线程安全

1.1 观察线性不安全

// 此处定义⼀个 int 类型的变量
private static int count = 0;

public static void main(String[] args) throws InterruptedException {
 Thread t1 = new Thread(() -> {
 // 对 count 变量进⾏⾃增 5w 次
 for (int i = 0; i < 50000; i++) {
 count++;
 }
 });

 Thread t2 = new Thread(() -> {
 // 对 count 变量进⾏⾃增 5w 次
 for (int i = 0; i < 50000; i++) {
 count++;
 }
 });


 t1.start();
 t2.start();
 // 如果没有这俩 join, 肯定不⾏的. 线程还没⾃增完, 就开始打印了. 
 t1.join();
 t2.join();
 // 预期结果应该是 10w
 System.out.println("count: " + count);
}

⼤家观察下是否适⽤多线程的现象是否⼀致？同时尝试思考下为什么会有这样的现象发⽣呢？

1.2 线程安全的概念

想给出⼀个线程安全的确切定义是复杂的，但我们可以这样认为：
如果多线程环境下代码运⾏的结果是符合我们预期的，即在单线程环境应该的结果，则说这个程序是线程安全的。

1.3线程不安全的原因

线程调度是随机的
这是线程安全问题的 罪魁祸⾸
随机调度使⼀个程序在多线程环境下, 执⾏顺序存在很多的变数.
程序猿必须保证 在任意执⾏顺序下 , 代码都能正常⼯作.
修改共享数据
多个线程修改同⼀个变量
上⾯的线程不安全的代码中, 涉及到多个线程针对 count 变量进⾏修改.
此时这个 count 是⼀个多个线程都能访问到的 "共享数据"

原子性

什么是原⼦性
我们把⼀段代码想象成⼀个房间，每个线程就是要进⼊这个房间的⼈。如果没有任何机制保证，A进⼊房间之后，还没有出来；B 是不是也可以进⼊房间，打断 A 在房间⾥的隐私。这个就是不具备原⼦性的。
那我们应该如何解决这个问题呢？是不是只要给房间加⼀把锁，A 进去就把⻔锁上，其他⼈是不是就进不来了。这样就保证了这段代码的原⼦性了。
有时也把这个现象叫做同步互斥，表⽰操作是互相排斥的。
⼀条 java 语句不⼀定是原⼦的，也不⼀定只是⼀条指令
⽐如刚才我们看到的 n++，其实是由三步操作组成的：

从内存把数据读到 CPU
进⾏数据更新
把数据写回到 CPU
不保证原⼦性会给多线程带来什么问题
如果⼀个线程正在对⼀个变量操作，中途其他线程插⼊进来了，如果这个操作被打断了，结果就可能是错误的。

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

可⻅性
可⻅性指, ⼀个线程对共享变量值的修改，能够及时地被其他线程看到.
Java 内存模型 (JMM): Java虚拟机规范中定义了Java内存模型.
⽬的是屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到⼀致的并发效果.

• 线程之间的共享变量存在主内存 (Main Memory).
• 每⼀个线程都有⾃⼰的 "⼯作内存" (Working Memory) .
• 当线程要读取⼀个共享变量的时候, 会先把变量从主内存拷⻉到⼯作内存, 再从⼯作内存读取数据.
• 当线程要修改⼀个共享变量的时候, 也会先修改⼯作内存中的副本, 再同步回主内存.
由于每个线程有⾃⼰的⼯作内存, 这些⼯作内存中的内容相当于同⼀个共享变量的 "副本". 此时修改线程1 的⼯作内存中的值, 线程2 的⼯作内存不⼀定会及时变化.

初始情况下, 两个线程的⼯作内存内容⼀致.
⼀旦线程1 修改了 a 的值, 此时主内存不⼀定能及时同步. 对应的线程2 的⼯作内存的 a 的值也不⼀定能及时同步.

这个时候代码中就容易出现问题.

此时引⼊了两个问题:
• 为啥要整这么多内存?
• 为啥要这么⿇烦的拷来拷去?

为啥整这么多内存?
实际并没有这么多 "内存". 这只是 Java 规范中的⼀个术语, 是属于 "抽象" 的叫法.
所谓的 "主内存" 才是真正硬件⻆度的 "内存". ⽽所谓的 "⼯作内存", 则是指 CPU 的寄存器和⾼速缓存.
为啥要这么⿇烦的拷来拷去?
因为 CPU 访问⾃⾝寄存器的速度以及⾼速缓存的速度, 远远超过访问内存的速度(快了 3 - 4 个数量级, 也就是⼏千倍, 上万倍).
⽐如某个代码中要连续 10 次读取某个变量的值, 如果 10 次都从内存读, 速度是很慢的. 但是如果只是第⼀次从内存读, 读到的结果缓存到 CPU 的某个寄存器中, 那么后 9 次读数据就不必直接访问内存了. 效率就⼤⼤提⾼了.
那么接下来问题⼜来了, 既然访问寄存器速度这么快, 还要内存⼲啥??
答案就是⼀个字: 贵

值的⼀提的是, 快和慢都是相对的. CPU 访问寄存器速度远远快于内存, 但是内存的访问速度⼜远远快于硬盘.
对应的, CPU 的价格最贵, 内存次之, 硬盘最便宜.
指令重排序
什么是代码重排序
⼀段代码是这样的：

去前台取下 U 盘
去教室写 10 分钟作业
去前台取下快递
如果是在单线程情况下，JVM、CPU指令集会对其进⾏优化，⽐如，按 1->3->2的⽅式执⾏，也是没问题，可以少跑⼀次前台。这种叫做指令重排序

编译器对于指令重排序的前提是 "保持逻辑不发⽣变化". 这⼀点在单线程环境下⽐较容易判断, 但是在多线程环境下就没那么容易了, 多线程的代码执⾏复杂程度更⾼, 编译器很难在编译阶段对代码的执⾏效果进⾏预测, 因此激进的重排序很容易导致优化后的逻辑和之前不等价.

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

先观察代码，在之后进行解释

// 此处定义⼀个 int 类型的变量
private static int count = 0;

public static void main(String[] args) throws InterruptedException {
 Object locker = new Object();
 Thread t1 = new Thread(() -> {
 // 对 count 变量进⾏⾃增 5w 次
 for (int i = 0; i < 50000; i++) {
 synchronized (locker) {
 count++;
 }
 }
 });

 Thread t2 = new Thread(() -> {
 // 对 count 变量进⾏⾃增 5w 次
 for (int i = 0; i < 50000; i++) {
 synchronized (locker) {
 count++;
 }
 }
 });

 t1.start();
 t2.start();
 // 如果没有这俩 join, 肯定不⾏的. 线程还没⾃增完, 就开始打印了. 
 t1.join();
 t2.join();
 // 预期结果应该是 10w
 System.out.println("count: " + count);
}

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

2.1 synchronized的特性

1）互斥

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

synchronized⽤的锁是存在Java对象头⾥的。
可以粗略理解成, 每个对象在内存中存储的时候, 都存有⼀块内存表⽰当前的 "锁定" 状态(类似于厕所的 "有⼈/⽆⼈").
如果当前是 "⽆⼈" 状态, 那么就可以使⽤, 使⽤时需要设为 "有⼈" 状态.
如果当前是 "有⼈" 状态, 那么其他⼈⽆法使⽤, 只能排队
理解 "阻塞等待".
针对每⼀把锁, 操作系统内部都维护了⼀个等待队列. 当这个锁被某个线程占有的时候, 其他线程尝试进⾏加锁, 就加不上了, 就会阻塞等待, ⼀直等到之前的线程解锁之后, 由操作系统唤醒⼀个新的线程, 再来获取到这个锁.
注意:
• 上⼀个线程解锁之后, 下⼀个线程并不是⽴即就能获取到锁. ⽽是要靠操作系统来 "唤醒". 这也就是操作系统线程调度的⼀部分⼯作.
• 假设有 A B C 三个线程, 线程 A 先获取到锁, 然后 B 尝试获取锁, 然后 C 再尝试获取锁, 此时 B 和 C都在阻塞队列中排队等待. 但是当 A 释放锁之后, 虽然 B ⽐ C 先来的, 但是 B 不⼀定就能获取到锁,⽽是和 C 重新竞争, 并不遵守先来后到的规则.

synchronized的底层是使⽤操作系统的mutex lock实现的。

2）可重入

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

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

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

for (int i = 0; i < 50000; i++) {
     synchronized (locker) {
         synchronized (locker) {
             count++;
         }
     }
}

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

2.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 锁的是什么. 两个线程竞争同⼀把锁, 才会产⽣阻塞等待.

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

Java 标准库中很多都是线程不安全的. 这些类可能会涉及到多线程修改共享数据, ⼜没有任何加锁措施.
• ArrayList
• LinkedList
• HashMap
• TreeMap
• HashSet
• TreeSet
• StringBuilder
但是还有⼀些是线程安全的. 使⽤了⼀些锁机制来控制.
• Vector (不推荐使⽤)
• HashTable (不推荐使⽤)
• ConcurrentHashMap
• StringBuffer

3. volatile 关键字

volatile 能保证内存可⻅性

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

代码在写⼊ volatile 修饰的变量的时候,
• 改变线程⼯作内存中volatile变量副本的值
• 将改变后的副本的值从⼯作内存刷新到主内存
代码在读取 volatile 修饰的变量的时候,
• 从主内存中读取volatile变量的最新值到线程的⼯作内存中
• 从⼯作内存中读取volatile变量的副本

前⾯我们讨论内存可⻅性时说了, 直接访问⼯作内存(实际是 CPU 的寄存器或者 CPU 的缓存), 速度⾮常快, 但是可能出现数据不⼀致的情况.
加上 volatile , 强制读写内存. 速度是慢了, 但是数据变的更准确了.
代码⽰例
在这个代码中
• 创建两个线程 t1 和 t2
• t1 中包含⼀个循环, 这个循环以 flag == 0 为循环条件.
• t2 中从键盘读⼊⼀个整数, 并把这个整数赋值给 flag.
• 预期当⽤⼾输⼊⾮ 0 的值的时候, t1 线程结束.

static class Counter {
     public int flag = 0;
}

public static void main(String[] args) {
     Counter counter = new Counter();
     Thread t1 = new Thread(() -> {
         while (counter.flag == 0) {
             // do nothing
         }
         System.out.println("循环结束!");
     });

     Thread t2 = new Thread(() -> {
         Scanner scanner = new Scanner(System.in);
         System.out.println("输⼊⼀个整数:");
         counter.flag = scanner.nextInt();
     });

 t1.start();
 t2.start();
}
// 执⾏效果
// 当⽤⼾输⼊⾮0值时, t1 线程循环不会结束. (这显然是⼀个 bug)

t1 读的是⾃⼰⼯作内存中的内容.
当 t2 对 flag 变量进⾏修改, 此时 t1 感知不到 flag 的变化.

如果给 flag 加上 volatile

static class Counter {
 public volatile int flag = 0;
}
// 执⾏效果
// 当⽤⼾输⼊⾮0值时, t1 线程循环能够⽴即结束.

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.

4.wait和notify

由于线程之间是抢占式执⾏的, 因此线程之间执⾏的先后顺序难以预知.
但是实际开发中有时候我们希望合理的协调多个线程之间的执⾏先后顺序.

球场上的每个运动员都是独⽴的 "执⾏流" , 可以认为是⼀个 "线程".
⽽完成⼀个具体的进攻得分动作, 则需要多个运动员相互配合, 按照⼀定的顺序执⾏⼀定的动作, 线程1 先 "传球" , 线程2 才能 "扣篮"
完成这个协调⼯作, 主要涉及到三个⽅法
• wait() / wait(long timeout): 让当前线程进⼊等待状态.
• notify() / notifyAll(): 唤醒在当前对象上等待的线程.
注意: wait, notify, notifyAll 都是 Object 类的⽅法.

4.1 wait()⽅法

wait 做的事情:
• 使当前执⾏代码的线程进⾏等待. (把线程放到等待队列中)
• 释放当前的锁
• 满⾜⼀定条件时被唤醒, 重新尝试获取这个锁.
wait 要搭配 synchronized 来使⽤. 脱离 synchronized 使⽤ wait 会直接抛出异常.
wait 结束等待的条件:
• 其他线程调⽤该对象的 notify ⽅法.
• wait 等待时间超时 (wait ⽅法提供⼀个带有 timeout 参数的版本, 来指定等待时间).
• 其他线程调⽤该等待线程的 interrupted ⽅法, 导致 wait 抛出 InterruptedException 异常.
代码⽰例: 观察wait()⽅法使⽤

public static void main(String[] args) throws InterruptedException {
     Object object = new Object();

     synchronized (object) {
         System.out.println("等待中");
         object.wait();
         System.out.println("等待结束");
     }
}

这样在执⾏到object.wait()之后就⼀直等待下去，那么程序肯定不能⼀直这么等待下去了。这个时候就需要使⽤到了另外⼀个⽅法唤醒的⽅法notify()。

4.2notify()方法

notify ⽅法是唤醒等待的线程.
• ⽅法notify()也要在同步⽅法或同步块中调⽤，该⽅法是⽤来通知那些可能等待该对象的对象锁的其它线程，对其发出通知notify，并使它们重新获取该对象的对象锁。
• 如果有多个线程等待，则有线程调度器随机挑选出⼀个呈 wait 状态的线程。(并没有 "先来后到")
• 在notify()⽅法后，当前线程不会⻢上释放该对象锁，要等到执⾏notify()⽅法的线程将程序执⾏
完，也就是退出同步代码块之后才会释放对象锁。
代码⽰例: 使⽤notify()⽅法唤醒线程
• 创建 WaitTask 类, 对应⼀个线程, run 内部循环调⽤ wait.
• 创建 NotifyTask 类, 对应另⼀个线程, 在 run 内部调⽤⼀次 notify
• 注意, WaitTask 和 NotifyTask 内部持有同⼀个 Object locker. WaitTask 和 NotifyTask 要想配合就
需要搭配同⼀个 Object.

static class WaitTask implements Runnable {
     private Object locker;
     public WaitTask(Object locker) {
         this.locker = locker;
     }

     @Override
     public void run() {
         synchronized (locker) {
             while (true) {
                 try {
                     System.out.println("wait 开始");
                     locker.wait();
                     System.out.println("wait 结束");
                 } catch (InterruptedException e) {
                     e.printStackTrace();
                 }
             }
         }
     }
}

static class NotifyTask implements Runnable {
     private Object locker;
     public NotifyTask(Object locker) {
         this.locker = locker;
     }

     @Override
     public void run() {
         synchronized (locker) {
             System.out.println("notify 开始");
             locker.notify();
             System.out.println("notify 结束");
         }
     }
}


public static void main(String[] args) throws InterruptedException {
     Object locker = new Object();
     Thread t1 = new Thread(new WaitTask(locker));
     Thread t2 = new Thread(new NotifyTask(locker));
     t1.start();
     Thread.sleep(1000);
     t2.start();
}

4.3notifyAll()方法

notify⽅法只是唤醒某⼀个等待线程. 使⽤notifyAll⽅法可以⼀次唤醒所有的等待线程.
范例：使⽤notifyAll()⽅法唤醒所有等待线程, 在上⾯的代码基础上做出修改.
• 创建 3 个 WaitTask 实例. 1 个 NotifyTask 实例.

static class WaitTask implements Runnable {
 // 代码不变
}
static class NotifyTask implements Runnable {
 // 代码不变
}
public static void main(String[] args) throws InterruptedException {
     Object locker = new Object();
     Thread t1 = new Thread(new WaitTask(locker));
     Thread t3 = new Thread(new WaitTask(locker));
     Thread t4 = new Thread(new WaitTask(locker));
     Thread t2 = new Thread(new NotifyTask(locker));

     t1.start();
     t3.start();
     t4.start();
     Thread.sleep(1000);
     t2.start();
}

此时可以看到, 调⽤ notify 只能唤醒⼀个线程。
• 修改 NotifyTask 中的 run ⽅法, 把 notify 替换成 notifyAll

public void run() {
     synchronized (locker) {
         System.out.println("notify 开始");
         locker.notifyAll();
         System.out.println("notify 结束");
     }
}

此时可以看到, 调⽤ notifyAll 能同时唤醒 3 个wait 中的线程
注意: 虽然是同时唤醒 3 个线程, 但是这 3 个线程需要竞争锁. 所以并不是同时执⾏, ⽽仍然是有先有后的执⾏.

4.4 wait 和 sleep 的对⽐

wait 和 sleep 是在编程和操作系统中常用的两种控制执行流的机制，尽管它们的名称相似，但它们的功能和用途有很大的不同。以下是它们的主要区别：

1. 功能

sleep：
- sleep 函数使当前线程暂停执行一段指定的时间。无论是 CPU 资源还是其他资源，线程在此期间不会执行任何操作。使用 sleep 通常用于延迟操作或等待某些条件的实现。
wait：
- wait 通常用于线程或进程间的同步。它使一个线程等待另一个线程或进程的状态改变（例如，等待子进程结束）。在此期间，调用 wait 的线程会被阻塞，直到它所等待的条件成立。

2. 用法

sleep：
- 通常用于控制时间间隔，例如在执行某些操作之前给用户提供时间，或在重复操作之间引入延迟。
wait：
- 多用于线程同步和进程间通信中，例如使用条件变量、信号量等机制。它使线程在某些条件不满足时处于阻塞状态，直到其他线程调用 notify 或 notifyAll 等方法来唤醒它。

3. 影响

sleep：
- 使用 sleep 后，线程会在指定时间内完全不执行，不会消耗 CPU 资源，但会保持占用系统资源。
wait：
- wait 使线程在条件不满足时进入等待状态，释放持有的锁或资源，直到被唤醒，允许其他线程继续执行。这有助于提高资源利用率和避免死锁。

4. 示例

sleep 示例（伪代码）：

import time

print("Start sleeping...")
time.sleep(5)  # 暂停 5 秒
print("Wake up!")

wait 示例（伪代码）：

condition = threading.Condition()

def thread_function():
    with condition:
        condition.wait()  # 等待其他线程通知
        print("Thread resumed!")

def notify_function():
    time.sleep(5)  # 假设等待某些条件
    with condition:
        condition.notify()  # 通知等待的线程

总结

wait 和 sleep 都是控制程序执行流的工具，但它们在功能、用途和实现机制上有明显的区别。在实际编程中，根据具体需求选择使用 sleep 或 wait 是很重要的。