JVM-多线程-死锁

已于 2024-06-01 23:19:12 修改
阅读量321 收藏 10
点赞数 5
分类专栏： java基础 文章标签： jvm java 开发语言
于 2024-06-01 23:13:01 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_26594041/article/details/139381073
版权

jstack

        jstack 是一个Java命令行工具，用于打印Java应用程序的线程堆栈跟踪。它可以帮助开发者分析应用程序的线程状态，查找死锁或其他线程相关问题。

打印线程堆栈信息：jstack <PID>

2024-06-01 23:05:42
Full thread dump OpenJDK 64-Bit Server VM (17.0.2+8-86 mixed mode, sharing):

Threads class SMR info:
_java_thread_list=0x00000152f45f4780, length=15, elements={
0x00000152d9398f60, 0x00000152f37c0e10, 0x00000152f37c1c80, 0x00000152f37d9e00,
0x00000152f37db9c0, 0x00000152f37de480, 0x00000152f37dee30, 0x00000152f37dfbc0,
0x00000152f37e1990, 0x00000152f37e9cc0, 0x00000152f446e530, 0x00000152f4555430,
0x00000152f456bb90, 0x00000152f456e8a0, 0x00000152f37ab7b0
}

"main" #1 prio=5 os_prio=0 cpu=0.00ms elapsed=36.08s tid=0x00000152d9398f60 nid=0x8208 at breakpoint [0x00000027398ff000]
   java.lang.Thread.State: RUNNABLE
        at com.du.gc.YGCExample.main(YGCExample.java:22)

"Reference Handler" #2 daemon prio=10 os_prio=2 cpu=0.00ms elapsed=36.06s tid=0x00000152f37c0e10 nid=0x7a80 waiting on condition  [0x0000002739fff000]
   java.lang.Thread.State: RUNNABLE
        at java.lang.ref.Reference.waitForReferencePendingList(java.base@17.0.2/Native Method)
        at java.lang.ref.Reference.processPendingReferences(java.base@17.0.2/Reference.java:253)
        at java.lang.ref.Reference$ReferenceHandler.run(java.base@17.0.2/Reference.java:215)

"Finalizer" #3 daemon prio=8 os_prio=1 cpu=0.00ms elapsed=36.06s tid=0x00000152f37c1c80 nid=0x7f48 in Object.wait()  [0x000000273a0ff000]       
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(java.base@17.0.2/Native Method)
        - waiting on <0x00000000fff0d5c8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(java.base@17.0.2/ReferenceQueue.java:155)
        - locked <0x00000000fff0d5c8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(java.base@17.0.2/ReferenceQueue.java:176)
        at java.lang.ref.Finalizer$FinalizerThread.run(java.base@17.0.2/Finalizer.java:172)

"Signal Dispatcher" #4 daemon prio=9 os_prio=2 cpu=0.00ms elapsed=36.05s tid=0x00000152f37d9e00 nid=0xaa60 waiting on condition  [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Attach Listener" #5 daemon prio=5 os_prio=2 cpu=0.00ms elapsed=36.05s tid=0x00000152f37db9c0 nid=0xa6e4 waiting on condition  [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Service Thread" #6 daemon prio=9 os_prio=0 cpu=0.00ms elapsed=36.05s tid=0x00000152f37de480 nid=0xb090 runnable  [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Monitor Deflation Thread" #7 daemon prio=9 os_prio=0 cpu=0.00ms elapsed=36.05s tid=0x00000152f37dee30 nid=0x8108 runnable  [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #8 daemon prio=9 os_prio=2 cpu=0.00ms elapsed=36.05s tid=0x00000152f37dfbc0 nid=0x6dc4 waiting on condition  [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   No compile task

"C1 CompilerThread0" #16 daemon prio=9 os_prio=2 cpu=0.00ms elapsed=36.05s tid=0x00000152f37e1990 nid=0x3e84 waiting on condition  [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
   No compile task

"Sweeper thread" #20 daemon prio=9 os_prio=2 cpu=0.00ms elapsed=36.05s tid=0x00000152f37e9cc0 nid=0xa21c runnable  [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"Common-Cleaner" #21 daemon prio=8 os_prio=1 cpu=0.00ms elapsed=36.01s tid=0x00000152f446e530 nid=0x52d0 in Object.wait()  [0x000000273a8fe000] 
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
        at java.lang.Object.wait(java.base@17.0.2/Native Method)
        - waiting on <0x00000000ffe39bc8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(java.base@17.0.2/ReferenceQueue.java:155)
        - locked <0x00000000ffe39bc8> (a java.lang.ref.ReferenceQueue$Lock)
        at jdk.internal.ref.CleanerImpl.run(java.base@17.0.2/CleanerImpl.java:140)
        at java.lang.Thread.run(java.base@17.0.2/Thread.java:833)
        at jdk.internal.misc.InnocuousThread.run(java.base@17.0.2/InnocuousThread.java:162)

"JDWP Transport Listener: dt_socket" #22 daemon prio=10 os_prio=0 cpu=0.00ms elapsed=35.99s tid=0x00000152f4555430 nid=0x72b4 runnable  [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"JDWP Event Helper Thread" #23 daemon prio=10 os_prio=0 cpu=0.00ms elapsed=35.99s tid=0x00000152f456bb90 nid=0x9f68 runnable  [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

"JDWP Command Reader" #24 daemon prio=10 os_prio=0 cpu=0.00ms elapsed=35.99s tid=0x00000152f456e8a0 nid=0x3dd4 runnable  [0x0000000000000000]   
   java.lang.Thread.State: RUNNABLE

"Notification Thread" #25 daemon prio=9 os_prio=0 cpu=0.00ms elapsed=35.69s tid=0x00000152f37ab7b0 nid=0x49e0 runnable  [0x0000000000000000]    
   java.lang.Thread.State: RUNNABLE

"VM Thread" os_prio=2 cpu=0.00ms elapsed=36.07s tid=0x00000152f37ba200 nid=0xb7f8 runnable

"GC Thread#0" os_prio=2 cpu=0.00ms elapsed=36.07s tid=0x00000152d93b9a40 nid=0x2658 runnable

"G1 Main Marker" os_prio=2 cpu=0.00ms elapsed=36.07s tid=0x00000152d93bd9a0 nid=0x9ac8 runnable

"G1 Conc#0" os_prio=2 cpu=0.00ms elapsed=36.07s tid=0x00000152d93be3b0 nid=0xac44 runnable

"G1 Refine#0" os_prio=2 cpu=0.00ms elapsed=36.07s tid=0x00000152d944e5e0 nid=0x4778 runnable

"G1 Service" os_prio=2 cpu=0.00ms elapsed=36.07s tid=0x00000152f3684210 nid=0xb300 runnable

"VM Periodic Task Thread" os_prio=2 cpu=0.00ms elapsed=35.69s tid=0x00000152d93de9e0 nid=0xb750 waiting on condition

JNI global refs: 767, weak refs: 0

远程连接

 jstack -l <hostname>:<port>

        这里的 <hostname> 是远程服务器的地址，<port> 是JVM的JMX端口号，通常在启动Java应用时通过 -Dcom.sun.management.jmxremote.port=<port> 参数指定。

 应用

  1. 死锁，Deadlock(重点关注)
  2. 等待资源，Waiting on condition(重点关注)
  3. 等待获取监视器，Waiting on monitor entry(重点关注)
  4. 阻塞，Blocked(重点关注）
  5. 执行中，Runnable
  6. 暂停，Suspended
  7. 对象等待中，Object.wait或TIMED_WAITING
  8. 停止，Parked

案例-死锁

        死锁是指两个或两个以上的线程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力干涉那它们都将无法推进下去

产生死锁主要原因

  1. 系统资源不足
  2. 进程运行推进的顺序不合适
  3. 资源分配不当

示例

public class DeadLockDemo {
  static Object lockA = new Object();
  static Object lockB = new Object();


  public static void main(String[] args) {

    Thread a = new Thread(() -> {
      synchronized (lockA) {
        System.out.println(Thread.currentThread().getName() + "\t" + " 自己持有A锁，期待获得B锁");

        try {
          TimeUnit.SECONDS.sleep(1);
        } catch (InterruptedException e) {
          e.printStackTrace();
        }

        //锁b 已被其他线程持有
        synchronized (lockB) {
          System.out.println(Thread.currentThread().getName() + "\t 获得B锁成功");
        }
      }
    }, "a");
    a.start();

    new Thread(() -> {
      synchronized (lockB) {
        System.out.println(Thread.currentThread().getName() + "\t" + " 自己持有B锁，期待获得A锁");

        try {
          TimeUnit.SECONDS.sleep(1);
        } catch (InterruptedException e) {
          e.printStackTrace();
        }

        //锁A 已被其他线程持有
        synchronized (lockA) {
          System.out.println(Thread.currentThread().getName() + "\t 获得A锁成功");
        }
      }
    }, "b").start();
  }
}

try lock 避免死锁

public class TryLockDeadlock implements Runnable {


  int flag = 1;
  static Lock lock1 = new ReentrantLock();
  static Lock lock2 = new ReentrantLock();

  public static void main(String[] args) {
    TryLockDeadlock r1 = new TryLockDeadlock();
    TryLockDeadlock r2 = new TryLockDeadlock();
    r1.flag = 0;
    new Thread(r1).start();
    new Thread(r2).start();

  }

  @Override
  public void run() {
    for (int i = 0; i < 100; i++) {
      if (flag == 1) {
        try {
          if (lock1.tryLock(800, TimeUnit.MILLISECONDS)) {
            try {
              System.out.println("线程1获取到了锁1");
              Thread.sleep(new Random().nextInt(1000));
              if (lock2.tryLock(800, TimeUnit.MILLISECONDS)) {
                try {
                  System.out.println("线程1获取到了锁2");
                  System.out.println("线程1成功获取到了两把锁");
                  break;
                } finally {
                  lock2.unlock();
                }
              } else {
                System.out.println("线程1获取锁2失败，已重试");
              }
            } finally {
              lock1.unlock();
              Thread.sleep(new Random().nextInt(1000));
            }
          } else {
            System.out.println("线程1获取锁1失败，已重试");
          }
        } catch (InterruptedException e) {
          e.printStackTrace();
        }
      }

      if (flag == 0) {
        try {
          if (lock2.tryLock(3000, TimeUnit.MILLISECONDS)) {
            try {
              System.out.println("线程2获取到了锁2");
              Thread.sleep(new Random().nextInt(1000));
              if (lock1.tryLock(800, TimeUnit.MILLISECONDS)) {
                try {
                  System.out.println("线程2获取到了锁1");
                  System.out.println("线程2成功获取到了两把锁");
                  break;
                } finally {
                  lock1.unlock();
                }
              } else {
                System.out.println("线程2获取锁1失败，已重试");
              }
            } finally {
              lock2.unlock();
              Thread.sleep(new Random().nextInt(1000));
            }
          } else {
            System.out.println("线程2获取锁2失败，已重试");
          }
        } catch (InterruptedException e) {
          e.printStackTrace();
        }
      }
    }
  }
}

3. 排查

 jps -l

死锁的类，进程号

 jstack 进程编号

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

"Thread-1":
  waiting to lock monitor 0x00000218c5625770 (object 0x0000000629237030, a java.lang.Object),
  which is held by "Thread-0"

Java stack information for the threads listed above:
===================================================
"Thread-0":
        at com.du.cpu.JstackDeadLockDemo.calLock_Obj1_First(JstackDeadLockDemo.java:36)
        - waiting to lock <0x0000000629237040> (a java.lang.Object)
        - locked <0x0000000629237030> (a java.lang.Object)
        at com.du.cpu.JstackDeadLockDemo.lambda$testDeadlock$0(JstackDeadLockDemo.java:22)
        at com.du.cpu.JstackDeadLockDemo$$Lambda$14/0x0000000800c01208.run(Unknown Source)
        at java.lang.Thread.run(java.base@17.0.2/Thread.java:833)
"Thread-1":
        at com.du.cpu.JstackDeadLockDemo.calLock_Obj2_First(JstackDeadLockDemo.java:49)
        - waiting to lock <0x0000000629237030> (a java.lang.Object)
        - locked <0x0000000629237040> (a java.lang.Object)
        at com.du.cpu.JstackDeadLockDemo.lambda$testDeadlock$1(JstackDeadLockDemo.java:23)
        at com.du.cpu.JstackDeadLockDemo$$Lambda$15/0x0000000800c01428.run(Unknown Source)
        at java.lang.Thread.run(java.base@17.0.2/Thread.java:833)

Found 1 deadlock.

jconsole

存在,及合理
关注
  • 5
    点赞
  • 踩
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
JVM问题排查——死锁
m0_46311226的博客
03-19 1972
文章目录环境准备工作排查姿势一：使用JVisualVM排查姿势二：使用Jps+Jstack 环境 JDK8   准备工作 先准备好一个死锁程序：（程序是网上随便找的） public class DeadLock { public static String obj1 = "obj1"; public static String obj2 = "obj2"; pu...
java 查看线程死锁
weixin_34043301的博客
06-03 294
　那我们怎么确定一定是死锁呢？有两种方法。 　　1>使用JDK给我们的的工具JConsole，可以通过打开cmd然后输入jconsole打开。 　　　　1)连接到需要查看的进程。 2）打开线程选项卡，然后点击左下角的“检测死锁” 　　　　3）jconsole就会给我们检测出该线程中造成死锁的线程，点击选中即可查看详情： 　　　　 从上图中我们可以看出： 　　　　　...
Java死锁问题排查解决
最新发布
刘皇叔说Java的博客
07-31 632
使用 Java VisualVM（简称 VisualVM）排查线上死锁是一个常见的实践，因为它提供了丰富的图形化界面，便于实时监控和诊断 Java 应用的运行情况。如果存在死锁，jstack 会在输出的末尾部分显示死锁相关的信息，包括哪些线程涉及以及它们正在等待哪些锁。使用线程转储（Thread Dump）线程转储 是诊断 Java 死锁的常用方法，可以查看所有线程的状态及其持有的锁信息。死锁，简单来说就是两个或者两个以上的线程在执行的过程中，争夺同一个共享资源造成的相互等待的现象。
jvm--死锁
yuke98727的博客
05-20 251
1、死锁定义 2、产生死锁demo 3、定位原因
Java线程死锁
allway2的博客
01-27 220
Java中的死锁是什么？ Java中的死锁是两个或更多线程永远被阻塞，互相等待的情况。 当多个线程需要相同的锁但以不同的顺序获得它们时，通常会发生这种情况。Java中的多线程编程由于synced关键字而陷入僵局。 它导致正在执行的线程在等待与指定对象关联的锁或监视器时阻塞。 死锁示例 package com.example.thread.deadlock.lock; import java.util.concurrent.locks.Lock; import java.util...
JVM调优实战场景二，死锁
David_bdqn的博客
09-05 2141
死锁（Dead Lock）：两个或以上的运算单元（进程、线程或协程），都在等待对方停止执行，以取得系统资源，但是没有一方提前退出。 1、模拟异常代码，开启两个线程，互相等待对方释放资源。sleep（2000）保证，两个线程第一时间能成功持有各自的第一个对象锁。 private static Object lock1 = new Object(); private static Object lock2 = new Object(); /** * 线程互相等待对方释
JVM---jstack分析Java线程CPU占用,线程死锁的解决
10-14
线程死锁是多线程编程中常见的问题，表现为两个或多个线程相互等待对方释放资源，导致都无法继续执行。分析线程死锁的步骤如下： 1. **构造死锁场景**：创建一个能引发死锁的Java程序，比如多个线程持有并请求其他...
基于Java的源码-多线程程序死锁检查 JCarder.zip
07-23
然而，多线程编程也带来了许多挑战，其中之一就是死锁。死锁是指两个或更多个线程相互等待对方释放资源，导致它们都无法继续执行的情况。为了解决这个问题，开发者需要有工具来检测和避免死锁的发生。 JCarder是一...
基于Java的实例源码-多线程程序死锁检查 JCarder.zip
06-28
在Java编程中，多线程是并发执行任务的关键机制，然而，如果不正确地管理线程间的资源竞争，可能会导致死锁。死锁是指两个或多个线程相互等待对方释放资源，从而导致它们都无法继续执行的状态。`JCarder`是一个用于...
jvm-mon基于控制台的JVM监视
08-06
3. **线程状态**：`jvm-mon`可展示当前运行的线程数量及状态，如RUNNABLE、WAITING、TIMED_WAITING等，这对于排查线程阻塞和死锁问题非常有帮助。 4. **类加载统计**：显示已加载的类数量，帮助分析类加载是否正常...
jvm调优测试仓库-jvm-monitor.zip
11-07
3. 线程优化：监控线程状态，减少死锁、阻塞和竞争条件。 4. 类加载优化：避免过多的类加载，减少类空间的占用。 5. 方法区和元空间：适当调整元空间大小，避免OutOfMemoryError。 6. 缓存和池优化：如数据库连接...
什么是死锁？JVM线程死锁，你该如何判断是因为什么？如果用VisualVM，dump线程信息出来，会有哪些信息？
小汤圆
04-26 273
线程死锁是指由于两个或者多个线程互相持有对方所需要的资源，导致这些线程处于等待状态，无法前往执行。 常常需要在隔两分钟后再次收集一次thread dump，如果得到的输出相同，仍然是大量thread都在等待给同一个 地址上锁，那么肯定是死锁了。 ...
JVM的线程状态及死锁
刚学会HelloWorld的XXX的博客
02-27 519
JVM的线程状态及如何排查死锁原因 http://blog.csdn.net/u014484649/article/details/27338819 VisualVM排查JAVA应用程序线程死锁 http://blog.csdn.net/chwshuang/article/details/44203537 使用 VisualVM 进行性能分析及调优 https://www.ibm.com...
JVM-05-诊断cpu占用过高与线程死锁
na_tion的专栏
03-21 430
一、诊断线程cpu占用过高步骤 1、用top命令定位哪个进程对cpu的占用过高； 2、查看进程的那个线程占用cpu高 ps H -eo pid,tid,%cpu | grep 进程id //pid:显示进程 //tid：显示线程 //%cpu: 显示占用cpu占用 3、jstack 进程id 可以根据线程id 找到有问题的线程，进一步定位到问题代码的源码行号 32665为十进制，需要转为十六进制为7f99（jstack命令显示的线程id用16进制表示） 二、定位线程死.
JVM的线程状态及如何排查死锁原因
u014484649的专栏
05-28 8494
1、TIMED_WAITING 2、waiting 3、blocked 4、runnable
JAVA并发编程：深入解析死锁、如何使用JVM自带分析工具检测死锁
菜鸟技术栈的专栏
09-15 322
1、什么是死锁？ 死锁是指两个或两个以上的进程（或线程）在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。 此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。 2、产生死锁的必要条件 互斥条件：所谓互斥就是进程在某一时间内独占资源。 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。 不剥夺条件:进程已获得资源，在末使用完之前，不能强行剥夺。 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
java线程死锁_Java线程死锁–案例研究
最佳 Java 编程
06-03 239
java线程死锁 本文将描述从在IBM JVM 1.6上运行的Weblogic 11g生产系统中观察到的最新Java死锁问题的完整根本原因分析。 此案例研究还将证明掌握线程转储分析技能的重要性； 包括用于IBM JVM Thread Dump格式。 环境规格 – Java EE服务器：Oracle Weblogic Server 11g和Spring 2.0.5 –操作系统：AIX ...
jvm内存泄露和内存死锁排查
kkchff的博客
08-25 1467
使用工具jconsole和visualvm jconsole可以查看内存状况和死锁 内存泄露代码 package com.test; import java.util.*; public class Heap{ public static void main(String[] args) throws InterruptedException{ ArrayL...
JVM之检测死锁与内存溢出
m0_73311735的博客
05-05 237
我们在进行JVM调优的时候经常会遇到OOM跟死锁等待，所以如果发现了这两类情况，那就必须把他们检测出来，检测哪一部分出现了问题，使用一些工具将问题给定位出来并且解决，合理的进行调优。当然JVM调优不是一蹴而就的，JVM调到最优需要进行多次调优，而且也不存在最优解，因为你可能会发现，这一次调优已经很好了，但是修改一下参数可能又比上一次更优。
Java软件开发核心知识：JVM、多线程、基础、泛型和Spring
然而，多线程编程也可能引发许多并发问题，比如死锁、竞态条件等。因此，掌握多线程编程的核心知识是必要的。我们将研究线程的生命周期、线程同步机制和线程池等概念，并介绍如何避免并发问题。 在掌握了JVM和多...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值