JUC(二)
通过本文档你将学习到
- 共享问题
- synchronized
- 线程安全分析
- Monitor
- wait/notify
- 线程状态转换
- 活跃性
- Lock
1 共享带来的问题
我们先从一个小故事开始讲起:
话说500年前,老王有一个日记本,然后想租出去赚点钱,然后转给了小王。但是小王也不是24小时一直用这个日记本,有时候他会睡觉,有时他会出去玩。
资本的力量,让老王萌生了一个天才的想法。再把这个日记本租一次,当然那时候是合法的,虽然现在好多开发商一个房子卖两次。小王不用的时候,小李用。两个交替使用。问题来了:
1、小王在一个加法运算,刚开始是0,然后+1后准备写到日记本上1,但是时间到了,轮到小李了。
2、小李是做减法运算,看到0然后-1 然后准备写上-1,时间也到了。
3、这时候小王又拿到笔记本了,直接1写了上去完事,出去玩了
4、笔记本这时候到小李这里了,直接把-1给写了上去。
5、小李后来一查,我xxx 什么鬼?明明是1怎么变成-1了?
@Slf4j(topic = "c.Test17")
public class Test17 {
public static void main(String[] args) throws InterruptedException {
Room room = new Room();
Thread t1 = new Thread(() -> {
for (int i = 0; i < 5000; i++) {
room.increment();
}
}, "t1");
Thread t2 = new Thread(() -> {
for (int i = 0; i < 5000; i++) {
room.decrement();
}
}, "t2");
t1.start();
t2.start();
//大致理解为,当前线程运行到这个方法时,会被挂起。而只有调用join方法的线程运行完毕 当前线程才继续运行。
t1.join();
t2.join();
log.debug("{}", room.getCounter());
}
}
以上的结果可能是正数、负数、零。为什么呢?因为 Java 中对静态变量的自增,自减并不是原子操作,要彻底理解,必须从字节码来进行分析
这里不介绍字节码这种东西,你可以参考小故事,就是小王计算完和写道纸上这是两个动作,一旦被分割(上下文切换)那么可能会出问题哦。
- 一个程序运行多个线程本身是没有问题的
- 问题出在多个线程访问共享资源
- 多个线程读共享资源其实也没有问题
- 在多个线程对共享资源读写操作时发生指令交错,就会出现问题
- 一段代码块内如果存在对共享资源的多线程读写操作,称这段代码块为临界区
例如,下面代码中的临界
class Room {
private int counter = 0;
public void increment() {
//临界区
counter++;
}
public void decrement() {
//临界区
counter--;
}
public synchronized int getCounter() {
return counter;
}
}
多个线程在临界区内执行,由于代码的执行序列不同而导致结果无法预测,称之为发生了竞态条件
为了避免临界区的竞态条件发生,有多种手段可以达到目的。
- 阻塞式的解决方案:synchronized,Lock
- 非阻塞式的解决方案:原子变量
本次课使用阻塞式的解决方案:synchronized,来解决上述问题,即俗称的【对象锁】,它采用互斥的方式让同一
时刻至多只有一个线程能持有【对象锁】,其它线程再想获取这个【对象锁】时就会阻塞住。这样就能保证拥有锁
的线程可以安全的执行临界区内的代码,不用担心线程上下文切换
class Room {
private int counter = 0;
public synchronized void increment() {
counter++;
}
public synchronized void decrement() {
counter--;
}
public synchronized int getCounter() {
return counter;
}
}
你可以做这样的类比:
- synchronized(对象) 中的对象,可以想象为一个房间(room),有唯一入口(门)房间只能一次进入一人
进行计算,线程 t1,t2 想象成两个人 - 当线程 t1 执行到 synchronized(room) 时就好比 t1 进入了这个房间,并锁住了门拿走了钥匙,在门内执行
count++ 代码 - 这时候如果 t2 也运行到了 synchronized(room) 时,它发现门被锁住了,只能在门外等待,发生了上下文切
换,阻塞住了这中间即使 t1 的 cpu 时间片不幸用完,被踢出了门外(不要错误理解为锁住了对象就能一直执行下去哦),这时门还是锁住的,t1 仍拿着钥匙,t2 线程还在阻塞状态进不来,只有下次轮到 t1 自己再次获得时间片时才能开门进入
-当 t1 执行完 synchronized{} 块内的代码,这时候才会从 obj 房间出来并解开门上的锁,唤醒 t2 线程把钥
匙给他。t2 线程这时才可以进入 obj 房间,锁住了门拿上钥匙,执行它的 count-- 代码
线程八锁的一些小测试题,就是考试锁对象是谁?
如果synchronized加在一个类的普通方法上,那么相当于synchronized(this)。
如果synchronized加载一个类的静态方法上,那么相当于synchronized(Class对象)。
2 Monitor(锁)
我们还是从一个小故事来吧。
现在我们的快递非常发达,寄快递送快递非常方便。现在先让小王出场,小王寄快递都是用的东风快递,你知道的东风快递,只要是地球上很快都能快速送达。但是成本很高呀。就想怎么省钱。小王做了一个表格本市的快递自己骑车去送,本省的用四通一达,外省的用顺丰空运。这样成本就下来的。
同样的,我们加锁上来就加个重量级的锁,有时候没必要,本来就没有锁竞争。就像人家说送快递,人家说就送到对面的小区就行,你立马说用东风快递吗?