两个线程形成死锁,是并发型的呢,还是并行型的呢
线程是CPU调度的基本单位,假如某个线程一直运行,那CPU的某个核心就被这个线程所独占。但某个线程如果是阻塞了,那就不要一直占据CPU。
死锁形成的必要条件是线程之间有共享资源竞争,如果只是一个线程一直占据CPU的某个核心,那极有可能是死循环,而不是死锁。
而死锁,到底是什么类型的死锁呢?以下为一些猜想
1.假设造成死锁的两个线程在阻塞后就不占用CPU的核心,那就只是占用点内存空间。
2.假设是并发型的死锁:两个线程由CPU的一个核心切换时间片调度,如果是这样,CPU的核心实际上只有一个得不到利用,比下面这种假设要好很多。
3.又假设是并行型的死锁:两个线程各自占用CPU的一个核心,但因为需要获得对方持有的锁,因而两个线程都一直占用着CPU的核心,所以CPU的两个核心都不能运行其它的线程,这种可比上面那些假设更浪费资源。因为计算机最宝贵的就是CPU。
但无论是上述哪一种假设,我们的任务都得不到CPU的完整执行。
死锁示例如下。但不知究竟是哪种类型的死锁?请你也能有所思考。
public class DeadLockDemo {public static void main(String[] args) {DeadTask task1 = new DeadTask(true);DeadTask task2 = new DeadTask(false);
// 启动两个线程开始竞相互等待对方已获得的锁,形成死锁局面new Thread(task1, "t1").start();new Thread(task2, "t2").start();}
}
class DeadTask implements Runnable{// static 修饰保证创建多个实例时成员唯一性,也就是保证锁的唯一性static Object lock1=new Object();static Object lock2=new Object();
// 用于控制线程选择执行的代码块private boolean ifElse;public DeadTask(boolean ifElse) {this.ifElse=ifElse;}@Overridepublic void run() {if (ifElse) {synchronized (lock1) {System.out.println(Thread.currentThread().getName()+" has got lock1!");try {Thread.sleep(2000);//假如此线程已经获得lock1,睡眠2s,保证另外一个线程能够被操作系统的任务处理器调度,从而获得lock2(sleep方法不会释放已获得的锁)} catch (InterruptedException e) {e.printStackTrace();}System.out.println(Thread.currentThread().getName()+" is waiting to get lock2 ...");synchronized (lock2) {System.out.println(Thread.currentThread().getName()+" has got lock2!");//dead part,never executed!}}}else {synchronized (lock2) {System.out.println(Thread.currentThread().getName()+" has got lock2!");try {Thread.sleep(2000);//假如此线程已经获得lock2,睡眠2s,保证另外一个线程能够获得lock1} catch (InterruptedException e) {e.printStackTrace();}System.out.println(Thread.currentThread().getName()+" is waiting to get lock1 ...");synchronized (lock1) {System.out.println(Thread.currentThread().getName()+" has got lock1!");//dead part}}}}}
控制台打印信息
t2 has got lock2!
t1 has got lock1!
t1 is waiting to get lock2 ...
t2 is waiting to get lock1 ...
可以看到这两个线程执行同一个任务时,执行到需要获取对方已经获得的锁时,就会一直阻塞在此处。所以后面的部分就得不到执行,不能打印以下内容:
t1 has got lock2!
t2 has got lock1!
最后,给出系统进程和线程信息
jps查看java进程,jstack查看某个进程的线程
C:\Users\root>jps
12260 Jps
11480 DeadLockDemo /*t1和t2所在的进程*/C:\Users\root>jstack -l 11480
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.261-b12 mixed mode):"DestroyJavaVM" #13 prio=5 os_prio=0 tid=0x0000016dbda12000 nid=0x4868 waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"t2" #12 prio=5 os_prio=0 tid=0x0000016dd5aa5800 nid=0x417c waiting for monitor entry [0x0000005674aff000]java.lang.Thread.State: BLOCKED (on object monitor)at threadpart.DeadTask.run(DeadLockDemo.java:46)- waiting to lock <0x00000000d63b27c0> (a java.lang.Object)- locked <0x00000000d63b27d0> (a java.lang.Object)at java.lang.Thread.run(Unknown Source)Locked ownable synchronizers:- None"t1" #11 prio=5 os_prio=0 tid=0x0000016dd5aa3000 nid=0x42e0 waiting for monitor entry [0x00000056749fe000]java.lang.Thread.State: BLOCKED (on object monitor)at threadpart.DeadTask.run(DeadLockDemo.java:33)- waiting to lock <0x00000000d63b27d0> (a java.lang.Object)- locked <0x00000000d63b27c0> (a java.lang.Object)at java.lang.Thread.run(Unknown Source)Locked ownable synchronizers:- None"Service Thread" #10 daemon prio=9 os_prio=0 tid=0x0000016dd5a73800 nid=0x3610 runnable [0x0000000000000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"C1 CompilerThread3" #9 daemon prio=9 os_prio=2 tid=0x0000016dd47c4800 nid=0x2900 waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"C2 CompilerThread2" #8 daemon prio=9 os_prio=2 tid=0x0000016dd47ba800 nid=0x528 waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"C2 CompilerThread1" #7 daemon prio=9 os_prio=2 tid=0x0000016dd47b6000 nid=0x1368 waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"C2 CompilerThread0" #6 daemon prio=9 os_prio=2 tid=0x0000016dd47ae800 nid=0x4304 waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x0000016dd47ac000 nid=0x4f34 waiting on condition [0x0000000000000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x0000016dd47ab000 nid=0x3858 runnable [0x0000000000000000]java.lang.Thread.State: RUNNABLELocked ownable synchronizers:- None"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x0000016dd4738000 nid=0x44e4 in Object.wait() [0x00000056740ff000]java.lang.Thread.State: WAITING (on object monitor)at java.lang.Object.wait(Native Method)- waiting on <0x00000000d6308ee0> (a java.lang.ref.ReferenceQueue$Lock)at java.lang.ref.ReferenceQueue.remove(Unknown Source)- locked <0x00000000d6308ee0> (a java.lang.ref.ReferenceQueue$Lock)at java.lang.ref.ReferenceQueue.remove(Unknown Source)at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)Locked ownable synchronizers:- None"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x0000016dd4709800 nid=0x42e4 in Object.wait() [0x0000005673fff000]java.lang.Thread.State: WAITING (on object monitor)at java.lang.Object.wait(Native Method)- waiting on <0x00000000d6306c00> (a java.lang.ref.Reference$Lock)at java.lang.Object.wait(Unknown Source)at java.lang.ref.Reference.tryHandlePending(Unknown Source)- locked <0x00000000d6306c00> (a java.lang.ref.Reference$Lock)at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)Locked ownable synchronizers:- None"VM Thread" os_prio=2 tid=0x0000016dd4703800 nid=0x4a00 runnable"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x0000016dbda2a800 nid=0xaf4 runnable"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x0000016dbda2b800 nid=0xb40 runnable"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x0000016dbda2d000 nid=0x4ff8 runnable"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x0000016dbda2f000 nid=0x315c runnable"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x0000016dbda30000 nid=0x2410 runnable"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x0000016dbda33000 nid=0x257c runnable"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x0000016dbda34000 nid=0x4170 runnable"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x0000016dbda35000 nid=0x124c runnable"VM Periodic Task Thread" os_prio=2 tid=0x0000016dd5a8f000 nid=0x439c waiting on conditionJNI global references: 5Found one Java-level deadlock:
=============================
"t2":waiting to lock monitor 0x0000016dd4714e98 (object 0x00000000d63b27c0, a java.lang.Object),which is held by "t1"
"t1":waiting to lock monitor 0x0000016dd4717888 (object 0x00000000d63b27d0, a java.lang.Object),which is held by "t2"Java stack information for the threads listed above:
===================================================
"t2":at threadpart.DeadTask.run(DeadLockDemo.java:46)- waiting to lock <0x00000000d63b27c0> (a java.lang.Object)- locked <0x00000000d63b27d0> (a java.lang.Object)at java.lang.Thread.run(Unknown Source)
"t1":at threadpart.DeadTask.run(DeadLockDemo.java:33)- waiting to lock <0x00000000d63b27d0> (a java.lang.Object)- locked <0x00000000d63b27c0> (a java.lang.Object)at java.lang.Thread.run(Unknown Source)Found 1 deadlock.
t1和t2线程相互等待锁的信息,可以看到t2想要获取的被t1持有,t1想要获取的被t2持有
"t2":waiting to lock monitor 0x0000016dd4714e98 (object 0x00000000d63b27c0, a java.lang.Object),which is held by "t1"
"t1":waiting to lock monitor 0x0000016dd4717888 (object 0x00000000d63b27d0, a java.lang.Object),which is held by "t2"
以上是Windows上的运行信息。
------------------------------------------------------------------------------------------------
为了印证我的猜想,我想用虚拟机模拟出单核单线程的环境。并把这个死锁程序编译后打包,放到虚拟机上运行。如果虚拟机确实能够模拟出单线程的CPU。那假设
1.虚拟机能够运行这个死锁程序,那就能够说明死锁程序中的线程不是并行型的,而是并发型的。
2.假设虚拟机能够运行这个死锁程序,也造成了死锁。而且这两个线程为终止之前,虚拟机还能够运行其它进程的线程,说明死锁进程中的线程不但是并发型的,而且形成死锁后不占用CPU核心,只是在内存中保存线程的状态。
我想CPU的设计者应该也是把死锁的运行情况设计为后面一种,不然一直占据CPU的核心,那岂不巨浪费计算机最宝贵的资源。’因为如果是前面的那些假设,那要不了几个死锁,CPU都完全被这些死锁占据了,电脑就完全工作不了了,是吧。CPU设计人员应该早就考虑到这些问题了。
看来,死锁最大的问题就是浪费内存,而且不能够完成想要执行的任务。
------------------------------------------------------------------------------------------------
以下是Linux上的运行信息。是一些额外信息,大家不妨参考一下
1.获取虚拟机CPU信息 cat /proc/cpuinfo
可知虚拟机CPU是单核的,但不知CPU的这个核心是几个线程的。因而不能够印证我的猜想
[redhat@redhat ~]$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 142
model name : Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz
stepping : 10
microcode : 0xb4
cpu MHz : 1799.313
cache size : 6144 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 22
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase tsc_adjust bmi1 avx2 smep bmi2 invpcid rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 arat
bogomips : 3600.00
clflush size : 64
cache_alignment : 64
address sizes : 45 bits physical, 48 bits virtual
power management:
2.在虚拟机上运行DeadLock.jar
java -jar DeadLock.jar
[redhat@redhat ~]$ java -jar DeadLock.jar
t1 has got lock1!
t2 has got lock2!
t1 is waiting to get lock2 ...
t2 is waiting to get lock1 ...
3.查看DeadLock进程信息
1).ps -ef |grep java
2).top -p 3409 -H
可以看到DeadLock进程中的线程信息:
Threads: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie
那为何总共只有一个线程呢??
我对Linux不是很熟,大家有精力自己分析吧
[redhat@redhat ~]$ ps -ef|grep java
redhat 3502 3409 0 11:11 pts/0 00:00:00 java -jar DeadLock.jar
redhat 4007 3832 0 11:23 pts/1 00:00:00 grep --color=auto java
[redhat@redhat ~]$ top -p 3409 -H
top - 11:23:54 up 42 min, 3 users, load average: 0.01, 0.04, 0.06
Threads: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.3 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 2031888 total, 604544 free, 783332 used, 644012 buff/cache
KiB Swap: 2097148 total, 2097148 free, 0 used. 1033392 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3409 redhat 20 0 116420 3112 1824 S 0.0 0.2 0:00.04 bash
两个线程形成死锁,是并发型的呢,还是并行型的呢相关推荐
- java线程饥饿死锁_java并发-线程饥饿死锁测试
线程饥饿死锁 <Java并发编程实践>中对线程饥饿死锁的解释是这样的:在使用线程池执行任务时,如果任务依赖于其他任务,那么就可能产生死锁问题.在单线程的Executor中,若果一个任务将另 ...
- Android多线程死锁定位,Java---多线程之死锁
死锁的两种情况: 简单的说下单块cpu运行多线程的情况: 大家可能平时玩电脑,可以同时挂QQ啊,玩游戏啊,打开文本啊,等等.这里,我们假设是单块cpu.也就是俗称的单核cpu. 大家可能会觉得这些软件 ...
- 详解java中Thread类,线程和进程的基本区别,多线程的好处,线程的五个生命周期,主线程和IDEA创建的Monitor Ctrl-Break守护线程;优雅地终止线程。死锁的产生
线程:CPU调度的最小单位:线程共享堆内存和方法区,但各自享有栈空间.进程:CPU分配资源的最小单位. 为什么需要多线程:①避免其中一个模块阻塞造成系统假死:②程序异步处理(交替执行),提高程序执行效 ...
- python主线程有两个子线程、创建两个主函数_Python多任务之线程
1.1. 线程 threading.Thread(target = 函数名) 线程的运行是没有先后顺序的 主线程死了,子线程必死.子线程结束后,子线程会给子线程收尸. 当调用Thread的时候,不会创 ...
- Java线程的死锁和活锁
文章目录 1.概览 2.死锁 2.1.什么是死锁 2.2 死锁举例 2.3 避免死锁 3.活锁 3.1 什么是活锁 3.2 活锁举例 3.3 避免活锁 1.概览 当多线程帮助我们提高应用性能的同时,它 ...
- cs439辅导 进程和线程以及死锁
文章目录 Q1 i ii Q2 i ii Q5 (a) Our most basic synchronization primitive is a lock. When would we use a ...
- 【操作系统学习笔记】—— 【二】进程、线程、死锁
本文参考: JavaGuide 王道考研-操作系统 CS-Notes 文章目录 一.进程的概念.组成.特征 1. 概念 2. 进程的组成 PCB 程序段 数据段 3. 进程的特征 二.进程的状态 三. ...
- 线程的死锁、活锁和饥饿现象
目录 1.死锁 2.活锁 3.饥饿 一个资源应该单独使用一把锁. 比如,一个对象中有多个共享资源,但有多个线程需要使用其中的不同资源 此时如果把对象整体作为一把锁,那并发就很低. 可以考虑,把每个共享 ...
- 黄金2:行稳致远-如何让你的线程免于死锁
欢迎来到<并发王者课>,本文是该系列文章中的第12篇. 在上篇文章中,我们介绍了死锁的概念及其原因,本文将为你介绍的是几种常见的死锁预防策略. 简单来说,预防死锁主要有三种策略: 顺序化加 ...
最新文章
- cms基于nodejs_我如何使基于CMS的网站脱机工作
- 开源中国源码学习笔记
- gevent queue应用1
- http error code
- PCB 机器学习(ML.NET)初体验实现PCB加投率预测
- 思考一下http.ListenAndServe + echo+gorm+xorm的可行性?
- 使用青云主机的GPU主机教程(不完整版)
- 讨伐 Google!为什么建智能城市要毫无隐私?| 极客头条
- myeclipse堆栈溢出
- linux切换英文界面,linux英文界面下使用中文输入法
- 查看xenapp 6.5 LIC版本
- OpenCV自带的CamShift算法解读
- 朴素贝叶斯+拉普拉斯平滑代码实现
- Aborting commit due to empty commit message.
- mir2的db数据库
- C++ 实现贪吃蛇游戏(免费附源码)
- 韩顺平mysql_韩顺平老师 Mysql优化 笔记
- STM32+ENC28J60+UIP协议栈实现WEB服务器示例
- 一、Hbase介绍、数据模型、体系结构
- 如何恢复回收站中被删除的文件?高效的恢复技巧