多线程初阶-线程安全 (面试和工作的重点！！！)
4. 多线程带来的的⻛险-线程安全 (重点)
整个多线程最关键的要点
1.面试
2.工作
如果不理解线程安全问题,很难保证写出正确的多线程代码的,
4.1 线程安全的概念
想给出⼀个线程安全的确切定义是复杂的，但我们可以这样认为：如果多线程环境下代码运⾏的结果是符合我们预期的（即在单线程环境应该的结果），则说这个程序是线程安全的。
某个代码,无论是在单个线程还是多个线程下执行,都不会产生 bug.这个情况就称为"线程安全”。如果单线程下运行正确,但是多线程下就可能会产生 bug，这个情况就称为"线程不安全"或"存在线程安全问题”
4.2 观察线程不安全
// 此处定义⼀个 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, 肯定不⾏的. 线程还没⾃增完, 就开始打印了. 很可能打印出来的 count 就是个 0t1.join();t2.join();// 预期结果应该是 10wSystem.out.println("count: " + count);
}
t1.join();
t2.join();
这俩线程, 谁先 join, 谁后 join 无所谓~~
如果不加join,按理说,一个线程自增 5w 次,两个线程,一共自增 10w 次，最终结果应该是 10w。非但这里的结果不是 10w，并且每次运行的结果都不同!!!
实际结果不符合预期,就是 bug !!!上述这个循环自增的代码,就属于是"存在线程安全问题"的代码
站在 cpu 执行指令的角度:
count++相当于 +=1，这个 count++ 其实是三个 cpu 指令构成的
如果是一个线程执行上述的 三个 指令,当然没问题。如果是两个线程,并发的执行上述操作,此时就会存在变数!!!(线程之间调度的顺序是不确定的!!)
这里一共有多少种情况??其实是无数种情况!!!
这里需要分析清楚,什么样的顺序下,执行结果是对的 (两次 ++,得到的结果是 2)，什么顺序下结果不对(两次 ++,结果不是 2)
线程的随机调度/抢占式执行~~ 在循环自增 5w 过程中,一旦运算过程中,中间的结果出现类似上面这种形态，这时候得到的最终结果就一定是 小于 10w 的.
4.3 线程不安全的原因
线程调度是随机的.
这是线程安全问题的罪魁祸首。随机调度使⼀个程序在多线程环境下, 执⾏顺序存在很多的变数。
程序猿必须保证 在任意执⾏顺序下 , 代码都能正常⼯作.
修改共享数据
多个线程修改同⼀个变量
上⾯的线程不安全的代码中, 涉及到多个线程针对 count 变量进⾏修改。此时这个 count 是⼀个多个线程都能访问到的 “共享数据”
原子性
什么是原⼦性
我们把⼀段代码想象成⼀个房间，每个线程就是要进⼊这个房间的⼈。如果没有任何机制保证，A进⼊房间之后，还没有出来；B 是不是也可以进⼊房间，打断 A 在房间⾥的隐私。这个就是不具备原⼦性的。
那我们应该如何解决这个问题呢？是不是只要给房间加⼀把锁，A 进去就把⻔锁上，其他⼈是不是就进不来了。这样就保证了这段代码的原⼦性了。
有时也把这个现象叫做同步互斥，表⽰操作是互相排斥的。
⼀条 java 语句不⼀定是原⼦的，也不⼀定只是⼀条指令
⽐如刚才我们看到的 n++，其实是由三步操作组成的：
1.从内存把数据读到 CPU
2.进⾏数据更新
3.把数据写回到 CPU
不保证原⼦性会给多线程带来什么问题
如果⼀个线程正在对⼀个变量操作，中途其他线程插⼊进来了，如果这个操作被打断了，结果就可能是错误的。
这点也和线程的抢占式调度密切相关. 如果线程不是 “抢占” 的, 就算没有原⼦性, 也问题不⼤.
可见性
可⻅性指, ⼀个线程对共享变量值的修改，能够及时地被其他线程看到.
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.去前台取下 U 盘
2.去教室写 10 分钟作业
3.去前台取下快递
如果是在单线程情况下，JVM、CPU指令集会对其进⾏优化，⽐如，按 1->3->2的⽅式执⾏，也是没问题，可以少跑⼀次前台。这种叫做指令重排序
编译器对于指令重排序的前提是 “保持逻辑不发⽣变化”. 这⼀点在单线程环境下⽐较容易判断, 但是在多线程环境下就没那么容易了, 多线程的代码执⾏复杂程度更⾼, 编译器很难在编译阶段对代码的执⾏效果进⾏预测, 因此激进的重排序很容易导致优化后的逻辑和之前不等价.
重排序是⼀个⽐较复杂的话题, 涉及到 CPU 以及编译器的⼀些底层⼯作原理, 此处不做过多讨论
4.4 解决之前的线程不安全问题
如何解决线程安全问题？
知道了原因,就可以对症下药了：
- [根本]操作系统对于线程的调度是随机的：抢占式执行
操作系统的底层设定.咱们左右不了
能否自己写个操作系统,取缔抢占式执行,不就解决线程安全问题了嘛??
理论上当然可行,实际上难度太大了~（1）技术上本身就非常难（2）推广上难上加难 - 多个线程同时修改同一个变量
和代码的结构直接相关。可以调整代码结构,规避一些线程不安全的代码（Java 中有个东西，String 就是采取了"不可变"特性,确保线程安全）
但是这样的方案,不够通用。有些情况下,需求上就是需要多线程修改同一个变量的。比如超买/超卖的问题~ 某个商品,库存 100 件, 能否创建出 101 个订单? - 修改操作,不是原子的.
乍看起来,count++,生成几个指令,咱们也无从干预。但是实际上，可以通过特殊手段,把这三个指令打包到一起,成为"整体”。
Java 中解决线程安全问题,最主要的方案!
加锁
通过加锁操作,让不是原子的操作,打包成一个原子的操作。计算机中的锁,和生活中的锁,是同样的概念! 锁具有"互斥”“排他"这样的特性
把锁"锁上"称为"加锁”，把锁"解开" 称为"解锁"。一旦把锁加上了,其他人要想加锁,就得阻塞等待
就可以使用锁,把刚才不是原子的 count++ 包裹起来。在 count++ 之前, 先加锁。然后进行 count++.计算完毕之后,再解锁。执行 3 步走 过程中,其他线程就没法 插队了
加锁操作,不是把线程锁死到 cpu 上,禁止这个 线程被调度走。而是禁止其他线程重新加这个锁,避免其他线程的操作!在当前线程执行过程中插队
在 java 中,加锁方式,有好多种，最主要使用的方式：synchronized 关键字~
加锁的目的,是为了把 三个操作,打包成一个原子的 操作
咱们这个代码的写法,是每次 count++ 之前,加锁。count++ 完了之后就释放了
前面说,加锁是把 count++ 这三步操作变成原子了。但是很明显,并非是加锁之后,执行三个操作过程中,线程就不调度了（准确说, 通过锁竞争让第二个线程的指令无法插入到第一个线程的执行指令中间，而不是禁止第一个线程被调度出 cpu ），而是即使加锁的线程被调度走了,其他线程也无法"插队执行”
可能有人会有疑问，这样不就串行执行了嘛？那效率不是有点慢？
加锁之后, 确实会影响到 多线程 的执行效率。但是即使如此,也是比你一个线程串行执行要更快的!!!
这样做仍然是有意义的.仍然要比所有的代码都在串行执行要更快.
实际上开发中,往往一个线程里要完成很多工作1,2,3,4,5··· 很多工作中,只有某个,某几个,才需要加锁, 剩下其他的都是可以并发的。比如,1,2,3, 4,5 其中 1,2,3,5 都能并发执行,4 需要加锁串行执行…
能否把 synchronized 放到 for 的外面呢?
这种情况 在计算所有的 count++ 之前,加锁。计算完所有的 count++ 之后释放锁。
引入多线程, 就是为了 并发 执行，就是为了充分利用 cpu 多核心资源。多进程编程 和 多线程编程 就是在利用多核心的编程手法。
日常工作中，一般都是让加锁范围尽量的小。这样的话,可以并发执行的逻辑就更多，此时外部的逻辑通常是更复杂的~~
// 此处定义⼀个 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, 肯定不⾏的. 线程还没⾃增完, 就开始打印了. 很可能打印出来的
count 就是个 0t1.join();t2.join();// 预期结果应该是 10wSystem.out.println("count: " + count);
}
这⾥⽤到的机制，⻢上会给⼤家解释。
5. synchronized 关键字 - 监视器锁 monitor lock
（JVM 中采用的一个术语。使用锁的过程中抛出一些异常，可能会看到 监视器锁 这样的报错信息）
5.1 synchronized 的特性
（1） 互斥
synchronized 会起到互斥效果, 某个线程执⾏到某个对象的 synchronized 中时, 其他线程如果也执⾏到同⼀个对象 synchronized 就会阻塞等待.
• 进⼊ synchronized 修饰的代码块, 相当于 加锁
• 退出 synchronized 修饰的代码块, 相当于 解锁
synchronized用的锁是存在Java对象头⾥的。
可以粗略理解成, 每个对象在内存中存储的时候, 都存有⼀块内存表⽰当前的 “锁定” 状态(类似于厕所的 “有⼈/⽆⼈”).
如果当前是 “⽆⼈” 状态, 那么就可以使⽤, 使⽤时需要设为 “有⼈” 状态.
如果当前是 “有⼈” 状态, 那么其他⼈⽆法使⽤, 只能排队
理解 “阻塞等待”.
针对每⼀把锁, 操作系统内部都维护了⼀个等待队列. 当这个锁被某个线程占有的时候, 其他线程尝试进⾏加锁, 就加不上了, 就会阻塞等待, ⼀直等到之前的线程解锁之后, 由操作系统唤醒⼀个新的线程,再来获取到这个锁.
注意:
• 上⼀个线程解锁之后, 下⼀个线程并不是⽴即就能获取到锁. ⽽是要靠操作系统来 “唤醒”. 这也就是操作系统线程调度的⼀部分⼯作.
• 假设有 A B C 三个线程, 线程 A 先获取到锁, 然后 B 尝试获取锁, 然后 C 再尝试获取锁, 此时 B 和 C都在阻塞队列中排队等待。 但是当 A 释放锁之后, 虽然 B ⽐ C 先来的, 但是 B 不⼀定就能获取到锁，⽽是和 C 重新竞争, 并不遵守先来后到的规则.
锁, 本质上也是操作系统提供的功能,内核提供的功能 =>通过 api 给应用程序了。java (VM)对于这样的系统 api 又进行了封装.
synchronized 是调用 系统的 api 进行加锁。系统 api 本质上是靠 cpu 上的特定指令完成加锁
（2）可重⼊
synchronized 加锁的效果,也可以称为"互斥性。synchronized 还有一些其他特性：
理解 “把⾃⼰锁死”
⼀个线程没有释放锁, 然后⼜尝试再次加锁.
// 第⼀次加锁, 加锁成功
lock();
// 第⼆次加锁, 锁已经被占⽤, 阻塞等待.
lock();
按照之前对于锁的设定, 第⼆次加锁的时候, 就会阻塞等待. 直到第⼀次的锁被释放, 才能获取到第⼆个锁. 但是释放第⼀个锁也是由该线程来完成, 结果这个线程已经躺平了, 啥都不想⼲了, 也就⽆法进⾏解锁操作. 这时候就会 死锁.
这样的锁称为 不可重⼊锁
for (int i = 0; i < 50000; i++) {synchronized (locker) {synchronized (locker) {count++;}}
}
看起来是两次一样的加锁,没有必要。但是实际上开发中,很容易写出这样的代码的。
一旦方法调用的层次比较深,就搞不好容易出现这样的情况
要想解除阻塞,需要往下执行才可以，要想往下执行就需要等到第一次的锁被释放，这样的问题,就称为"死锁”。
这样的代码在 Java 中其实是不会死锁的!!! 为了避免程序猿粗心大意搞出死锁！java引入了"可重入机制"，Java 中的 synchronized 是 可重⼊锁, 因此没有上⾯的问题。
最外层“ { ”真正加锁
最外层“ }” 真正解锁
站在 JVM 的视角,看到多个}需要执行，JVM 如何知道哪个}是真正解锁的那个??
先引入一个变量,计数器(0)，每次触发{的时候,把计数器++，每次触发 } 的时候,把计数器 - -，当计数器 - - 为 0 的时候, 就是真正需要解锁的时候~
在可重⼊锁的内部, 包含了 “线程持有者” 和 “计数器” 两个信息：（1）如果某个线程加锁的时候, 发现锁已经被⼈占⽤, 但是恰好占⽤的正是⾃⼰, 那么仍然可以继续获取到锁, 并让计数器⾃增.（2）解锁的时候计数器递减为 0 的时候, 才真正释放锁. (才能被别的线程获取到)
死锁是面试中考察的重点，也是工作中,多线程开发中非常核心的注意事项~~
若面试官的问题:
如何自己实现一个可重入锁?
1.在锁内部记录当前是哪个线程持有的锁,后续每次加锁,都进行判定
2.通过计数器,记录当前加锁的次数,从而确定何时真正进行解锁,
死锁（死锁的进一步讨论）
“死锁”是多线程代码中的一类经典问题， 加锁是能解决线程安全问题,但是如果加锁方式不当,就可能产生死锁!!
死锁同样也是经典面试题!!
死锁的三种典型场景：
场景1. 一个线程, 一把锁.
刚才说情况 如果锁是不可重入锁,并且一个线程针对一个锁对象,连续加锁两次，就会出现死锁（钥匙锁屋里了）
通过引入可重入锁,问题就迎刃而解了
场景2. 两个线程,两把锁
两个线程,两把锁，每个线程获取到一把锁之后,尝试获取对方的锁。线程1 获取到 锁A，线程2 获取到 锁B，接下来1 尝试获取 B,2 尝试获取 A，就同样出现死锁了!!!（屋钥匙锁车里了，车钥匙锁屋里了）
如果不加 sleep, 很可能 t1 一口气就把 locker1 和 locker2 都拿到了.这个时候,t2 还没开动呢~ 自然无法构成死锁.
经典面试题:让你手写一个出现死锁的代码：
C++方向,代码就好写,直接加锁两次就行了
Java 方向,就得通过上述代码,两个线程两把锁,精确控制好加锁的顺序
这里也就需要让我们知道，如果遇到死锁问题，就可以通过上述调用栈+状态进行定位了
场景3. N 个线程 M 把锁
一个经典的模型，哲学家就餐问题(学校的操作系统课上,也会有这个东西)
死锁,非常严重的问题~~ 属于程序中最严重的一类 bug !!!
一旦出现死锁,线程就"卡住了"无法继续工作，一个进程中的线程个数,就那么多。更可怕的是,死锁这种bug, 往往都是概率 出现，测试的时候怎么测试都没事，一发布就出问题，发布了也没问题,等到夜深人静,大家都睡着,突然给你整出点问题！比 bug 更可怕的是,“概率性出现的 bug”。虽然概率小,但是我们也需要重视!! 假设上述问题的 概率是 万分之一,同样是需要我们处理的，当时阿里这边的服务器每天的访问量是 3亿次，每天就有 3万个用户,触发了这个 bug！
如何避免死锁问题?
教科书上经典的,死锁的四个必要条件 !!!(下列四个条件,要求大家背下来!!面试经典问题!!)必要条件: 缺一不可！任何一个死锁的场景,都必须同时具备上述四点，只要缺少一个,都不会构成死锁。
1.锁具有互斥特性.
一个线程拿到锁之后,其他线程就得阻塞等待（锁最基本的特性.，不太好破坏）
2.锁不可抢占(不可被剥夺)
一个线程拿到锁之后,除非他自己主动释放锁,否则别人抢不走~~（也是锁最基本的特性.，也不好破坏）
3.请求和保持
一个线程拿到一把锁之后,不释放这个锁的前提下,再尝试获取其他锁。（如果先放下左手的筷子,再拿右手的筷子, 就不会构成死锁! 代码中加锁的时候,不要去“嵌套”。这种做法, 通用性, 不够的。 嵌套,很难避免：有些情况下,确实是需要拿到多个锁, 再进行某个操作的.）
4.循环等待. 多个线程获取多个锁的过程中,出现了循环等待。A 等待 B, B 也等待 A 或者 A 等待 B,B 等待 C, C 等待 A。（约定好加锁的顺序（比如按照编号从小到大的顺序）,就可以破除循环等待了）
解决死锁问题,核心思路, 破坏上述的必要条件,只要能破坏一个,就搞定!!上述破坏3 4两种 是开发中比较实用的方法，还有一些其他方案,也能解决死锁问题.但引入加锁顺序的规则（普适性高, 方案容易落地)
死锁的小结：
死锁这里非常重要的，时面试高频的问题。
"谈谈你对于死锁的理解”
死锁:
1.死锁是啥
2.死锁的三个场景
3. 死锁的危害
4.死锁的必要条件, 如何解决死锁
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 修饰普通方法, 相当于给 this 加锁 (锁对象 this)
synchronized 修饰静态方法,相当于给类对象加锁
我们重点要理解，synchronized 锁的是什么.
两个线程竞争同⼀把锁, 才会产⽣阻塞等待.
两个线程分别尝试获取两把不同的锁, 不会产⽣竞争.
- 如果我一个线程加锁,一个线程不加锁,是否会存在线程安全问题?
就不会出现锁竞争了!!!会存在线程安全问题 - 如果两个线程,针对不同的对象加锁呢？
也会存在线程安全问题
在一个程序中,锁,不一定只有一把。一个厕所,可能有多个坑位是一样的。每个坑位都有一个锁,如果你两个线程,针对不同的坑位加锁,不会产生互斥的(也称为 锁竞争/锁冲突)。只有是针对同一个坑位加锁,才有互斥。
代码中,可以创建出多个锁。具体写代码的时候,想搞几个锁,就搞几个。只有多个线程竞争同一把锁,才会产生互斥,针对不同的锁,则不会。 - 针对加锁操作的一些混淆的理解
把 count 放到一个 Test.t 对象中. 通过上述 add 方法来进行修改,加锁的时候锁对象,写作 this
synchronized (Test.class){ } 获取类对象 ：
在 java 代码中就可以通过类名.class 的方式拿到这个类对象。反射 api 就是从上述对象中获取信息的。
一个 java 进程中, 某个类,只能有唯一一个类对象
synchronized 的变种写法，可以使用 synchronized 修饰方法 。synchronized (this),也可以等价把 synchronized 加到方法上。
方法中还有一个特殊的情况：
static 修饰的方法,不存在 this.（static 修饰的方法,也叫做"类方法，不是针对"实例"的方法,而是针对类的,在这个方法中, 没有 this.） 此时, synchronized 修饰 static 方法, 相当于针对类对象加锁
其他编程语言中,加锁解锁, 都是单独的方法。对比其他语言，java 的加锁操作风格是独树一帜的。Java 中为啥使用 synchronized + 代码块 做法?而不是采用 lock + unlock 函数的方式来搭配呢?
像 C++ 这种写法, 就可能会,忘记调用 unlock(unlock 没有执行到)，如果忘记调用 unlock 其他线程都无法获取到这个锁， 产生严重的 bug!!
Java 采取的 synchronized, 就能确保, 只要出了 } 一定能释放锁. 无论因为 return 还是因为 异常，无论里面调用了哪些其他代码,都是可以确保 解锁 操作执行到的.
只要我写了 lock,就会立即加上 unlock 。这种说法,纯纯的,大猪蹄子行为,你给妹子保证,我这辈子只爱你一个,永远不会变心。就算你非常细心，能够确保每个 条件都加 unlock，但是你不能保证，你们组新来的实习生,也能做到这一点（各位同学们, 你们很可能就是这个实习生)
(其实在 Java 中,也有 lock/unlock 风格的锁, 一般很少使用)
但是c++没有 finally ,只能靠程序猿人工来保证了~~(很有可能,java 程序员代码早早写完，也没啥 bug, 下班回去打游戏了,C++ 程序员还在苦苦寻找哪里没有释放锁)。但是更新版本的 C++ 引入了 lock quard (守卫)这个东西,可以起到类似于 synchronized,代码块结束之后,就能自动释放锁。
5.3 Java 标准库中的线程安全类
- Java 标准库中很多都是线程不安全的. 这些类可能会涉及到多线程修改共享数据, ⼜没有任何加锁措施.（把加锁决策交给程序员）
线程不安全.多个线程,尝试修改同一个上述的对象,就很容易出现问题!! 而不是 100%，也可能你这个代码写出来之后,是没问题的，具体代码具体分析（多线程代码,稍微变换一点,就可能有不一样的结果）
• ArrayList
• LinkedList
• HashMap
• TreeMap
• HashSet
• TreeSet
• StringBuilder - 但是还有⼀些是线程安全的. 使⽤了⼀些锁机制来控制.
自带了锁, 在多线程环境下时候,能好点。也不是 100% 不出问题!! 只是概率比上面小很多，具体代码具体分析!!!（多线程代码,稍微变换一点, 就可能有不一样的结果）
像Vector，HashTable，StringBuffer 这几个类都属于是 标准库 即将弃用，不推荐使用,暂时还留着(保持和老的代码兼容）。这个时候,新的代码就不要用了，未来某一天新版本的 jdk,就把这些内容给删了。
• Vector (不推荐使⽤)
• HashTable (不推荐使⽤)
Java 早起,各位 Java 大佬还不够成熟时,引入的设定。现在的话这些设定已经被推翻了，不建议使用了.
• ConcurrentHashMap
相比于 HashTable 来说,高度优化的版本(后续详细分析)
• StringBuffer
StringBuffer 的核⼼⽅法都带有 synchronized .
一旦代码中, 使用了锁,意味着代码可能会因为锁的竞争,产生阻塞=>程序的执行效率大打折扣.
一定要思考清楚, 这个地方是否确食需要锁，不需要的时候不要乱加.
线程阻塞 =>从 cpu 上调度走，啥时候能调度回来继续执行???不好说了~~ 沧海桑田 - 还有的虽然没有加锁, 但是不涉及 “修改”, 仍然是线程安全的
• String
6. 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)
while(flag == 0){
}
核心指令2条：
（1）load 从内存读取数据到 cpu 寄存器
（2）cmp（比较,同时会产生跳转）条件成立,继续顺序执行；条件不成立,就跳转到另外一个地址来执行。
由于上述代码,循环体是空着的.后续就没有别的指令. 当前循环旋转速度很快，短时间内出现大量的load 和 cmp 反复执行的效果~~load 执行消耗的时间,会比 cmp 多很多!!多个几干倍,上万倍!!cpu 寄存器的访问速度,也比内存速度快好几个数量级（内存访问速度比硬盘快好几个数量级）
这个执行过程中有两个关键要点:
（1）上述执行过程中,load 速度非常慢，load 操作开销远远超过 条件跳转 !! 执行 一次 load 消耗的时间,顶几干次,上万次 cmp 执行的时间
（2）另外,JVM 还发现每次 load 执行的结果,其实是一样的（要想输入, 过几秒才能输入，在这几秒之内，已经执行了不知道多少次循环(上百亿) ）
干脆,JVM 就把上述 load 操作优化掉了：只是第一次真正进行 load，后续再执行到对应的代码,就不再真正 load 了,而是直接读取刚才已经 load 过的寄存器中的值了。把速度慢的给优化掉了，使程序执行速度更快了。
编译器优化
主流编程语言, 编译器的设计者 (对于 Java 来说,谈到的编译器包括 javac 和 jvm)考虑到一个问题: 实际上写 代码的程序员,水平是参差不齐的(差距很大的)。虽然有的程序员水平不高,写的代码效率比较低,编译器在编译执行的时候,分析理解现有代码的意图和效果,然后自动对这个代码进行调整和优化,在确保程序执行逻辑不变的前提下,提高程序的效率。
编译器优化 的效果是很明显~~服务器开启优化,启动时间可能 10min 左右，如果不开启优化,启动时间可能 1h 以上（这个服务器,启动好了要从硬盘上加载 100 多个 G 的数据，cpu 和 IO都是密集的）。
但是大前提是"程序的逻辑不变”。大多数情况下,编译器优化, 都可以做到"逻辑不变"前提，但是在有些特定场景下,编译器优化可能出现"误判"导致逻辑发生改变（想让编译器正确保持,没那么容易。如果是单线程下还好，如果是多线程下,很容易出现误判的!!!）。
优化固然挺好, 是提高效率了.但是因为优化引入 bug，也不合适。（某某公司进行"优化”，其实就是裁员。裁员裁到大动脉了。）
t1 读的是⾃⼰⼯作内存中的内容.上述把 load 优化掉, 导致后续当 t2 对 flag 变量进⾏修改, 此时 t1 感知不到 flag 的变化.(就没有后续 load)
小结: 上述问题本质上还是编译器优化引起的.t1 读的是⾃⼰⼯作内存中的内容.优化掉 load 操作之后,使 t1 线程感知不到 t2 线程的修改。"内存可见性"问题
内存可见性,高度依赖编译器的优化的具体实现,编译器啥时候触发优化,啥时候不触发优化,不好说!!!
上述代码如果稍微改动一点,就可能截然不同了：
如果上述代码中,循环体内存在 IO 操作或者 阻塞操作(sleep)，这就会使循环的旋转速度大幅度降低了。
IO 操作：
（1）load，cmp，I0操作 中 I0操作占大头！！此时就没有优化 load 的必要了。（2）另外, IO 操作是不能被优化掉的！！刚才 load 被优化的前提是反复 load 的结果相同，IO 操作,注定是反复执行的结果是不相同的
阻塞操作(sleep)：
不加 sleep，一秒钟循环上百亿次，load 操作的整体开销非常大,优化的迫切程度就更高。加了 sleep, 一秒钟循环 1000 次load 整体开销就没那么大了.优化的迫切程度就降低了.
所以 内存可见性 问题,其实是个高度依赖编译器优化的问题。啥时候触发这个问题（优化）,啥时候不触发（不优化）,不好说。更希望,让咱们代码能够确保,无论当前这个线程代码咋写的,都不要出现这种内存可见性问题。
java 提供了 volatile （强制读取内存！！开销是大了,效率是低了,数据的准确性/逻辑的正确性,提高了），就可以使上述的优化被强制关闭,可以确保每次循环条件都会重新从内存中读取数据了。更多的时候,快没有准更重要的。确实也有时候需要快,不需要准，就不加 volatile。引入 volatile 关键字, 把选择权,交给了程序猿自己。
谈到 volatile ->谈到一个词：JMM
Java 内存模型JMM (Java Memory Model)
Java 规范文档上提到的一个抽象的概念. Java 官方文档的术语.
每个线程,有一个自己的“工作内存”（work memory），同时这些线程共享同一个"主内存”（main memory）。当一个线程循环进行上述读取变量操作的时候,就会把主内存中的数据,拷贝到该线程的工作内存中。后续另一个线程修改,也是先修改自己的工作内存,拷贝到主内存里。由于第一个线程仍然在读自己的工作内存,因此感知不到主内存的变化。
咱们前面讲的是,把读内存的操作,优化成读寄存器操作。同样的意思！！！这里的“工作内存”其实不是咱们说的内存，CPU 的寄存器和缓存,统称为 work memory（工作内存）！！内存专业术语 就是 main memory，“主内存” 才是咱们真正所说的内存。
为啥引入 JMM (主内存,工作内存) 这一套抽象的概念, 而不是直接说 CPU 寄存器？
主要是为了"跨平台”！为了能够兼容不同的硬件设备。不同的 cpu, 用来缓存上述内存数据的区域,可能不同的.Java 程序员不需要关心,硬件(CPU) 差别的。不同 cpu寄存器情况不一样,缓存有没有也不一样, 缓存有几级也不一样…变数比较多… 搞 Java 的大佬希望咱们不必关注这些细节的。而且,作为规范文档,要严谨表述，每次都说 优化到 cpu 寄存器或缓存中… (非常拗口)
Java 文档为了严谨 也为了表述的没那么绕,就引入了 工作内存 这个概念,代指 cpu 寄存器 + 缓存这一套东西。存储数据, 不只是有内存,还有 外存 (硬盘), 还有 cpu 寄存器,cpu 上还有缓存
面试的时候,被问到内存可见性问题：
就可以按照第一种方式（CPU 寄存器 和 内存）或者第二种方式（JMM：主内存和工作内存）来表述。
我们要知道：内存可见性问题是咋回事，怎么来的, 原因(CPU 寄存器 和 内存/JMM)，volatile 能够解决的问题是啥样的, 啥样的问题不能解决。
如果给 flag 加上 volatile
public volatile int flag = 0;// 执⾏效果
// 当⽤⼾输⼊⾮0值时, t1 线程循环能够⽴即结束.
类似的,上述内存可见性问题,使用 synchronized 也能一定程度的解决~~ 引入 synchronized 其实是因为 加锁操作 本身太重量了.相比于 load 来说, 开销更大,编译器自然就不会对 load 优化了.(和加上sleep/io 操作一样)
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.
volatile 这个关键字, 能够解决内存可见性问题引起的线程安全问题，但是不具备原子性这样的特点~~
synchronized 和 volatile 是两个不同的维度:
(两个线程修改)(一个线程读,一个线程修改)
7. wait 和 notify
线程的 等待通知 机制（协调线程之间的执行逻辑的顺序的）：
join 是等另一个线程彻底执行完, 才继续走。wait 是等到另一个线程执行 notify, 才继续走(不需要另一个线程执行完)，更精细的控制线程之间的执行顺序了。
由于系统内部,线程之间是抢占式执⾏的,随机调度， 因此线程之间执⾏的先后顺序难以预知。但是实际开发中有时候我们希望合理的协调多个线程之间的执⾏先后顺序。
程序员也是有手段干预的、通过"等待”的方式,能够让线程一定程度的按照咱们预期的顺序来执行。无法主动让某个线程被调度,但是可以主动让某个线程等待 (就给别的线程机会了)。
球场上的每个运动员都是独⽴的 “执⾏流” , 可以认为是⼀个 “线程”.
⽽完成⼀个具体的进攻得分动作, 则需要多个运动员相互配合, 按照⼀定的顺序执⾏⼀定的动作, 线程1 先 “传球” , 线程2 才能 “扣篮”.
完成这个协调⼯作, 主要涉及到三个⽅法
• wait() / wait(long timeout): 让当前线程进⼊等待状态.
• notify() / notifyAll(): 唤醒在当前对象上等待的线程.
注意: wait, notify, notifyAll 都是 Object 类的⽅法.
等待通知可以安排线程之间的 执行顺序,另外,wait notify 也能解决"线程饿死"的问题：
"线程饿死” 不是 死锁。只是因为 某个线程 频繁获取释放锁，由于获取的太快,以至于其他线程捞不着 cpu 资源.
当多个线程竞争一把锁的时候,获取到锁的线程如果释放了,其他是哪个线程拿到锁?
不确定(随机调度)
操作系统的调度是随机的，其他线程都属于在锁上阻塞等待,是阻塞状态，当前这个释放锁的线程，是就绪状态，这个线程有很大的概率能够再次拿到这个锁
系统中的线程调度无序,上述情况很可能出现(不至于长时间一直进进出出，进出个几十次 还是有可能)，不会像死锁那样卡死，但是可能会卡住一下下，对于程序的效率,肯定是影响的。
当拿到锁的线程,发现要执行的任务,时机还不成熟的时候,就使用 wait 阻塞等待
等待通知机制,就能够解决上述问题：通过条件,判定看当前逻辑是否能够执行.如果不能执行, 就主动 wait (主动进行阻塞)，就把执行的机会让给别的线程了，避免该线程进行一些无意义的重试。等到后续条件时机成熟了(需要其他线程进行通知的)，再让阻塞的线程被唤醒。
7.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()。
7.2 notify()⽅法
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;}@Overridepublic 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;}@Overridepublic 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();
}
7.3 notifyAll()⽅法
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 个线程需要竞争锁. 所以并不是同时执⾏, ⽽仍然是有先有后的执⾏.
理解 notify 和 notifyAll
notify 只唤醒等待队列中的⼀个线程. 其他线程还是乖乖等着
notifyAll ⼀下全都唤醒, 需要这些线程重新竞争锁
7.4 wait 和 sleep 的对⽐（⾯试题）
其实理论上 wait 和 sleep 完全是没有可⽐性的，因为⼀个是⽤于线程之间的通信的，⼀个是让线程阻塞⼀段时间，唯⼀的相同点就是都可以让线程放弃执⾏⼀段时间.
当然为了面试的⽬的，我们还是总结下：
（1） wait 需要搭配 synchronized 使⽤. sleep 不需要.
（2）wait 是 Object 的⽅法 sleep 是 Thread 的静态⽅法.