调试排错 - Java问题排查:工具单
1. Java 调试入门工具
1.1 jps
jps是jdk提供的一个查看当前java进程的小工具, 可以看做是JavaVirtual Machine Process Status Tool的缩写。
jps常用命令:
jps参数:
jps原理:
java程序在启动以后,会在java.io.tmpdir指定的目录下,就是临时文件夹里,生成一个类似于hsperfdata_User的文件夹,这个文件夹里(在Linux中为/tmp/hsperfdata_{userName}/),有几个文件,名字就是java进程的pid,因此列出当前运行的java进程,只是把这个目录里的文件名列一下而已。 至于系统的参数什么,就可以解析这几个文件获得。
更多请参考 jps - Java Virtual Machine Process Status Tool
1.2 jstack
jstack是jdk自带的线程堆栈分析工具,使用该命令可以查看或导出 Java 应用程序中线程堆栈信息。
jstack常用命令:
jstack参数:
更多请参考: jvm 性能调优工具之 jstack
1.3 jinfo
jinfo 是 JDK 自带的命令,可以用来查看正在运行的 java 应用程序的扩展参数,包括Java System属性和JVM命令行参数;也可以动态的修改正在运行的 JVM 一些参数。当系统崩溃时,jinfo可以从core文件里面知道崩溃的Java应用程序的配置信息。
jinfo常用命令:
jinfo参数:
更多请参考:jvm 性能调优工具之 jinfo
1.4 jmap
命令jmap是一个多功能的命令。它可以生成 java 程序的 dump 文件, 也可以查看堆内对象示例的统计信息、查看 ClassLoader 的信息以及 finalizer 队列。
两个用途:
jmap参数:
更多请参考:jvm 性能调优工具之 jmap (opens new window)和 jmap - Memory Map
1.5 jstat
jstat参数众多,但是使用一个就够了。
1.6 jdb
jdb可以用来预发debug,假设你预发的java_home是/opt/java/,远程调试端口是8000。那么:
出现以上代表jdb启动成功。后续可以进行设置断点进行调试。
具体参数可见oracle官方说明jdb - The Java Debugger
1.7 CHLSDB
CHLSDB感觉很多情况下可以看到更好玩的东西,不详细叙述了。 查询资料听说jstack和jmap等工具就是基于它的。
更详细的可见R大此贴 http://rednaxelafx.iteye.com/blog/1847971
2. Java 调试进阶工具
2.1 btrace
首当其冲的要说的是btrace。真是生产环境&预发的排查问题大杀器。 简介什么的就不说了。直接上代码干:
查看当前谁调用了ArrayList的add方法,同时只打印当前ArrayList的size大于500的线程调用栈。
监控当前服务方法被调用时返回的值以及请求的参数。
著作权归https://www.pdai.tech所有。 链接:https://www.pdai.tech/md/java/jvm/java-jvm-debug-tools-list.html
btrace 具体可以参考这里:https://github.com/btraceio/btrace
注意:
经过观察,1.3.9的release输出不稳定,要多触发几次才能看到正确的结果
正则表达式匹配trace类时范围一定要控制,否则极有可能出现跑满CPU导致应用卡死的情况
由于是字节码注入的原理,想要应用恢复到正常情况,需要重启应用。
2.2 Greys
Greys是@杜琨的大作吧。说几个挺棒的功能(部分功能和btrace重合):
sc -df xxx
: 输出当前类的详情,包括源码位置和classloader结构trace class method
: 打印出当前方法调用的耗时情况,细分到每个方法, 对排查方法性能时很有帮助。
2.3 Arthas
Arthas是基于Greys。
具体请参考:调试排错 - Java应用在线调试Arthas
2.4 javOSize
就说一个功能:
classes
:通过修改了字节码,改变了类的内容,即时生效。 所以可以做到快速的在某个地方打个日志看看输出,缺点是对代码的侵入性太大。但是如果自己知道自己在干嘛,的确是不错的玩意儿。
其他功能Greys和btrace都能很轻易做的到,不说了。
更多请参考:官网
2.5 JProfiler
之前判断许多问题要通过JProfiler,但是现在Greys和btrace基本都能搞定了。再加上出问题的基本上都是生产环境(网络隔离),所以基本不怎么使用了,但是还是要标记一下。
更多请参考:官网
3. 其它工具
3.1 dmesg
如果发现自己的java进程悄无声息的消失了,几乎没有留下任何线索,那么dmesg一发,很有可能有你想要的。
sudo dmesg|grep -i kill|less
去找关键字oom_killer。找到的结果类似如下:
以上表明,对应的java进程被系统的OOM Killer给干掉了,得分为854. 解释一下OOM killer(Out-Of-Memory killer),该机制会监控机器的内存资源消耗。当机器内存耗尽前,该机制会扫描所有的进程(按照一定规则计算,内存占用,时间等),挑选出得分最高的进程,然后杀死,从而保护机器。
dmesg日志时间转换公式: log实际时间=格林威治1970-01-01+(当前时间秒数-系统启动至今的秒数+dmesg打印的log时间)秒数:
date -d "1970-01-01 UTC echo "$(date +%s)-$(cat /proc/uptime|cut -f 1 -d' ')+12288812.926194"|bc
seconds" 剩下的,就是看看为什么内存这么大,触发了OOM-Killer了。
最后更新于
这有帮助吗?