目录
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方法相当于针对类对象加锁:
完
如果哪里有疑问的话欢迎来评论区指出和讨论,如果觉得文章有价值的话就请给我点个关注还有免费的收藏和赞吧,谢谢大家