线程活跃性

最新推荐文章于 2022-09-11 22:47:26 发布

Q z1997

最新推荐文章于 2022-09-11 22:47:26 发布

阅读量294

点赞数

分类专栏： JUC 文章标签： java 开发语言

本文链接：https://blog.csdn.net/weixin_43939924/article/details/124599146

版权

JUC 专栏收录该内容

59 篇文章 0 订阅

订阅专栏

本文深入探讨了Java并发编程中的死锁、活锁和饥饿问题。通过示例代码展示了死锁的场景，并提供了使用jconsole和jstack工具进行死锁检测的方法。此外，还讨论了活锁的情况以及如何通过顺序加锁避免死锁，但这种方式可能导致线程饥饿。文章最后提到了线程饥饿的实例，并指出了解决死锁问题的顺序加锁策略可能引入的新问题。

摘要由CSDN通过智能技术生成

死锁

有这样的情况：一个线程需要同时获取多把锁，这时就容易发生死锁
t1 线程获得 A对象锁，接下来想获取 B对象的锁 t2 线程获得 B对象锁，接下来想获取 A对象的锁例：

package com.example.demo.hmjuc.day10;

import com.example.demo.hmjuc.Sleep;

/**
 * 死锁演示
 *
 * @author zhangqi
 * @date 2022/5/5 20:15
 */
public class Test1 {

    public static void main(String[] args) {
        // 死锁演示
        Object o1 = new Object();
        Object o2 = new Object();


        new Thread(() -> {
            synchronized (o1) {
                System.out.println("t1 o1");
                try {
                    Sleep.sleep(1000);
                } catch (Exception e) {
                    e.printStackTrace();
                }
                synchronized (o2) {
                    System.out.println("t1 o2");
                }
            }

        }).start();
        new Thread(() -> {
            synchronized (o2) {
                System.out.println("t2 o2");
                try {
                    Sleep.sleep(500);
                } catch (Exception e) {
                    e.printStackTrace();
                }
                synchronized (o1) {
                    System.out.println("t2 o1");
                }
            }

        }).start();

    }
}

定位死锁

检测死锁可以使用 jconsole工具，或者使用 jps 定位进程 id，再用 jstack 定位死锁：

cmd > jps
Picked up JAVA_TOOL_OPTIONS: -Dfile.encoding=UTF-8
12320 Jps
22816 KotlinCompileDaemon
33200 Test1// JVM 进程
11508 Main
28468 Launcher

jstack pid

cmd > jstack 33200
2022-05-05 22:26:05
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.131-b11 mixed mode):

"DestroyJavaVM" #14 prio=5 os_prio=0 tid=0x0000000002ee7000 nid=0x3a1c waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Thread-1" #13 prio=5 os_prio=0 tid=0x000000001ff37000 nid=0x3948 waiting for monitor entry [0x0000000020afe000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.example.demo.hmjuc.day10.Test1.lambda$main$1(Test1.java:42)
        - waiting to lock <0x000000076b969150> (a java.lang.Object)
        - locked <0x000000076b969160> (a java.lang.Object)
        at com.example.demo.hmjuc.day10.Test1$$Lambda$2/2117255219.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)

"Thread-0" #12 prio=5 os_prio=0 tid=0x000000001ff36000 nid=0x45d0 waiting for monitor entry [0x00000000209ff000]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at com.example.demo.hmjuc.day10.Test1.lambda$main$0(Test1.java:28)
        - waiting to lock <0x000000076b969160> (a java.lang.Object)
        - locked <0x000000076b969150> (a java.lang.Object)
        at com.example.demo.hmjuc.day10.Test1$$Lambda$1/1637506559.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)

"Service Thread" #11 daemon prio=9 os_prio=0 tid=0x000000001fc19000 nid=0x331c runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

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

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

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

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

"Monitor Ctrl-Break" #6 daemon prio=5 os_prio=0 tid=0x000000001fb71000 nid=0x417c runnable [0x00000000202fe000]
   java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
        at java.net.SocketInputStream.read(SocketInputStream.java:171)
        at java.net.SocketInputStream.read(SocketInputStream.java:141)
        at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
        at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
        at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
        - locked <0x000000076ba0f368> (a java.io.InputStreamReader)
        at java.io.InputStreamReader.read(InputStreamReader.java:184)
        at java.io.BufferedReader.fill(BufferedReader.java:161)
        at java.io.BufferedReader.readLine(BufferedReader.java:324)
        - locked <0x000000076ba0f368> (a java.io.InputStreamReader)
        at java.io.BufferedReader.readLine(BufferedReader.java:389)
        at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:49)

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

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

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x000000001e443800 nid=0x4f44 in Object.wait() [0x000000001f79f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x000000076b608ec8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
        - locked <0x000000076b608ec8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x000000001cd7e800 nid=0x3be8 in Object.wait() [0x000000001f69f000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x000000076b606b68> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:502)
        at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
        - locked <0x000000076b606b68> (a java.lang.ref.Reference$Lock)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)

"VM Thread" os_prio=2 tid=0x000000001e422800 nid=0x4f64 runnable

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x0000000002efc800 nid=0xd38 runnable

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x0000000002efe000 nid=0x4834 runnable

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x0000000002eff800 nid=0x3244 runnable

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x0000000002f02000 nid=0x3274 runnable

"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x0000000002f04800 nid=0xa10 runnable

"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x0000000002f05800 nid=0x3384 runnable

"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x0000000002f08800 nid=0x5380 runnable

"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x0000000002f0a000 nid=0x39b0 runnable

"GC task thread#8 (ParallelGC)" os_prio=0 tid=0x0000000002f0b000 nid=0x1154 runnable

"GC task thread#9 (ParallelGC)" os_prio=0 tid=0x0000000002f0c000 nid=0x514c runnable

"VM Periodic Task Thread" os_prio=2 tid=0x000000001fb72000 nid=0x3954 waiting on condition

JNI global references: 318


Found one Java-level deadlock:
=============================
"Thread-1":
  waiting to lock monitor 0x000000001cd82b78 (object 0x000000076b969150, a java.lang.Object),
  which is held by "Thread-0"
"Thread-0":
  waiting to lock monitor 0x000000001cd85358 (object 0x000000076b969160, a java.lang.Object),
  which is held by "Thread-1"

Java stack information for the threads listed above:
===================================================
"Thread-1":
        at com.example.demo.hmjuc.day10.Test1.lambda$main$1(Test1.java:42)
        - waiting to lock <0x000000076b969150> (a java.lang.Object)
        - locked <0x000000076b969160> (a java.lang.Object)
        at com.example.demo.hmjuc.day10.Test1$$Lambda$2/2117255219.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)
"Thread-0":
        at com.example.demo.hmjuc.day10.Test1.lambda$main$0(Test1.java:28)
        - waiting to lock <0x000000076b969160> (a java.lang.Object)
        - locked <0x000000076b969150> (a java.lang.Object)
        at com.example.demo.hmjuc.day10.Test1$$Lambda$1/1637506559.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:748)

Found 1 deadlock.

避免死锁要注意加锁顺序
另外如果由于某个线程进入了死循环，导致其它线程一直等待，对于这种情况 linux 下可以通过 top 先定位到
CPU 占用高的 Java 进程，再利用 top -Hp 进程id 来定位是哪个线程，最后再用 jstack 排查

活锁

活锁出现在两个线程互相改变对方的结束条件，最后谁也无法结束，例如

package com.example.demo.hmjuc.day10;

import com.example.demo.hmjuc.Sleep;

/**
 * 活锁
 *
 * @author zhangqi
 * @date 2022/5/5 20:45
 */
public class Test3 {
    static volatile int a = 10;
    static final Object o = new Object();

    public static void main(String[] args) {
        new Thread(() -> {
            while (a > 0) {
                Sleep.sleep(200);
                a--;
                System.out.println("t1 a = " + a);
            }
        }, "t1").start();
        new Thread(() -> {
            while (a < 20) {
                Sleep.sleep(200);
                a++;
                System.out.println("t2 a = " + a);
            }
        }, "t2").start();
    }
}

饥饿

很多教程中把饥饿定义为，一个线程由于优先级太低，始终得不到 CPU 调度执行，也不能够结束，饥饿的情况不
易演示，讲读写锁时会涉及饥饿问题
下面我讲一下我遇到的一个线程饥饿的例子，先来看看使用顺序加锁的方式解决之前的死锁问题
在这里插入图片描述
顺序加锁的解决方案
但是这样就会出现线程饥饿问题

Q z1997

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
线程活跃性

死锁有这样的情况：一个线程需要同时获取多把锁，这时就容易发生死锁t1 线程获得 A对象锁，接下来想获取 B对象的锁 t2 线程获得 B对象锁，接下来想获取 A对象的锁例：package com.example.demo.hmjuc.day10;import com.example.demo.hmjuc.Sleep;/** * 死锁演示 * * @author zhangqi * @date 2022/5/5 20:15 */public class Test1 {
复制链接

扫一扫

专栏目录