在分析线上问题时常使用到jstack <PID>命令将当时Java应用程序的线程堆栈dump出来。
面对jstack 日志,我们如何查看?
首先要清楚线程的状态
线程的状态有:new、runnable、running、waiting、timed_waiting、blocked、dead
线程状态变迁图:
各状态说明:
New: 当线程对象创建时存在的状态,此时线程不可能执行;
Runnable:当调用thread.start()后,线程变成为Runnable状态。只要得到CPU,就可以执行;
Running:线程正在执行;
Waiting:执行thread.join()或在锁对象调用obj.wait()等情况就会进该状态,表明线程正处于等待某个资源或条件发生来唤醒自己;
Timed_Waiting:执行Thread.sleep(long)、thread.join(long)或obj.wait(long)等就会进该状态,与Waiting的区别在于Timed_Waiting的等待有时间限制;
Blocked:如果进入同步方法或同步代码块,没有获取到锁,则会进入该状态;
Dead:线程执行完毕,或者抛出了未捕获的异常之后,会进入dead状态,表示该线程结束
其次,对于jstack日志,我们要着重关注如下关键信息
Deadlock:表示有死锁
Waiting on condition:等待某个资源或条件发生来唤醒自己。具体需要结合jstacktrace来分析,比如线程正在sleep,网络读写繁忙而等待
Blocked:阻塞 Waiting on monitor entry:在等待获取锁
in Object.wait():获取锁后又执行obj.wait()放弃锁
对于Waiting on monitor entry 和 in Object.wait()的详细描述:Monitor是 Java中用以实现线程之间的互斥与协作的主要手段,它可以看成是对象或者 Class的锁。每一个对象都有,也仅有一个 monitor。从下图中可以看出,每个 Monitor在某个时刻,只能被一个线程拥有,该线程就是 "Active Thread",而其它线程都是 "Waiting Thread",分别在两个队列 " Entry Set"和 "Wait Set"里面等候。在 "Entry Set"中等待的线程状态是 "Waiting for monitor entry",而在 "Wait Set"中等待的线程状态是 "in Object.wait()"
最后通过示例来实践一下
示例一:描述 Blocked 和 Waiting to lock
执行后程序输出:
Thread[main,5,main]
说明主线程先进入同步代码块,获取到thread2对象上的锁。
通过jstack输出结果:
先说明下日志格式:
"thread2"为线程名称,在平时创建线程或线程池时请务必取一个见明之义的线程名称,方便排查问题;
prio=6:线程优先级,不用关心;
tid=0x0000000006540800:线程id,不用关心;
nid=0x2be4:操作系统映射的线程id, 非常关键,后面再使用jstack时补充;
waiting for monitor entry:表示线程正在等待获取锁
0x0000000006dbf000:线程栈起始地址
从jstack日志中,可以看到:主线程获取到thread2对象上的锁,因此正在执行sleep操作,状态为TIMED_WAINTING, 而thread2由于未获取到thread2对象上的锁,因此处于BLOCKED状态。
再细看,thread2 正在"waiting to lock <0x00000000d719d280>",即试图在地址为0x00000000d719d280所在的对象获取锁,而该锁却被main线程占有(locked <0x00000000d719d280>)。main线程正在"waiting on condition",说明正在等待某个条件触发,由jstacktrace来看,此线程正在sleep。
经验:如果在jstack日志发现大量的线程在waiting to lock 某个地址,只要能查到哪个线程获取到锁就可以方便定位问题了
示例二:描述waiting on condition
]
jstack日志输出结果:
从日志中可以看到,main线程的状态是Waiting,正在"waiting on condition"来唤醒自己。
结合jstackstrace日志来看,"parking to wait for <0x00000000d719ba70> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)"说明在调用ArrayBlockingQueue.put()阻塞了。
示例三:描述Object.wait()
程序输出结果:
Thread[thread2,5,main]
Thread[main,5,main]
说明线程thread2先进入同步代码块,获取到thread2对象上的锁。
jstack日志输出结果:
可以看出:线程thread2的状态是"Waiting", 正在"in Object.wait()"。表明该线程在获取到对象锁后,调用obj.wait()方法,放弃了锁,进入了"Wait Set"队列。
相关推荐
主要介绍了Java线程Dump分析工具jstack解析及使用场景,具有一定借鉴价值,需要的朋友可以参考下
需要本地安装JDK并配置JAVA环境变量。 之后使用java -jar jca469.jar即可打开工具。 直接将dump出来的堆栈信息,打开,便可分析。
抓取jstack方法及解决system用户执行jstack命令权限问题, 打开cmd窗口,输入命令 jstack -l 49824>>C:/error01.txt 其中49824为tomcat8.0 的pid ; error01.txt 这个可以自己取名字 多输出几份jstack 文件,做比对...
jstack生成的Thread Dump日志.docx 系统线程状态 (Native Thread Status) 系统线程有如下状态: deadlock 死锁线程,一般指多个线程调用期间进入了相互资源占用,导致一直等待无法释放的情况。 ...
MPP的jstack分析结果
图形界面分析threadump_jstack分析工具_包含jdk。IBM出品,用来分析jstack pid 打印的信息。用着挺方便的。
windows系统jstack自动抓取脚本
JStack和Java Thread Dumps分析
Broken pipe产生的原因通常是当管道读端没有在读,而管道的写端继续有线程在写,就会造成管道中断。(由于管道是单向通信的) SIGSEGV(Segment fault)意味着指针所对应的地址是无效地址,没有物理内存对应该地址。
使用jstack定位分析CPU消耗问题
JVM监控工具介绍jstack, jconsole, jinfo, jmap, jdb, jstat.doc
用jstack分析CPU占用率高的原因 1 top -H -p pid 2 linux printf命令将10进制转换为16进制 3在jstack中找到相应的堆栈信息jstack pid grep 'nid' -C5 –color
2019最新深入理解JVM内存结构及运行原理(JVM调优)高级核心课程视频教程下载。JVM是Java知识体系中的重要部分,对JVM底层的了解是每一位Java程序员深入Java技术领域的重要因素。本课程试图通过简单易懂的方式,系统...
自动抓取jstack
通过ps到java进程号将进程的jstack信息输出。jstack信息是java进程的线程堆栈信息,通过该信息可以分析java的线程阻塞等问题。
(1)如果堆栈信息明确是应用代码,则证明该线程正在等待资源,一般是大量读取某种资源且该资源采用了资源锁的情况下,线程进入等待状态,等待资源的读取,或者正在等待其
这是一个 jstack 保存的死锁现场,由于 log4j consoleAppender 和 System.out 竞争资源导致的锁冲突,目前还不知道根本原因,需要分析。
Kubernetes应用java程序无法使用jmap,jstack的解决方案.docx
jmap、jstack、jstat组合使用定位jvm问题
主要介绍了如何通过jstack命令dump线程信息,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下