目录
1.线程的状态
1.1 NEW、RUNNABLE、TERMINATED
1.2 TIMED_WAITING
1.3 WAITING
1.4 BLOCKED
2.多线程带来的风险-线程安全（重点）
2.1 观察线程不安全的征象
2.2 分析产生该征象的原因
2.3 产生线程安全问题的原因
2.3.1 抢占式执行（根本）
2.3.2 多个线程同时修改同一个变量
2.3.3 修改操纵，不是原子的
2.3.4 内容可见性问题
2.3.5 指令从排序
2.4 怎样解决线程安全问题
2.4.1 抢占式执行
2.4.2 多个线程同时修改同一个变量
2.4.3 修改操纵，不是原子的
解决方案
加锁：synchronized
synchronized的变种写法
1.线程的状态
线程的所有状态如下：
• NEW: 安排了⼯作, 还未开始⾏动 • RUNNABLE: 可⼯作的. ⼜可以分成正在⼯作中和即将开始⼯作. • BLOCKED: 这⼏个都表⽰排队等着其他事情 • WAITING: 这⼏个都表⽰排队等着其他事情 • TIMED_WAITING: 这⼏个都表⽰排队等着其他事情 • TERMINATED: ⼯作完成了. 1.1 NEW、RUNNABLE、TERMINATED
对于这三个状态的解释：
NEW：new了Thread对象，还没start
RUNNABLE ：停当状态，可以分成以下两种情况（正在工作大概即将开始工作）：
（1）线程正在cpu上执行 （2）线程随时可以去cpu上执行 TERMINATED：内核中的线程已经结束了，但是Thread对象还在
- public static void main(String[] args) throws InterruptedException {
- Thread t1=new Thread(()->{
- System.out.println("线程t1开始执行...");
- try {
- Thread.sleep(1);
- } catch (InterruptedException e) {
- throw new RuntimeException(e);
- }
- System.out.println("t1线程结束...");
- });
- System.out.println(t1.getState());
- t1.start();
- Thread.sleep(0,500);
- System.out.println(t1.getState());
- t1.join();
- System.out.println(t1.getState());
- }
1.2 TIMED_WAITING
• 指定时间的阻塞
• 线程阻塞（不加入 cpu 调度，不继续执行了）
• 阻塞的时间是有上限的
Thread.sleep(时间);会进入到TIMED_WAITING状态
另外，join(时间)也会进入到TIMED_WAITING状态：
1.3 WAITING
死等，没有超时时间的阻塞等待
1.4 BLOCKED
也是一种阻塞，比较特别，是由于锁导致的阻塞。
2.多线程带来的风险-线程安全（重点）
2.1 观察线程不安全的征象
案例：
创建一个静态变量count=0;
在main方法里创建两个线程t1和t2
两个线程内分别循环五万次count++操纵
末了打印出count的值：
- public class Demo10 {
- public static int count=0;
- public static void main(String[] args) throws InterruptedException {
- 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);
- }
- }
这样的代码很明显是有bug的，实际执行效果与预期效果不符合就叫做bug。
这样的问题，是多线程并发执行引发的问题。
假如调换代码的执行程序，把t1线程和t2线程的并行改成串行（一个执行完了再执行另一个）
结果又酿成正确的了：
执行结果：
很明显，当前的bug是由于多线程的并发执行代码引起的bug
这样的bug，就称为“线程安全问题”，大概叫做“线程不安全”
反之，假如一个代码在多线程并发执行的环境下也不会出现雷同上述的bug
这样的代码就称为“线程安全”
2.2 分析产生该征象的原因
站在 CPU 的角度来看count++，这个操纵看起来是一行代码，实际上对应到三个CPU指令：
1.load，把内存中的值（count变量）读取到寄存器中
2.add，把指定的寄存器中的值进行+1操纵（结果还是在这个寄存器中）
3.save，把寄存器中的值，写回到内存中
CPU执行这三条指令的过程中，随时有可能触发线程的调度切换（如下所示）：
指令1 指令2 指令3 线程切走
指令1 指令2 线程切走 指令3
指令1 线程切走 指令2 指令3
指令1 线程切走 指令2 线程切走 指令3
但是由于操纵体系的调度是随机的，不可预期的
执行任何一个指令的过程中都有可能触发上述的“线程切换”的操纵
也就是说，随机调度（大概叫抢占式执行）就是线程安全问题的罪魁罪魁。
t1线程和t2线程的执行过程可能会出现如下情况（只举了个别例子，可能还有别的情况）：
对于执行结果：打 √ 的为正确结果，× 为错误结果。
对于其中某种正确情况的具体执行过程如下：
对于其中某种错误情况的具体执行过程如下：
可以看到：
t1线程和t2线程分别进行了一次count++操纵，理论上count的值应为2，实际上由于随机调度，t1的寄存器和t2的寄存器都读取了内存的初始值0，最终执行完两次count++后count的值为1
由于线程执行的过程中有可能（大概率）会发生上述的错误情况，因此代码的执行结果总是<=100000
假如降低单个线程的循环次数，会发现能运行出正确的结果：
运行结果：
出现这种征象的原因：
毕竟上，线程安全问题仍旧存在，只不过概率变低了。
单个线程执行的count++次数会影响到这个线程的运行时间，即运行50次比运行50000次要快得多
因为运行的太快了，很可能在t2.start()执行之前，t1线程就执行完了
等到后续t2线程的执行，就酿成了串行执行
2.3 产生线程安全问题的原因
2.3.1 抢占式执行（根本）
抢占式执行：操纵体系对于线程的调度是随机的
抢占式执行计谋
最初诞生于多使命操纵体系的时间，是非常重大的发明
后代的操纵体系，都是一脉相承
2.3.2 多个线程同时修改同一个变量
假如是一个线程，修改一个变量---没问题
假如是多个线程，不是同时修改同一个变量---没问题
假如是多个线程，修改不同变量---没问题（不会出现中间结果相互覆盖的情况）
假如是多个线程，读取同一个变量---没问题（该变量不可修改）
2.3.3 修改操纵，不是原子的
原子：
假如一个操纵只是对应到一个cpu指令，那么就可以认为它是原子的
cpu就不会出现“一条指令执行到一半”这样的情况
反之，假如一个操纵对应到多个cpu指令，那么它就不是原子的，例如：
++
--
+=
-=
........
2.3.4 内容可见性问题
后续再讨论
2.3.5 指令从排序
后续再讨论
2.4 怎样解决线程安全问题
2.4.1 抢占式执行
抢占式执行是操纵体系的底层设定，程序员无法左右。
2.4.2 多个线程同时修改同一个变量
和代码的结构直接相关
可以调整代码结构，规避一些线程不安全的代码
但是这样的方案不够通用
Java中有个东西：
String 就是接纳了“不可变”特性，确保线程安全
2.4.3 修改操纵，不是原子的
解决方案：
Java中解决线程安全问题，最重要的方案就是：加锁
通过加锁操纵，让不是原子的操纵，打包成一个原子的操纵
2.4.3.1 锁的概念
计算机中的锁，和生存中的锁，是同样的概念：互斥/排他
把锁“锁上”称为“加锁”
把锁“解开”称为“解锁”
一旦把锁加上了，其他人要想加锁，就得阻塞等待
对于上述例子的count++操纵，它并非是原子的，此时就可以使用锁，把刚才不是原子的count++
包裹起来，在count++之前，先加锁，然后进行count++，计算完毕之后，再解锁
（此时在执行三步走的过程中，其他线程就没法“插队”了）
加锁操纵，不是把线程锁死到cpu上，禁止这个线程被调度走
而是禁止其他线程重新加这个锁，避免其他线程的操纵在当前线程执行的过程中“插队”
2.4.3.2加锁：synchronized
加锁 / 解锁 自己是操纵体系提供的api
很多编程语言都对这样的api进行了封装
大多数的封装风格，都是接纳两个函数：
加锁 lock();
//执行一些要保护起来的逻辑
解锁 unlock();
Java中使用 synchronized 这样的关键字，搭配代码块来实现雷同的效果：
synchronized(){ //进入代码块，相称于加锁
//执行一些要保护起来的逻辑
}出了代码块，相称于解锁
使用synchronized对上述案例进行加锁：
可以看到括号内需要填入参数，应该填入什么呢？
填写的是，用来加锁的对象。要 加锁 / 解锁，前提是得先有一个锁
在Java中任何一个对象都可以用作“锁”
这个对象的类型是什么不重要
重要的是，是否有多个线程针对这同一个对象加锁（竞争同一把锁）
再次执行代码，线程安全问题得到了解决：
【注意】
两个线程，针对同一个对象加锁，才会产生互斥效果
（一个线程加上了锁，另一个线程就得阻塞等待，等到第一个线程开释锁，才有时机）
假如是不同的锁对象，此时不会有互斥效果，线程安全问题并没有得到解决：
代码执行结果，仍旧存在线程安全问题：
2.4.3.3 synchronized的变种写法
在方法内加锁：
这种写法跟之前的写法产生的效果是一样的，执行代码：
修饰方法的写法还能继续变形：使用synchronized修饰方法，就相称于是针对this进行加锁
这种写法跟上面的效果也是一样的。
StringBuffer、Vector这些类里面有些方法就是带有synchronized的：
因此，StringBuffer是线程安全的，而StringBuilder线程不安全。
而方法之中，还有一个特别情况，static修饰的方法不存在this
此时，synchronized修饰static方法相称于针对类对象加锁。
2.4.3.4 可重入
当我们使用锁写代码，一旦方法调用的条理比较深，搞不好就会出现这种情况（大概雷同的）：
分析上面这段代码：
1.第一次进行加锁（第一层），可以或许成功（锁没有人使用）
2.第二次进行加锁（第二层），此时的locker已经是被占用的状态，第二次加锁就会触发阻塞等待
要想排除阻塞，就必须往下执行
要想往下执行，就需要等到第一次的锁被开释
这样的问题，就被称为“死锁”(dead lock)
为了解决上述问题，Java的synchronized就引入了可重入的概念
当某个线程针对一个锁，加锁成功之后
后续该线程再次针对这个锁进行加锁
不会触发阻塞，而是直接往下走
因为当前这把锁就是被这个线程持有
但是假如是其他线程尝试加锁，就会正常阻塞
也就是说，当我们执行上述代码时，并不会触发死锁，而是正常执行：
可重入锁的实现原理，关键在于让锁对象内部保存，当前是哪个线程持有这把锁
后续有线程针对这个锁加锁的时间，对比一下，持有锁的线程是否和当前要加锁的线程是同一个
当有多层加锁时，最外层的加锁和解锁才是有效的，内部锁直接放行
站在JVM的角度，看到多个 } 需要执行，JVM怎样知道哪个 } 是真正需要解锁的谁人：
先引入一个变量，计数器（0）
每次触发 { 的时间，把计数器++
每次触发 } 的时间，把计数器--
当计数器 --到0的时间，就是真正需要解锁的时间
2.4.3.5 监视器锁
监视器锁 minitor lock
JVM中接纳的一个术语
使用锁的过程中抛出的一些异常，可能会看到 监视器锁 这样的报错信息
完
假如哪里有疑问的话欢迎来评论区指出和讨论，假如觉得文章有价值的话就请给我点个关注还有免费的收藏和赞吧，谢谢各人
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
