JavaEE-多线程初阶(3)
目录
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);}
}按照道理来说，count进行了总共十万次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中解决线程安全问题，最主要的方案就是：加锁
通过加锁操作，让不是原子的操作，打包成一个原子的操作
计算机中的锁，和生活中的锁，是同样的概念：互斥/排他
把锁“锁上”称为“加锁”
把锁“解开”称为“解锁”
一旦把锁加上了，其他人要想加锁，就得阻塞等待
对于上述例子的count++操作，它并非是原子的，此时就可以使用锁，把刚才不是原子的count++
包裹起来，在count++之前，先加锁，然后进行count++，计算完毕之后，再解锁
（此时在执行三步走的过程中，其他线程就没法“插队”了）
加锁操作，不是把线程锁死到cpu上，禁止这个线程被调度走
而是禁止其他线程重新加这个锁，避免其他线程的操作在当前线程执行的过程中“插队”
加锁：synchronized
加锁 / 解锁 本身是操作系统提供的api
很多编程语言都对这样的api进行了封装
大多数的封装风格，都是采取两个函数：
加锁 lock();
//执行一些要保护起来的逻辑
解锁 unlock();
Java中使用 synchronized 这样的关键字，搭配代码块来实现类似的效果：
synchronized(){ //进入代码块，相当于加锁
//执行一些要保护起来的逻辑
}出了代码块，相当于解锁
使用synchronized对上述案例进行加锁：
可以看到括号内需要填入参数，应该填入什么呢？
填写的是，用来加锁的对象。要 加锁 / 解锁，前提是得先有一个锁
在Java中任何一个对象都可以用作“锁”
这个对象的类型是什么不重要
重要的是，是否有多个线程针对这同一个对象加锁（竞争同一把锁）
再次执行代码，线程安全问题得到了解决：
【注意】
两个线程，针对同一个对象加锁，才会产生互斥效果
（一个线程加上了锁，另一个线程就得阻塞等待，等到第一个线程释放锁，才有机会）
如果是不同的锁对象，此时不会有互斥效果，线程安全问题并没有得到解决：
代码执行结果，依旧存在线程安全问题：
synchronized的变种写法
可以使用 synchronized 修饰方法
这种写法跟之前的写法产生的效果是一样的，执行代码：
修饰方法的写法还能继续变形：使用synchronized修饰方法，就相当于是针对this进行加锁
这种写法跟上面的效果也是一样的。
StringBuffer、Vector这些类里面有些方法就是带有synchronized的：
因此，StringBuffer是线程安全的，而StringBuilder线程不安全。
而方法之中，还有一个特殊情况，static修饰的方法不存在this
此时，synchronized修饰static方法相当于针对类对象加锁：
完
如果哪里有疑问的话欢迎来评论区指出和讨论，如果觉得文章有价值的话就请给我点个关注还有免费的收藏和赞吧，谢谢大家
