JavaEE语法之第二章、多线程（初阶三）
目录
一、多线程带来的风险-线程安全 (重点)
1.1观察线程不安全
1.2线程安全的概念
1.3线程不安全的原因
1.3.1抢占式执行（进程的随机调度）
1.3.2多个线程修改同一个变量
1.3.3内存的可见性
1.3.4原子性
1.3.5指令重排序
二、解决之前的线程不安全问题
2.1synchronized 关键字-监视器锁monitor lock
2.1.1synchronized 的特性
1) 互斥
2) 刷新内存
3) 可重入
2.1.2synchronized 使用示例
2.1.2.1直接修饰普通方法: 锁的 SynchronizedDemo 对象
2.1.2.2修饰静态方法: 锁的 SynchronizedDemo 类的对象
2.1.2.3修饰代码块: 明确指定锁哪个对象.
2.1.3Java 标准库中的线程安全类
2.2volatile 关键字
2.2.1volatile 能保证内存可见性
2.2.2volatile 不保证原子性
2.2.3禁止指令重排序
一、多线程带来的风险-线程安全 (重点)
1.1观察线程不安全
//线程不安全
class Counter{
private int count=0;
public void add(){
count++;
}
public int get(){
return count;
}
}
public class ThreadDemo13 {
public static void main(String[] args) throws InterruptedException{
Counter counter=new Counter();
//两个线程，两个线程分别对Counter自增五万次
Thread thread=new Thread(()->{
for(int i=0;i<50000;i++){
counter.add();
}
});
Thread thread2=new Thread(()->{
for(int i=0;i<50000;i++){
counter.add();
}
});
thread.start();
thread2.start();
//等待两个线程执行完成
thread.join();
thread2.join();
System.out.println(counter.get());
//实际结果和预期结果不相符，这是一个Bug，这是一个线程暴怒安全的
}
}
归根结底，线程的安全问题全是因为线程的无序调度，导致了执行顺序的不确定性，结果就变化了。
1.2线程安全的概念
如果多线程环境下代码运行的结果是符合我们预期的，即在单线程环境应该的结果，则说这个程序是线程安全的。
1.3线程不安全的原因
1.3.1抢占式执行（进程的随机调度）
1.3.2多个线程修改同一个变量
- 一个线程修改同一个变量，是安全的
- 多个线程读取同一个变量，是安全的
- 多个线程修改不同变量，是安全的
- 多个线程修改同一个变量，是不安全的
1.3.3内存的可见性
可见性指, 一个线程对共享变量值的修改，能够及时地被其他线程看到。
Java 内存模型 (JMM): Java虚拟机规范中定义了Java内存模型，目的是屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一的并发效果。
- 线程之间的共享变量存在 主内存 (Main Memory).
- 每一个线程都有自己的 "工作内存" (Working Memory) .
- 当线程要读取一个共享变量的时候, 会先把变量从主内存拷贝到工作内存, 再从工作内存读取数据.
- 当线程要修改一个共享变量的时候, 也会先修改工作内存中的副本, 再同步回主内存.
由于每个线程有自己的工作内存, 这些工作内存中的内容相当于同一个共享变量的 "副本". 此时修改线程1 的工作内存中的值, 线程2 的工作内存不一定会及时变化.
1) 初始情况下, 两个线程的工作内存内容一致.
2) 一旦线程1 修改了 a 的值, 此时主内存不一定能及时同步. 对应的线程2 的工作内存的 a 的值也不一定能及时同步.
此时引入了两个问题:
- 为啥要整这么多内存?
- 为啥要这么麻烦的拷来拷去?
1) 为啥整这么多内存?
实际并没有这么多 "内存". 这只是 Java 规范中的一个术语, 是属于 "抽象" 的叫法.所谓的 "主内存" 才是真正硬件角度的 "内存". 而所谓的 "工作内存", 则是指 CPU 的寄存器和高速缓存.
2) 为啥要这么麻烦的拷来拷去?因为 CPU 访问自身寄存器的速度以及高速缓存的速度, 远远超过访问内存的速度(快了 3 - 4 个数量级, 也就是几千倍, 上万倍).比如某个代码中要连续 10 次读取某个变量的值, 如果 10 次都从内存读, 速度是很慢的. 但是如果只是第一次从内存读, 读到的结果缓存到 CPU 的某个寄存器中, 那么后 9 次读数据就不必直接访问内存了. 效率就大大提高了.
那么接下来问题又来了, 既然访问寄存器速度这么快, 还要内存干啥??
答案就是一个字: 贵
值的一提的是, 快和慢都是相对的. CPU 访问寄存器速度远远快于内存, 但是内存的访问速度又远远快于硬盘.对应的, CPU 的价格最贵, 内存次之, 硬盘最便宜.
1.3.4原子性
原子：不可分割的最小单位。
我们把一段代码想象成一个房间，每个线程就是要进入这个房间的人。如果没有任何机制保证，A进入房间之后，还没有出来；B 是不是也可以进入房间，打断 A 在房间里的隐私。这个就是不具备原子性的。那我们应该如何解决这个问题呢？是不是只要给房间加一把锁，A 进去就把门锁上，其他人是不是就进不来了。这样就保证了这段代码的原子性了。有时也把这个现象叫做同步互斥，表示操作是互相排斥的。
一条 java 语句不一定是原子的，也不一定只是一条指令
比如刚才我们看到的 n++，其实是由三步操作组成的：
1. load:从内存把数据读到 CPU
2. add:进行数据更新
3. save:把数据写回到 CPU
(=赋值操作，就是一个原子操作)
不保证原子性会给多线程带来什么问题
如果一个线程正在对一个变量操作，中途其他线程插入进来了，如果这个操作被打断了，结果就可能是错误的。这点也和线程的抢占式调度密切相关. 如果线程不是 "抢占" 的, 就算没有原子性, 也问题不大.
1.3.5指令重排序
什么是代码重排序
一段代码是这样的：
1. 去前台取下 U 盘
2. 去教室写 10 分钟作业
3. 去前台取下快递
如果是在单线程情况下，JVM、CPU指令集会对其进行优化，比如，按 1->3->2的方式执行，也是没问题，可以少跑一次前台。这种叫做指令重排序
编译器对于指令重排序的前提是 "保持逻辑不发生变化". 这一点在单线程环境下比较容易判断, 但
是在多线程环境下就没那么容易了, 多线程的代码执行复杂程度更高, 编译器很难在编译阶段对代
码的执行效果进行预测, 因此激进的重排序很容易导致优化后的逻辑和之前不等价.
重排序是一个比较复杂的话题, 涉及到 CPU 以及编译器的一些底层工作原理, 此处不做过多讨论
二、解决之前的线程不安全问题
2.1synchronized 关键字-监视器锁monitor lock
2.1.1synchronized 的特性
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) 刷新内存
1. 获得互斥锁
2. 从主内存拷贝变量的最新副本到工作的内存
3. 执行代码
4. 将更改后的共享变量的值刷新到主内存
5. 释放互斥锁
synchronized 能不能保证内存可见性，是具有争议性的。
3) 可重入
synchronized 同步块对同一条线程来说是可重入的，不会出现自己把自己锁死的问题；
理解 "把自己锁死"
一个线程没有释放锁, 然后又尝试再次加锁.
// 第一次加锁, 加锁成功
lock();
// 第二次加锁, 锁已经被占用, 阻塞等待.
lock();按照之前对于锁的设定, 第二次加锁的时候, 就会阻塞等待. 直到第一次的锁被释放, 才能获取到第
二个锁. 但是释放第一个锁也是由该线程来完成, 结果这个线程已经躺平了, 啥都不想干了, 也就无
法进行解锁操作. 这时候就会 死锁.
这样的锁称为 不可重入锁.
Java 中的 synchronized 是 可重入锁, 因此没有上面的问题.
代码示例
在下面的代码中,increase 和 increase2 两个方法都加了 synchronized, 此处的 synchronized 都是针对 this 当前对象加锁的.在调用 increase2 的时候, 先加了一次锁, 执行到 increase 的时候, 又加了一次锁. (上个锁还没释放, 相当于连续加两次锁)这个代码是完全没问题的. 因为 synchronized 是可重入锁.static class Counter { public int count = 0; synchronized void increase() { count++; } synchronized void increase2() { increase(); } }在可重入锁的内部, 包含了 "线程持有者" 和 "计数器" 两个信息.
- 如果某个线程加锁的时候, 发现锁已经被人占用, 但是恰好占用的正是自己, 那么仍然可以继续获取到锁, 并让计数器自增.
- 解锁的时候计数器递减为 0 的时候, 才真正释放锁. (才能被别的线程获取到)
2.1.2synchronized 使用示例
synchronized 本质上要修改指定对象的 "对象头". 从使用角度来看, synchronized 也势必要搭配一个具体的对象来使用.
class Counter{
private int count=0;//变量捕获
//synchronized public void add等价于synchronized(this)
public void add(){
//count++;
synchronized(this){
count++;
}
}
public int get(){
return count;
}
}
public class ThreadDemo13 {
public static void main(String[] args) throws InterruptedException{
Counter counter=new Counter();
//两个线程，分别对count进行5万次自增操作
Thread thread1=new Thread(()->{
for(int i=0;i<50000;i++){
counter.add();
}
});
Thread thread2=new Thread(()->{
for(int i=0;i<50000;i++){
counter.add();
}
});
thread1.start();
thread2.start();
//等待两个线程执行完成
thread1.join();
thread2.join();
System.out.println(counter.get());
}
}
2.1.2.1直接修饰普通方法: 锁的 SynchronizedDemo 对象
public class SynchronizedDemo {
public synchronized void methond() {
}
}2.1.2.2修饰静态方法: 锁的 SynchronizedDemo 类的对象
public class SynchronizedDemo {
public synchronized static void method() {
}
}2.1.2.3修饰代码块: 明确指定锁哪个对象.
锁当前对象
public class SynchronizedDemo {
public void method() {
synchronized (this) {
}
}
}锁类对象
public class SynchronizedDemo {
public void method() {
synchronized (SynchronizedDemo.class) {
}
}
}重点要理解，synchronized 锁的是什么. 两个线程竞争同一把锁, 才会产生阻塞等待.
两个线程分别尝试获取两把不同的锁, 不会产生竞争.
2.1.3Java 标准库中的线程安全类
Java 标准库中很多都是线程不安全的. 这些类可能会涉及到多线程修改共享数据, 又没有任何加锁措施.
- ArrayList
- LinkedList
- HashMap
- TreeMap
- HashSet
- TreeSet
- StringBuilder
但是还有一些是线程安全的. 使用了一些锁机制来控制.
- Vector (不推荐使用)
- HashTable (不推荐使用)
- ConcurrentHashMap
- StringBuffer
StringBuffer 的核心方法都带有 synchronized .
还有的虽然没有加锁, 但是不涉及 "修改", 仍然是线程安全的
String
2.2volatile 关键字
2.2.1volatile 能保证内存可见性
volatile 修饰的变量, 能够保证 "内存可见性".
代码在写入 volatile 修饰的变量的时候,
- 改变线程工作内存中volatile变量副本的值
- 将改变后的副本的值从工作内存刷新到主内存
代码在读取 volatile 修饰的变量的时候,
- 从主内存中读取volatile变量的最新值到线程的工作内存中
- 从工作内存中读取volatile变量的副本
前面我们讨论内存可见性时说了, 直接访问工作内存(实际是 CPU 的寄存器或者 CPU 的缓存), 速度非常快, 但是可能出现数据不一致的情况.
加上 volatile , 强制读写内存. 速度是慢了, 但是数据变的更准确了.
public class ThreadDemo14 {
volatile public static int flag=0;
public static void main(String[] args) {
Thread t1=new Thread(()->{
while(flag==0){
//空着存在内存泄漏，编译器会自动优化
}
System.out.println("循环结束，线程一结束");
});
Thread t2=new Thread(()->{
Scanner input=new Scanner(System.in);
System.out.println("请输入一个整数：");
flag=input.nextInt();
});
t1.start();
t2.start();
}
}
2.2.2volatile 不保证原子性
volatile 和 synchronized 有着本质的区别. synchronized 能够保证原子性, 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.
2.2.3禁止指令重排序
