jstack 查看死锁现象

最新推荐文章于 2024-05-20 11:49:02 发布
最新推荐文章于 2024-05-20 11:49:02 发布
阅读量545 收藏
点赞数
分类专栏： synchronized 文章标签： java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u013761206/article/details/120385712
版权

代码：

public class ServerApplication {
private static  class InnerTest{



    public void  add(){

        this.add();

    }


    private Integer a = 0;

    private Integer b =1;


    public  void mockCompeteA(){

        synchronized (a){

            System.out.println("A拿到a锁");

            synchronized (b){

                System.out.println("A拿到b锁");

            }

        }

    }


    public  void mockCompeteB(){

        synchronized (b){

            System.out.println("B拿到b锁");

            synchronized (a){

                System.out.println("B拿到a锁");

            }

        }

    }


}


public static void main(String[] args) {


    List<InnerTest> innerTestList =  new ArrayList<>();

    InnerTest innerTest =  new InnerTest();


    Thread a = new Thread(new Runnable() {
        @Override
        public void run() {
            while (true) {
                innerTest.mockCompeteA();
            }
        }
    });

       Thread b = new Thread(new Runnable() {
        @Override
        public void run() {

            while (true){

                innerTest.mockCompeteB();

            }

        }
    });


       a.start();

       b.start();


}
}

jstack -l 32480 > E:\vmlog\32480.txt

32480.txt内容：

2021-09-19 22:20:23
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.251-b08 mixed mode):

"Thread-1" #13 prio=5 os_prio=0 tid=0x000000001f0d1800 nid=0x813c waiting for monitor entry [0x000000001fabf000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at com.server.ServerApplication$InnerTest.mockCompeteB(ServerApplication.java:64)
    - waiting to lock <0x00000006cbc634c0> (a java.lang.Integer)
    - locked <0x00000006cbc634d0> (a java.lang.Integer)
    at com.server.ServerApplication$2.run(ServerApplication.java:99)
    at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
    - None

"Thread-0" #12 prio=5 os_prio=0 tid=0x000000001f0cf000 nid=0x828c waiting for monitor entry [0x000000001f9bf000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at com.server.ServerApplication$InnerTest.mockCompeteA(ServerApplication.java:47)
    - waiting to lock <0x00000006cbc634d0> (a java.lang.Integer)
    - locked <0x00000006cbc634c0> (a java.lang.Integer)
    at com.server.ServerApplication$1.run(ServerApplication.java:88)
    at java.lang.Thread.run(Thread.java:748)

   Locked ownable synchronizers:
    - None

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

   Locked ownable synchronizers:
    - None

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

   Locked ownable synchronizers:
    - None

"C2 CompilerThread2" #9 daemon prio=9 os_prio=2 tid=0x000000001e4ca800 nid=0xa3d4 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
    - None

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

   Locked ownable synchronizers:
    - None

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

   Locked ownable synchronizers:
    - None

"Monitor Ctrl-Break" #6 daemon prio=5 os_prio=0 tid=0x000000001e4c1000 nid=0x7070 runnable [0x000000001eabe000]
   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 <0x00000006cbca03c0> (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 <0x00000006cbca03c0> (a java.io.InputStreamReader)
    at java.io.BufferedReader.readLine(BufferedReader.java:389)
    at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:64)

   Locked ownable synchronizers:
    - None

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

   Locked ownable synchronizers:
    - None

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

   Locked ownable synchronizers:
    - None

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x000000001e180800 nid=0x3a14 in Object.wait() [0x000000001e75f000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x00000006cbc89470> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
    - locked <0x00000006cbc89470> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
    at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)

   Locked ownable synchronizers:
    - None

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

   Locked ownable synchronizers:
    - None

"main" #1 prio=5 os_prio=0 tid=0x0000000002926000 nid=0xe18 runnable [0x000000000281f000]
   java.lang.Thread.State: RUNNABLE
    at com.server.ServerApplication.main(ServerApplication.java:120)

   Locked ownable synchronizers:
    - None

"VM Thread" os_prio=2 tid=0x000000001c389000 nid=0x6ae8 runnable 

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x000000000293b800 nid=0x4cb8 runnable 

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x000000000293d000 nid=0x870c runnable 

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x000000000293e800 nid=0x63bc runnable 

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x0000000002941000 nid=0x7610 runnable 

"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x0000000002943800 nid=0x61e4 runnable 

"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x0000000002944800 nid=0x39cc runnable 

"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x0000000002948000 nid=0x7258 runnable 

"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x0000000002949000 nid=0x700 runnable 

"VM Periodic Task Thread" os_prio=2 tid=0x000000001ef56000 nid=0x56f0 waiting on condition 

JNI global references: 12


Found one Java-level deadlock:
=============================
"Thread-1":
  waiting to lock monitor 0x000000001c393538 (object 0x00000006cbc634c0, a java.lang.Integer),
  which is held by "Thread-0"
"Thread-0":
  waiting to lock monitor 0x000000001c393698 (object 0x00000006cbc634d0, a java.lang.Integer),
  which is held by "Thread-1"

Java stack information for the threads listed above:
===================================================
"Thread-1":
    at com.server.ServerApplication$InnerTest.mockCompeteB(ServerApplication.java:64)
    - waiting to lock <0x00000006cbc634c0> (a java.lang.Integer)
    - locked <0x00000006cbc634d0> (a java.lang.Integer)
    at com.server.ServerApplication$2.run(ServerApplication.java:99)
    at java.lang.Thread.run(Thread.java:748)
"Thread-0":
    at com.server.ServerApplication$InnerTest.mockCompeteA(ServerApplication.java:47)
    - waiting to lock <0x00000006cbc634d0> (a java.lang.Integer)
    - locked <0x00000006cbc634c0> (a java.lang.Integer)
    at com.server.ServerApplication$1.run(ServerApplication.java:88)
    at java.lang.Thread.run(Thread.java:748)

Found 1 deadlock.

polarcoder
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
kirby-locked-pages::locked_with_key:密码保护页面，包括面板蓝图
05-07
柯比锁定页面 使用密码保护您要从不需要的视图中隐藏的页面。 主要特征 :locked: 轻松用密码保护单个页面 :framed_picture: 包括面板图 要求 柯比3 PHP 7.3以上 安装 下载 下载该存储库并将其复制到/site/plugins/kirby-locked-pages 。 Git子模块 git submodule add https://github.com/johannschopplich/kirby-locked-pages.git site/plugins/kirby-locked-pages 作曲家 composer require johannschopplich/kirby-locked-pages 用法 当访问锁定页面时，Kirby将重定向到一个登录表单（），您可以在其中输入密码。 用户输入正确的密码后，他将被重定向回之前被锁定的页面网址。 该会话还记录了该页面现在已为用户解锁。 会话期满
Diode-pumped passively mode-locked femtosecond Yb:(Y0.9La0.1)2O3 ceramic laser
02-06
We experimentally demonstrate a diode-pumped passively mode-locked femtosecond laser with Yb3+-doped yttrium lanthanum oxide ceramic. Mode-locking is achieved by using a semiconductor saturable absorber mirror, and intracavity dispersion is compensated by a pair of SF6 prisms. Laser pulses as short as 357 fs at a central wavelength of 1 075 nm are obtained. The maximum average output power is 670 mW under 4.5 W of pumping power with a slope efficiency of 20%. To the best of our knowledge, this i
JVM优化之使用Jstack命令查找JVM死锁
最新发布
qq_41139119的博客
05-20 214
JVM优化之使用Jstack命令查找JVM死锁
java.util.concurrent.locks
BLOG域名:programb.blog.csdn.net
05-12 187
Interfaces and classes providing a framework for locking and waiting for conditions that is distinct from built-in synchronization and monitors. The framework permits much greater flexibility in the use of locks and conditions, at the expense of more awkwa
JVM之jstack实战死锁问题
write less , do more
10-10 1594
这个条件占用部分资源的线程进一步申请其他资源时，如果申请不到可以主动释放它占有的资源，这样不可抢占这个条件就破坏掉了。线程尝试获取锁的时候加上一定的时限，超过时限则放弃对该锁的请求，并释放自己占有的锁。编写代码，启动2个线程，Thread1拿到了obj1锁，准备去拿obj2锁时，obj2已经被Thread2锁定，所以发送了死锁。，即存在一个等待队列：T1等待占有T2的资源，T2等待占有T3的资源，T3等待占有T1的资源。这样就形成了一个等待环路。，即当资源请求者在请求其他的资源的同时保持对原有资源的占有。
JAVA进阶5 性能分析工具——JStack
编程圈子-谢厂节的博客
12-01 2833
当线程获得了 Monitor，进入了临界区之后，如果发现线程继续运行的条件没有满足，它则调用对象（一般就是被 synchronized 的对象）的 wait() 方法，放弃了 Monitor，进入 “Wait Set”队列。但是，要注意的是，因为 Lock类只是一个普通类， JVM无从得知 Lock对象的占用情况，所以在线程 DUMP中，也不会包含关于 Lock的信息， 关于死锁等问题，就不如用 synchronized的编程方式容易识别。比如，在程序中，有多个服务线程，设计成从一个队列里面读取请求数据。
jstack排查死锁问题
个人日常记录,分析
10-24 2066
死锁问题排查学习,一起进步
jstack命令解析
denghonghao的博客
01-03 1432
jstack用法 /opt/java8/bin/jstack Usage: jstack [-l] <pid> (to connect to running process) 连接活动线程 jstack -F [-m] [-l] <pid> (to connect to a hung process) 连接阻塞线程...
jstack命令及其死锁、CPU飙高问题排查使用
IT- 研究者
03-07 2226
一、jstack用法 [root@smdw tang]# jstack Usage: jstack [-l] <pid> (to connect to running process) jstack -F [-m] [-l] <pid> (to connect to a hung process) jstack [...
使用jstack排查JVM进程死锁
水妖
10-28 1573
jstack查看运行期间线程信息神器
jvm工具-jstack使用
菜鸟腾飞
04-10 4553
一、介绍 jstack是java虚拟机自带的一种堆栈跟踪工具。jstack用于打印出给定的java进程ID或core&nbsp;file或远程调试服务的Java堆栈信息，如果是在64位机器上，需要指定选项”-J-d64”，Windows的jstack使用方式只支持以下的这种方式： jstack [-l] pid &nbsp; 主要分为两个功能：&nbsp; a．&nbsp; 针对活着的进程做本地的...
通过jstack分析解决进程死锁问题实例代码
10-18
主要介绍了通过jstack分析解决进程死锁问题实例代码，具有一定借鉴价值,需要的朋友可以参考下
JVM---jstack分析Java线程CPU占用,线程死锁的解决
10-14
`jstack`会识别出死锁并显示死锁链，每个线程的等待锁信息都会被列出。 5. **定位问题**：根据死锁链上的信息，找到造成死锁的具体代码位置，对锁的使用进行调整以避免死锁。 在实际生产环境中，线程问题可能更加...
MPP的jstack分析结果
06-04
MPP的jstack分析结果
如何通过jstack命令dump线程信息
10-15
`jstack`命令是Java开发中用于诊断线程堆栈信息的重要工具，它可以帮助开发者了解Java应用程序的线程状态，包括运行、等待、阻塞等，以及是否存在死锁等问题。当遇到性能问题或者线程卡住不前时，`jstack`能提供关键...
jstack文件
07-10
Broken pipe产生的原因通常是当管道读端没有在读，而管道的写端继续有线程在写，就会造成管道中断。（由于管道是单向通信的） SIGSEGV(Segment fault)意味着指针所对应的地址是无效地址，没有物理内存对应该地址。
Locked ownable synchronizers（转）
Mr_moving
11-03 8587
public class DeadLock { public static void main(final String[] args) throws Exception { final Object lock1 = new Object(); final Object lock2 = new Object(); Thread.currentThread().setName("main-thread"); final Thread r
Java 程序死锁问题原理及解决方案(来源IBM开发者论坛本文作者文章)
09-03 2089
本文首先介绍了死锁发生的原因，并通过一个示例解释了死锁发生的前提情况。然后通过 JVM 的 jstack 工具演示了如何确定一个死锁的发生。最后对死锁的预防、恢复等方式进行了解释。 原文地址：https://www.ibm.com/developerworks/cn/java/j-lo-deadlock/
JDK 常用工具 —— jstack 详解
lly__lly的博客
07-09 3839
jstack 详解
jstack查看线程死锁
09-06
jstack是Java开发中的一个命令，主要用于查看Java线程的调用堆栈，可以用来分析线程问题，比如死锁问题。通过使用jstack命令，可以获取线程的状态和调用堆栈信息。 当使用jstack命令查看线程死锁时，可以根据输出...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值