多线程引发的安全问题

  前言👀~

上一章我们介绍了线程的一些基础知识点,例如创建线程、查看线程、中断线程、等待线程等知识点,今天我们讲解多线程下引发的安全问题

线程安全(最复杂也最重要)

产生线程安全问题的原因

锁(重要)

synchronized 的特性

互斥性

刷新内存

可重入

死锁(重要)

volatile(重要)

JMM

volatile 和 synchronized 的区别

wait和notify方法

wait方法

notify方法

线程饿死

notifyAll方法

wait和sleep的区别


如果各位对文章的内容感兴趣的话,请点点小赞,关注一手不迷路,讲解的内容我会搭配我的理解用我自己的话去解释如果有什么问题的话,欢迎各位评论纠正 🤞🤞🤞

12b46cd836b7495695ce3560ea45749c.jpeg

个人主页:N_0050-CSDN博客

相关专栏:java SE_N_0050的博客-CSDN博客  java数据结构_N_0050的博客-CSDN博客  java EE_N_0050的博客-CSDN博客


线程安全(最复杂也最重要)


首先我们来看下面这段代码,猜一下它的输出结果

public class Test2 {public static int count;public static void main(String[] args) throws InterruptedException {Thread t1 = new Thread(() -> {for (int i = 0; i < 15000; i++) {count++;}});Thread t2 = new Thread(() -> {for (int i = 0; i < 15000; i++) {count++;}});t1.start();t2.start();t1.join();t2.join();System.out.println(count);}
}

输出结果:小于30000  不信的话可以去试试

按道理应该是输出3000啊为什么呢?这是由于多线程不安全问题的原因,执行的顺序是随机的!!!多核心cpu处理不同的线程和单线程处理不同的线程都可能会引发线程不安全。首先就count++这个操作在cpu进行处理的时候会分为三个步骤,先拿操作数count然后自增最后保存到内存中。下图中只有前两个执行顺序是正确的,其他都是错误的。

fb05b516f470f226d9787a3db5957032.jpeg

我们接着拆解细分,如果cpu都是按这个顺序去处理的话结果应该是预期的30000

7c7dac90c2cb7a4d1b3393591303986c.png

接着是不按套路出牌的,如下图所示,各执行了一次自增的操作但是结果count还是为1,这是因为不管单核心还是多核心在处理多线程时可能会被打断去执行其他线程的任务,都是因为该死的操作系统的调度器回根据一定的策略来分配cpu时间给不同的线程,导致执行的顺序是随机的不确定的

844dc85cf3e73ca0bf951f99cb2254b5.png

并且可能会出现结果小于15000,原因是因为可能在执行t1线程执行自增的操作后,然后去执行t2线程并且执行了两次自增,最后相当于就自增一次,如下图所示按照我标注的顺序看就能发现了

0eb08156af735db3e79a9fc22d1a1a70.png

产生线程安全问题的原因

1.操作系统中线程调度的顺序是随机的(抢占式执行)

2.不同线程针对同一变量进行修改

3.修改操作不是原子级的(先读再修改),类似数据库的原子性

4.内存可见性问题

5.指令重排序问题

我们该如何解决呢?跟数据库类似加锁!


锁(重要)

通过加锁解决上述问题,如何给java中的代码加锁呢?

1.synchronized()关键字(最常用的办法):使用synchronized的时候搭配代码块{}使用,进入这个代码块就是加锁,出了代码块就是解锁。后面进行解释

还是刚才的代码我们给它加上锁看看结果

public class Test2 {public static int count;public static void main(String[] args) throws InterruptedException {Object lock = new Object();Thread t1 = new Thread(() -> {for (int i = 0; i < 15000; i++) {synchronized (lock) {count++;}}});Thread t2 = new Thread(() -> {for (int i = 0; i < 15000; i++) {synchronized (lock) {count++;}}});t1.start();t2.start();t1.join();t2.join();System.out.println(count);}
}

输出结果,我们会发现这回输出的结果符合预期就是30000

74f1725381ebc5990390d0a12bbb19f8.png

为什么加锁了结果就正确了呢?看了下面的图你就能明白了,不明白的话我举个例子你去银行的ATM取款机取钱,你进入这个ATM就相当于加锁了这时候别人进不来,只能等你存或取完钱了然后出来了才能进去

90552e72e5a8ea7cd877c60b22a03009.png


synchronized 的特性

互斥性

重点就是我们并不关注这个锁对象,关注的是不同线程的锁对象是不是同一对象。

如果当前线程进入加锁的状态,另外一个线程也尝试进行加锁,就会产生锁冲突/锁竞争,后面这个线程就会阻塞等待,等到前一个线程解锁为止。synchronized后面的括号()是填需要进行加锁的对象,对象不重要,重要的是通过这个对象用来区分两个线程是否在竞争同一个锁。如果两个线程针对同一个对象加锁的时候,会有锁冲突/锁竞争。如果不是就没有锁竞争,仍然并发执行。有了这样的规则就把并发执行转为串行执行。抓住一个原则就是两个线程是不是针对同一个对象加锁!

还是刚才那段代码这也是为什么最后执行结果和我们预期的相符合的,就是因为锁的是对象是同一个,导致另外一个线程进入阻塞状态,等上个线程解锁了才能上锁

public class Test2 {public static int count;public static void main(String[] args) throws InterruptedException {Object lock = new Object();Thread t1 = new Thread(() -> {for (int i = 0; i < 15000; i++) {synchronized (lock) {count++;}}});Thread t2 = new Thread(() -> {for (int i = 0; i < 15000; i++) {synchronized (lock) {count++;}}});t1.start();t2.start();t1.join();t2.join();System.out.println(count);}
}

注意1:上一个线程解锁之后, 下一个线程并不是立即就能获取到锁. 而是要靠操作系统来 "唤醒". 这也就是操作系统线程调度的一部分工作

注意2:假设有 A B C 三个线程, 线程 A 先获取到锁, 然后 B 尝试获取锁, 然后 C 再尝试获取锁, 此时 B 和 C 都在阻塞队列中排队等待. 但是当 A 释放锁之后, 虽然 B 比 C 先来的, 但是 B 不一定就能获取到锁, 而是和 C 重新竞争, 并不遵守先来后到的规则这就是之前说的系统调度的随机性


对象头:

synchronized用的锁是存在Java对象头里的,java的一个对象,对应的内存空间中除了你自己定义的属性之外还有自带的属性。这些自带的属性就可以称为对象头中,对象头中,其中有属性表示当前对象是否加锁

4df4b1a8bd164807a632cb4881490794.png

对象头可以简单理解为, 每个对象在内存中存储的时候, 都存有一块内存表示当前的 "锁定" 状态,就像公共厕所的把手的颜色,红色代表有人你要等人出来了才能进去,绿色就是可以直接进去

补充:synchronized 除了可以修饰代码块,还可以修饰成员方法和静态方法

修饰成员方法:此时this就是锁对象

class Java {public int count;synchronized public void increase() {count++;}//上面是下面的简写public void increase1() {synchronized (this) {count++;}}
}public class Test3 {public static void main(String[] args) {Java java = new Java();java.increase1();System.out.println(java.count);}
}


修饰静态方法:针对类对象加锁

class Java {public static int count;synchronized public static void increase() {count++;}//上面是下面的简写public static void increase1() {synchronized (Java.class) {count++;}}}public class Test3 {public static void main(String[] args) {Java java = new Java();Java.increase1();System.out.println(Java.count);}
}

刷新内存

synchronized 的工作过程: 

1. 获得互斥锁

2. 从主内存拷贝变量的最新副本到工作的内存

3. 执行代码

4. 将更改后的共享变量的值刷新到主内存

5. 释放互斥锁

所以 synchronized 也能保证内存可见性. 具体代码参见后面 volatile 部分.


可重入

可重入锁指的是一个线程连续针对一把锁,加锁两次,不会出现死锁,满足这个要求,就是可重入锁,不满足就是不可重入锁(死锁),synchronized不会有这种情况,你可以去试试对两把不同的锁进行加锁

下面这个代码表示的就是可重入锁,对同一线程针对一把锁加锁两次

public class Test2 {public static int count;public static void main(String[] args) throws InterruptedException {Object lock = new Object();Thread t1 = new Thread(() -> {synchronized (lock) {synchronized (lock) {count++;}}});t1.start();t1.join();System.out.println(count);}
}

在上面的代码中有没有想过,如果一个锁加锁后另外一个锁怎么进行加锁的不应该等另外一个锁解锁后,后面这个锁才能进行加锁的嘛?如果是串行的那没什么事情,但是现在是嵌套的并行的情况。代码执行的时候,进入第一层锁到结束的位置我标注1,进入后就视为加锁了,此时第二层锁要想加锁得等第一层锁解锁后才能加锁,按道理应该第二层处于阻塞等待状态。然后接着走我们要想第一层锁解锁,就要把里面的代码执行完才能解锁吧,但是此时第二层怎么执行下去呢?第一层都没解锁第二层怎么能加锁呢?第一层要想解锁还得执行完第二层的代码,此时就出现死锁的情况(线程卡死)

                                        be352a27d57841329c8bce257c6acbef.png

加锁:让锁记录一下是哪个线程把它锁住的,后续如果再进行加锁的时候,如果加锁线程就是持有锁的线程就直接加锁成功。如果是同一线程就直接加锁成功就是说我在一个线程进行加锁后,让锁记录一下是哪个线程把它锁住的,后续再在对这个锁进行加锁的话,直接判断被加锁的线程和要加锁的线程是不是同一个线程是的话直接加锁并且计数如果不是当前线程并且被还没解锁,则阻塞当前线程

44d552078ad650b45e5c63e931a9375c.png

解锁:引入计数,锁会记录当前线程的加锁次数,直到解锁次数与加锁次数匹配时才真正释放锁,就是加锁+1,解锁-1,直至为0才能解锁。直白说要执行到最外层才能解锁

                                        2a189a6c4392438fb70d4176a557cf4d.png

注意:无论是否嵌套,加锁就加1,解锁就减1!!!


死锁(重要)

死锁:可以理解两个渣男都有自己的女朋友的情况下,互相看上对方的女朋友,但是呢这么做不好,只能等,等其中一对分手了才有机会脚踏两条船😂,专业点说就是在多线程的情况下,一个线程持有资源的情况去请求获取另外一个线程持有的资源而而产生的阻塞等待

1.一个线程连续针对一把锁,加锁两次,如果是不可重入锁就是死锁,synchronized不会出现这种情况

2.两个线程,两把锁(无论是不是可重入锁,都会死锁),就是t1线程获取锁A,t2线程获取锁B,t1线程又获取锁B,t2线程获取锁A。什么意思呢?举个例子你此时需要获取两把钥匙,钥匙A用来开门,钥匙B用来开车,此时钥匙A在你手里,可是你要开车又需要钥匙B,但是呢钥匙B被你女朋友获取了在你女朋友那,而恰恰相反她想要钥匙A打开门,而此时你在世界最北端,她在最右端

public class Test2 {public static Object lock1 = new Object();public static Object lock2 = new Object();public static void main(String[] args) throws InterruptedException {Thread t1 = new Thread(() -> {synchronized (lock1) {try {Thread.sleep(1000);} catch (InterruptedException e) {throw new RuntimeException(e);}synchronized (lock2) {System.out.println("t1加锁成功");}}});Thread t2 = new Thread(() -> {synchronized (lock2) {try {Thread.sleep(1000);} catch (InterruptedException e) {throw new RuntimeException(e);}synchronized (lock1) {System.out.println("t2加锁成功");}}});t1.start();t2.start();t1.join();t2.join();}
}

上述代码的输出结果,什么也不会输出,线程卡死了,也就是死锁的情况,因为t1线程先拿到锁lock1然后进入休眠,t2线程拿到锁lock2进入休眠,此时t1线程尝试去拿锁lock2,会发现已经被t2线程拿了,此时要想获取需要等到t2线程解锁后才能获取

                                b49b30bb0644419fa541068b4701a98a.png

解决这个问题的死锁很简单,我把这个休眠方法去掉就行了,这样就变成串行了

public class Test2 {public static Object lock1 = new Object();public static Object lock2 = new Object();public static void main(String[] args) throws InterruptedException {Thread t1 = new Thread(() -> {synchronized (lock1) {synchronized (lock2) {System.out.println("t1加锁成功");}}});Thread t2 = new Thread(() -> {synchronized (lock2) {synchronized (lock1) {System.out.println("t2加锁成功");}}});t1.start();t2.start();t1.join();t2.join();}
}

输出结果

2aa1552dcbdb44b68a4487b0f8a53bea.png

3.N个线程,M把锁,更容易出现死锁的情况(哲学家就餐问题),这个情况和上面的情况差不多

public class Test2 {public static Object lock1 = new Object();//左筷子 lock3的右筷子public static Object lock2 = new Object();//左筷子 lock3的右筷子public static Object lock3 = new Object();//左筷子 lock2的右筷子public static void main(String[] args) throws InterruptedException {Thread t1 = new Thread(() -> {synchronized (lock1) {try {Thread.sleep(3000);} catch (InterruptedException e) {throw new RuntimeException(e);}synchronized (lock2) {System.out.println("t1加锁成功");}}});Thread t2 = new Thread(() -> {synchronized (lock2) {try {Thread.sleep(2000);} catch (InterruptedException e) {throw new RuntimeException(e);}synchronized (lock3) {System.out.println("t2加锁成功");}}});Thread t3 = new Thread(() -> {synchronized (lock3) {try {Thread.sleep(1000);} catch (InterruptedException e) {throw new RuntimeException(e);}synchronized (lock1) {System.out.println("t3加锁成功");}}});t1.start();t2.start();t3.start();t1.join();t2.join();t3.join();}
}

解释一下为什么上面这段代码会产生死锁,首先t1线程获取一把锁lock1然后进入休眠,接着t2线程获取一把锁lock2然后进入休眠,接着t3线程获取一把锁lock3然后休眠,然后t1线程接着往下执行去获取锁lock2,但是锁lock2被t2线程占着所以无法加锁(无法获取锁lock2)进入阻塞状态后面t2线程和t3线程也是一样的结果,相互之间有依赖关系,最终导致产生死锁,解决办法也很简单把休眠去掉,让一个线程先执行完。

产生死锁的四种必要条件

在上面的讲解中,我们拎出了几种产生死锁的场景。总结一下产生死锁的四种必要条件

1.互斥(锁的机制):当一个线程拿到一把锁之后,另外一个线程再想拿到这把锁,要等到上个线程解锁后才能获取,在此期间这个线程进入阻塞等待

2.不可剥夺(锁的机制):跟上面的差不多意思,就是A线程拿到锁之后,B线程不能把这个锁抢过来,只能等线程A解锁

3.请求和保持(代码结构):一个线程因请求资源而阻塞,并且对已有的资源保持不放。简单点说就是一个线程想要获取多把锁,上面的例子中提到的就是这个问题。t1线程持有锁A的情况又想获取锁B,但此时锁B被线程t2线程占有,t1线程不断请求获取锁B,并且锁A也没有解锁

4.循环等待(代码结构):和上面的情况差不多,只是形成回路了,彼此之间依赖,什么意思呢?t1线程占有锁A,t2线程占有锁B,t3线程占有锁C,此t1线程又想要获取锁B,t2线程又想要获取锁C,t3线程又想要获取锁A

解决死锁

首先根据产生死锁的条件进行分析,第1条和第2条我们无法进行干涉,因为是锁的机制自带的。我们从第3条入手,这种情况我们要避免"锁嵌套的结构",从并行转为串行的结构这样就能解决死锁的问题。但是呢如果有些场景就是这样的结构呢?设置好加锁的顺序,什么意思呢?看下面这段代码

public class Test2 {public static Object lock1 = new Object();//左筷子 lock3的右筷子public static Object lock2 = new Object();//左筷子 lock3的右筷子public static Object lock3 = new Object();//左筷子 lock2的右筷子public static void main(String[] args) throws InterruptedException {Thread t1 = new Thread(() -> {synchronized (lock1) {synchronized (lock2) {System.out.println("t1加锁成功");}}});Thread t2 = new Thread(() -> {synchronized (lock2) {synchronized (lock3) {System.out.println("t2加锁成功");}}});Thread t3 = new Thread(() -> {synchronized (lock3) {synchronized (lock1) {System.out.println("t3加锁成功");}}});t1.start();t2.start();t3.start();t1.join();t2.join();t3.join();}
}

输出结果如下图,我来解释一下,我们先让t1线程拿到锁lock1并且再次拿到锁lock2,然后全拿到后输出语句,完成后解锁。接着让t2线程拿到锁lock2再拿到锁lock3,然后输出语句后解锁。t3线程也是一样。我们会发现没有产生死锁的情况,这就是设置好加锁的顺序,可以理解为先让一个线程拿到想要的所有锁,记住锁的机制(在此间别的锁要想获取这个锁等到这个线程解锁后才能获取),然后等这个线程解锁完后,再让下个线程获取。

     5f5f74787e384d39aca5789e72bb8278.png


volatile(重要)

首先先说volatile关键字的作用保证内存可见性(什么意思呢?直白点说叫编译器别优化,别瞎操心,下面对编译器优化进行了解释)和禁止指令重排序(之后会讲解)

内存可见性问题:在多线程下产生的问题,一个线程进行读,一个线程进行修改产生的内存可见性问题,这个问题需要结合当时的场景进行判断,下面进行详细介绍

首先我们要知道一个问题,我们知道计算机运行的程序/代码,经常需要访问数据,而这些需要处理和访问的数据呢都会先存在内存当中,当我们要进行处理的时候cpu会先从内存当中取数据,就例如count++的操作,count会先放到内存当中,cpu要想处理这个count的话要先从内存中取count放到cpu的寄存器中,然后进行运算。cpu在读取内存的时候,这个速度是很慢的,但是对比读取硬盘肯定是快很多的。cpu一般的操作都是很快的,唯独到了读/写内存的时候,速度就慢下来了。这个问题其实是由于cpu的高速缓存存储器导致的。为了解决上面的问题,编译器会对代码进行优化,对于读/写内存的操作,优化成读取寄存器。这样就能减少读取内存的次数,从而提高程序整体的效率

注意:这里的编译器指的是java中的编译器,java中的编译器有分为 java编译器,也就是我们之前用的javac,另一个就是即时编译器,也就是jit,这里说的编译器就是这个jit

接下来使用代码演示这个问题

public class Test5 {public static int count = 0;public static void main(String[] args) {Thread t1 = new Thread(() -> {while (count == 0) {}System.out.println("结束");});t1.start();Thread t2 = new Thread(() -> {Scanner scanner = new Scanner(System.in);System.out.print("请输入:");count = scanner.nextInt();});t2.start();}
}

输出结果

通过jconsole关键发现输入1后t1线程并没有停下来

问题详解:创建t1线程后开始执行任务,进入循环判断满不满足条件,满足则接着执行,不满足则输出结束。就判断条件这个操作在cpu上执行的时候分为两步,一步是load从内存中读取操作数放到寄存器中,一步是cmp比较操作数是不是满足条件,这个速度是很快的,一下子执行了非常多次,不断的重复这两个操作。编译器/JVM发现load这么多次都是一样的结果,于是对其进行优化在执行一次load后后续不再进行load操作,因为一次load操作可以执行很多次cmp操作。就在第一次从内存读取后(编译器是个二百五,无法确定它会什么时候进行优化以及不优化,所以不一定是第一次后,后面也会有例子进行解释),后续不在从内存读取,直接从寄存器中读取。导致内存可见性问题产生,编译器的bug

解决办法

1.解决办法给count使用volatile关键字,让编译器禁止优化问题就解决了,volatile 修饰的变量, 能够保证 "内存可见性",就是说一个线程对共享变量值的修改,能够及时地被其它线程看到

public class Test5 {public static volatile int count = 0;public static void main(String[] args) {Thread t1 = new Thread(() -> {while (count == 0) {}System.out.println("结束");});t1.start();Thread t2 = new Thread(() -> {Scanner scanner = new Scanner(System.in);System.out.print("请输入:");count = scanner.nextInt();});t2.start();}
}

输出结果,这时候输入1,t1线程输出结束然后就销毁了

2.不使用volatile关键字也可以解决这个问题

public class Test5 {public static int count = 0;public static void main(String[] args) {Thread t1 = new Thread(() -> {while (count == 0) {try {Thread.sleep(100);} catch (InterruptedException e) {throw new RuntimeException(e);}}System.out.println("结束");});t1.start();Thread t2 = new Thread(() -> {Scanner scanner = new Scanner(System.in);System.out.print("请输入:");count = scanner.nextInt();});t2.start();}
}

输出结果和上面一样,为什么呢?通过休眠让cpu执行这些操作的次数减少了开销就小了,编译器就没有做出优化了,也就不会出现内存可见性的问题

总结:由于编译器是个二百五,我们无法确定它会什么时候进行优化以及不优化,碰到这种问题建议使用volatile关键字


JMM

关于内存可见性涉及的关键性概念JMM(Java Memory Model,java内存模型),存储空间划分如下图

为什么java要搞一个JMM出来呢?实现跨平台性,要兼容不同的cpu、操作系统以及各种硬件设备等等。不同的cpu上的寄存器以及高速缓存存储器都不同有些可能还没有。所以java为了实现跨平台性,搞了JMM出来,来代指这套与硬件相关的信息


volatile 和 synchronized 的区别

1.synchronized 能够保证原子性, volatile 保证的是内存可见性,不能保证原子性

public class Test5 {public static volatile int count;public static void main(String[] args) throws InterruptedException {Thread t1 = new Thread(() -> {for (int i = 0; i < 10000; i++) {count++;}});Thread t2 = new Thread(() -> {for (int i = 0; i < 10000; i++) {count++;}});t1.start();t2.start();t1.join();t2.join();System.out.println(count);}
}

输出结果和我们预期的不符合,应该输出20000,还是会造成线程不安全的问题

2.synchronized 既能保证原子性, 也能保证内存可见性。之前演示过,同一线程对同一变量进行修改的操作

public class Test5 {public static volatile int count;public static void main(String[] args) throws InterruptedException {Object lock = new Object();Thread t1 = new Thread(() -> {for (int i = 0; i < 10000; i++) {synchronized (lock) {count++;}}});Thread t2 = new Thread(() -> {for (int i = 0; i < 10000; i++) {synchronized (lock) {count++;}}});t1.start();t2.start();t1.join();t2.join();System.out.println(count);}
}

输出结果


wait和notify方法

之前提到的join方法能控制线程结束的先后顺序,但是呢我们希望线程不结束也能控制先后顺序,注意join不是只能影响主线程,哪个线程调用join方法哪个就会受影响,就是谁调用谁受影响

我们知道多个线程的执行顺序是随机的,由于系统随机调度,抢占式执行的, 因此线程之间执行的先后顺序难以预知。但是实际开发中有时候我们希望合理的协调多个线程之间的执行先后顺序,多线程中有个重要机制,就是协调多个线程的执行顺序,使用wait和notify方法

wait方法

wait对应的中文意思是等待,所以这个方法就是让指定线程进入阻塞状态

wait 要搭配 synchronized 来使用,脱离 synchronized 使用 wait 会直接抛出异常。并且wait可以设置等待时间,一般建议设置不要死等,wait和notify都是Object类的方法,所以随便定义个对象都可以使用

public class Test5 {public static void main(String[] args) throws InterruptedException {System.out.println("开始");Object o = new Object();o.wait();System.out.println("结束");}
}

输出结果

所以我们在使用wait方法的时候要注意这三件事:

1.释放当前的锁(就是解锁了,因为我们知道加锁要确定那个对象),只有先加锁了才能解锁

2.让线程进入阻塞

3.当线程被唤醒的时候,重新获取到锁(就是可以去拿锁了)

public class Test5 {public static void main(String[] args) throws InterruptedException {System.out.println("开始");Object o = new Object();synchronized (o) {o.wait(1000);}System.out.println("结束");}
}

输出结果

notify方法

notify对应的中文意思是通知,所以这个方法就是唤醒对应的阻塞状态的线程,指定唤醒进入阻塞状态的线程

notify也需要搭配synchronized使用wait和notify都是Object类的方法,所以随便定义个对象都可以使用

public class Test5 {public static void main(String[] args) throws InterruptedException {Object o = new Object();Thread t1 = new Thread(() -> {System.out.println("t1线程开始睡了");synchronized (o) {try {o.wait();} catch (InterruptedException e) {throw new RuntimeException(e);}}System.out.println("t1线程睡醒了");});t1.start();Thread.sleep(100);synchronized (o) {o.notify();}}
}

输出结果

注意wait和notify在使用的时候需要借助同一个对象!!!


线程饿死

什么是线程饿死呢?就比如说线程A获取一把锁之后在cpu上执行,其他线程想获取这把锁只能进入阻塞等待没在cpu上执行。然后当线程A解锁后,这些线程想去cpu上执行获取这把锁,注意此时这些线程要去cpu上执行获取这把锁需要系统调度,所以需要时间。但是呢线程A已经在cpu上执行了,后续想要再获取这把锁,比其他线程更好拿到,如果线程A一直重复这样的操作,会导致其他线程饿死。下面代码进行演示

public class Test5 {public static void main(String[] args) throws InterruptedException {Object o = new Object();Thread t1 = new Thread(() -> {synchronized (o) {System.out.println("t1线程来了");}synchronized (o) {System.out.println("t1线程来了");}synchronized (o) {System.out.println("t1线程来了");}//这里省略n条});Thread t2 = new Thread(() -> {synchronized (o) {System.out.println("t2线程来了");}});Thread t3 = new Thread(() -> {synchronized (o) {System.out.println("t3线程来了");}});t1.start();t2.start();t3.start();}
}

输出结果,如果我在t1线程串行的加n个锁,就会导致其他线程没机会获取到这个锁

使用wait和notify方法可以避免线程饿死,因为wait方法会释放锁然后进入阻塞状态


notifyAll方法

notify方法是一次唤醒一个线程,notifyAll是一次唤醒全部线程,但是要注意唤醒的时候,wait会重新获取锁,所以是串行执行的

public class Test5 {public static void main(String[] args) throws InterruptedException {Object o = new Object();Thread t1 = new Thread(() -> {synchronized (o) {try {o.wait();} catch (InterruptedException e) {throw new RuntimeException(e);}System.out.println("t1线程来了");}});Thread t2 = new Thread(() -> {synchronized (o) {try {o.wait();} catch (InterruptedException e) {throw new RuntimeException(e);}System.out.println("t2线程来了");}});Thread t3 = new Thread(() -> {synchronized (o) {try {o.wait();} catch (InterruptedException e) {throw new RuntimeException(e);}System.out.println("t3线程来了");}});t1.start();t2.start();t3.start();Thread.sleep(100);System.out.println("我来叫醒你们");synchronized (o) {o.notifyAll();}}
}

输出结果,注意一下虽然是同时唤醒 3 个线程, 但是这 3 个线程需要竞争锁. 所以并不是同时执行, 而仍然是有先有后的执行


wait和sleep的区别

如果需要线程间通信和协作,则使用wait()方法,如果是让线程阻塞一段时间,则使用sleep()方法

1.wait 需要搭配 synchronized 使用,sleep 不需要

2.wait是Object类的方法,sleep是Thread类的静态方法

以上便是本章的内容多线程引发的安全问题,后续还会讲解到内容太多分着讲解,这章节的内容同样很重要,不管是日常还是面试中都会频繁出现。我们下一章再见💕

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/web/36615.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

Hive笔记-6

6.2.8 聚合函数 1) 语法 count(*)&#xff0c;表示统计所有行数&#xff0c;包含null值&#xff1b; count(某列)&#xff0c;表示该列一共有多少行&#xff0c;不包含null值&#xff1b; max()&#xff0c;求最大值&#xff0c;不包含null&#xff0c;除非所有值都是null&a…

不同node版本的切换及其指定版本vue-cli脚手架下载

目录 一.清空本地已安装node.js版本 二.装nvm管理工具 三.安装指定node版本 四.使用nvm命令切换或删除指定node版本 五.在指定node版本下下载指定vue-cli脚手架 一.清空本地已安装node.js版本 1.按健winR弹出窗口&#xff0c;键盘输入cmd&#xff0c;然后敲回车。 2.输入…

win11 + ubuntu linux双系统:开机直接进入windows修复

https://zhuanlan.zhihu.com/p/666702893 这种 双系统直接进入win 的问题&#xff0c;应该属于引导坏了&#xff0c;即grub坏了。 原因&#xff1a;笔记本送修了&#xff0c;没拆掉硬盘&#xff0c;可能引导被售后搞坏了。 在win-磁盘管理中查看分区&#xff0c;linux的分区…

《SpringBoot+Vue》Chapter04 SpringBoot整合Web开发

返回JSON数据 默认实现 依赖 <dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency>在springboot web依赖中加入了jackson-databind作为JSON处理器 创建一个实体类对象…

学编程容易遇到的误区,请提前规避

随着互联网行业的蓬勃发展和编程技术的普及&#xff0c;越来越多的人开始对编程感兴趣。然而&#xff0c;编程学习并非一蹴而就&#xff0c;新手入门时常常会陷入误区&#xff0c;影响学习状态效率。 今天&#xff0c;我们来一起揭开编程学习常见的五大误区&#xff0c;希望能…

【融合ChatGPT等AI模型】Python-GEE遥感云大数据分析、管理与可视化及多领域案例应用

随着航空、航天、近地空间遥感平台的持续发展&#xff0c;遥感技术近年来取得显著进步。遥感数据的空间、时间、光谱分辨率及数据量均大幅提升&#xff0c;呈现出大数据特征。这为相关研究带来了新机遇&#xff0c;但同时也带来巨大挑战。传统的工作站和服务器已无法满足大区域…

如何激活typora

话不多说&#xff0c;直接上流程。 1、先下载最新的typora安装包&#xff0c;并安装成功。 Typora的安装 &#xff08;1&#xff09;官网下载&#xff1a;https://typora.xnxxxk.cn/index.html?qhclickid777dd93d58082a46 2、下载百度云我上传的两个exe&#xff0c;不大&…

嵌入式实验---实验五 串口数据接收实验

一、实验目的 1、掌握STM32F103串口数据接收程序设计流程&#xff1b; 2、熟悉STM32固件库的基本使用。 二、实验原理 1、STM32F103R6能通过查询中断方式接收数据&#xff0c;每接收到一个字节&#xff0c;立即向对方发送一个相同内容的字节&#xff0c;并把该字节的十六进…

Dahlia Hart: Stylized Casual Character(休闲角色模型)

此包包含两个发型和两个服装&#xff0c;每个都有多种颜色选择。每个发型都适合与物理资源一起使用&#xff0c;并包含各种表情和音素混合形状。 下载&#xff1a;​​Unity资源商店链接资源下载链接 效果图&#xff1a;

【机器学习】大模型训练的深入探讨——Fine-tuning技术阐述与Dify平台介绍

目录 引言 Fine-tuning技术的原理阐 预训练模型 迁移学习 模型初始化 模型微调 超参数调整 任务设计 数学模型公式 Dify平台介绍 Dify部署 创建AI 接入大模型api 选择知识库 个人主页链接&#xff1a;东洛的克莱斯韦克-CSDN博客 引言 Fine-tuning技术允许用户根…

数据分析-常用模型-RFM模型

一、RFM模型的底层逻辑 漏斗模型中&#xff0c;大部分业务都是按流程推进&#xff0c;可以做漏斗分析。但是&#xff0c;大家有没有想过一个问题&#xff1a; 如果没有转化过程记录&#xff0c;该怎么办&#xff1f;如果用户行为频率很高&#xff0c;有几十个漏斗&#xff0c…

[数据库]索引机制

目录 索引机制 索引的类型 索引使用 哪些适合添加索引 ​编辑 索引机制 当没有索引的时候, 如下示例,在找到id等于1的时候, 仍然会往下继续查找, 进行全表扫描, 因为它认为下面也有可能还会有1 加上索引之后进行二叉树查找, 找到1之后, 发现1的左边没有了, 右边也没有了就停…

【项目实战】Android Studio简单实现图书馆借阅管理系统

希望文章能给到你启发和灵感&#xff5e; 点赞收藏关注 支持一下吧&#xff5e; 阅读指南 序幕一、基础环境说明1.1 硬件环境1.2 软件环境 二、整体设计2.1 数据库逻辑处理&#xff1a;2.2 登录/注册模块2.3 功能界面初始化&#xff1a;2.4 图书管理模块2.5 图书租借服务2.6 读…

钡铼BL104智慧环保多个485采集转MQTT无线传输

PLC物联网关BL104是一款专为工业环境设计的先进协议转换网关&#xff0c;其集成了钡铼智能技术和环保多个485采集转MQTT无线传输功能&#xff0c;为工业控制系统提供了高效的数据采集、传输和管理解决方案。 技术规格与功能特点 PLC物联网关BL104采用钡铼智能技术&#xff0c…

一招教你用python代码给朋友写一个爱心代码

有人问我马上要跟女朋友一周年了&#xff0c;能不能用代码给他写一个爱心代码呢&#xff1f;那算你问对人了&#xff0c;来上才艺 可以使用Python的turtle模块来绘制一个爱心形状。下面是一个简单的示例代码&#xff0c;我将详细解释每一步&#xff1a; import turtle # 创建一…

回溯法基本思想-01背包、N皇后回溯法图解

基本思想&#xff1a; ​ 回溯法是一种系统地搜索问题解空间的算法&#xff0c;常用于解决组合优化和约束满足问题。其核心思想是利用深度优先搜索逐步构建可能的解&#xff0c;同时在搜索过程中进行剪枝操作&#xff0c;以排除那些无法满足问题约束或不能产生最优解的分支&am…

js修改scss变量

style.scss $color : var(--color,#ccc); // 默认值 #ccc .color{background: $color; } 定义了一个scss变量&#xff08;$color&#xff09;&#xff0c;用普通的css变量&#xff08;--color&#xff09;给他赋值&#xff0c;这里需要一个默认值&#xff0c;此时css变量(--co…

数据结构复习指南

数据结构复习指南 本文中列举了数据结构期末考试可能存在的考点 绪论 数据的基本单位 数据元素是数据的基本单位 数据项 数据项是组成数据的、有独立含义的、不可分割的最小单位。 数据对象 数据对象是性质相同的数据元素的集合&#xff0c;是数据的一个子集。 数据结…

如何借助ai(文心一言)获取tushare的数据

1. 准备工作 确保已安装python &#xff0c;安装Tushare库 和文心一言的地址&#xff08;文心一言&#xff09;&#xff1a; 注册Tushare账号并获取Token&#xff1a;在Tushare官方网站注册账号&#xff0c;并获取个人Token。如下 tushare地址&#xff1a;&#xff08;点击即…

【高级篇】InnoDB引擎深入:核心机制与实战优化(十五)

引言 在探索了MySQL集群与分布式技术之后,我们进入了数据库引擎的核心地带——InnoDB。作为MySQL的默认存储引擎,InnoDB凭借其对事务的支持、行级锁定、高效的恢复机制以及复杂的内存管理,成为众多应用场景的首选。本章,我们将深入InnoDB的内部机制,透彻理解锁管理、事务…