jstack

jstack 用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息，如果是在64位机器上，需要指定选项"-J-d64"，Windows的jstack使用方式只支持以下的这种方式： jstack [-l][F] pid 如果java程序崩溃生成core文件，jstack工具可以用来获得core文件的java stack和native stack的信息，从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。另外，jstack工具还可以附属到正在运行的java程序中，看到当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现hung的状态，jstack是非常有用的。进程处于hung死状态可以用-F强制打出stack。 dump 文件里，值得关注的线程状态有： 死锁， Deadlock（重点关注） 执行中，Runnable 等待资源， Waiting on condition（重点关注） 等待获取监视器， Waiting on monitor entry（重点关注） 暂停，Suspended 对象等待中，Object.wait() 或 TIMED_WAITING 阻塞， Blocked（重点关注） 停止，Parked 在摘了另一篇博客的三种场景： 实例一：Waiting to lock 和

原文地址：https://yq.aliyun.com/articles/69520 我的问题排查工具箱 前言 平时的工作中经常碰到很多疑难问题的处理，在解决问题的同时，有一些工具起到了相当大的作用，在此书写下来，一是作为笔记，可以让自己后续忘记了可快速翻阅，二是分享，希望看到此文的同学们可以拿出自己日常觉得帮助很大的工具，大家一起进步。 闲话不多说，开搞。 Linux命令类 tail 最常用的tail -f tail -300f shopbase.log #倒数300行并进入实时监听文件写入模式 grep grep forest f.txt #文件查找 grep forest f.txt cpf.txt #多文件查找 grep 'log' /home/admin -r -n #目录下查找所有符合关键字的文件 cat f.txt | grep -i shopbase grep 'shopbase' /home/admin -r -n --include *.{vm,java} #指定文件后缀 grep 'shopbase' /home/admin -r -n --exclude *.{vm,java} #反匹配 seq 10 | grep 5 -A 3 #上匹配 seq 10 | grep 5 -B 3 #下匹配 seq 10 | grep 5 -C 3 #上下匹配，平时用这个就妥了

NAME jstack - Prints Java thread stack traces for a Java process, core file, or remote debug server. SYNOPSIS jstack [ options ] pid jstack [ options ] executable core jstack [ options ] [ server-id@ ] remote-hostname-or-IP 参数： -F 当’jstack [-l] pid’没有相应的时候强制打印栈信息,如果直接jstack无响应时，用于强制jstack，一般情况不需要使用。 -l 长列表. 打印关于锁的附加信息,例如属于java.util.concurrent的ownable synchronizers列表，会使得JVM停顿得长久得多（可能会差很多倍，比如普通的jstack可能几毫秒和一次GC没区别，加了 -l 就是近一秒的时间），-l 建议不要用。 -m 打印java和native c/c++ 框架的所有栈信息.可以打印JVM的堆栈,显示上Native的栈帧，一般应用排查不需要使用。 示例： jstack pid 查看线程cpu占用： top -H -p pid //找到占用较高的线程id python -c "print hex(线程id)" /

We recently upgraded from JDK6u20 (Linux, 32bit and 64bit) to JDK6u23. Since then, we cannot longer use the tools jstack and jstat to get monitoring information from the running process. If we switch back to JDK6u20, everything works fine. We are running Tomcat 6. According to this forum post, others have the same problem: http://forums.oracle.com/forums/thread.jspa?threadID=2151967&tstart=0 Running simple plain Java processes and using the tools works. Jstack says: Unable to open socket file: target process not responding or HotSpot VM not loaded The -F option can be used when the target

I have a Gui application in swing that prints a ticket on a serial thermal printer. When i hit the button that launch this action, my GUI is frozen. I think that's because the code is executed on the EDT. I used jstack to be sure but i don't understand the results below : Full thread dump Java HotSpot(TM) Client VM (23.3-b01 mixed mode, sharing): "Thread-12" prio=6 tid=0x03012000 nid=0xd04 runnable [0x038ef000] java.lang.Thread.State: RUNNABLE at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1575) "Thread-6" prio=6 tid=0x0302c400 nid=0x1b0 waiting

【参考文章】： jstack 命令使用经验总结 1. 简介 　　jstack主要用于生成java虚拟机当前时刻的线程快照。 　　线程快照是当前java虚拟机内每一条线程正在执行的方法堆栈的集合， 　　主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等 2. 基本用法 　　 2.1 jstack <pid> 　　输出当前时刻该进程的线程快照信息； 　　一般分为三个部分： 　　第一部分为是当前快照的时间信息和JVM的信息； 　　示例： 　　　　 　　第二部分为多个线程的执行情况，我们选取一个线程作为示例进行分析； 　　示例： 　　　　 　　　　main：线程名称； 　　　　prio：线程优先级； 　　　　os_prio：线程优先级； 　　　　tid：线程ID； 　　　　nid：映射到Linux系统中的轻量级进程PID，快照中用16进制表示，可转为10进制在系统中进行查看； 　　 线程当前动作 ：　　 　　　　一般记录在每个 thread dump 的第一行末尾； 　　　　 runnable ：表示线程在参数CPU竞争，可能在被调度运行，也可能在就绪等待； 　　　　 sleeping ：表示调用了 Thread.sleep()，线程进入休眠； 　　　　 waiting on condition [0x...] ： 表示线程被 阻塞原语所阻塞 ,

I have a Tomcat running as a Windows Service, and those are known not to work well with jstack. jconsole is working well, on the other hand, and I can see stacks of individual threads (I'm connecting to "localhost:port" to access it). How can I use jconsole or a similar tool to dump all the thread stacks into a file? (similar to jstack) You can use the ThreadMXBean management interface. This FullThreadDump class demonstrates the capability to get a full thread dump and also detect deadlock remotely using JMX. Nowadays you can use jvisualvm tool to connect to your remote JVM through JMX and

此文已由作者朱笑天授权网易云社区发布。 欢迎访问 网易云社区 ，了解更多网易技术产品运营经验。 问题的起因是笔者在一轮性能测试的中，发现某协议的响应时间很长，去观察哨兵监控里的javamethod监控可以看到以下结果： onMessage是该协议的总入口，可以看到该协议平均耗时为352.11ms，观察其他耗时方法可以看到updateUserForeignId耗时307.75ms，那么可以认为该方法的响应时间慢是该协议的最主要性能瓶颈，这时候我们应该看看该方法究竟做了哪些操作导致响应时间过长： 从哨兵监控中可以看到userStorage.updateUserForeignId方法耗时122.86ms，userStorage.updateForeignIdPegging方法耗时71.33ms，这两个方法有成为了SessionProcessHelper.updateUserForeignId方法的主要耗时点，基于对代码的熟悉程度xxxStroge方法都是一些数据库的操作，那么现在可以初步的认为数据库的相关操作可能是问题的根源所在，为了清楚的展示问题，我们先选择一个逻辑较简单的方法分析一下，从上面的哨兵方法监控里可以看到updateSession方法耗时34.88ms，查看该方法代码： 可以看到方法只是有一个简单的dao层的操作，通过查看dao层方法可知该方法仅仅是一个update操作