两个线程形成死锁，是并发型的呢，还是并行型的呢

bitDesigner

已于 2022-02-20 12:09:44 修改

阅读量442

点赞数

分类专栏：线程及并发文章标签：线程死锁进程线程 jps jstack

于 2021-12-27 16:28:39 首次发布

本文链接：https://blog.csdn.net/qq_44922239/article/details/122174950

版权

线程及并发专栏收录该内容

6 篇文章 0 订阅

订阅专栏

线程是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;
	}
	@Override
	public 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: RUNNABLE

   Locked 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: RUNNABLE

   Locked ownable synchronizers:
        - None

"C1 CompilerThread3" #9 daemon prio=9 os_prio=2 tid=0x0000016dd47c4800 nid=0x2900 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"C2 CompilerThread2" #8 daemon prio=9 os_prio=2 tid=0x0000016dd47ba800 nid=0x528 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"C2 CompilerThread1" #7 daemon prio=9 os_prio=2 tid=0x0000016dd47b6000 nid=0x1368 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"C2 CompilerThread0" #6 daemon prio=9 os_prio=2 tid=0x0000016dd47ae800 nid=0x4304 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x0000016dd47ac000 nid=0x4f34 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
        - None

"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x0000016dd47ab000 nid=0x3858 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked 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 condition

JNI global references: 5


Found 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