调试排错 - Java问题排查：工具单

转载：调试排错 - Java问题排查：工具单

1. Java 调试入门工具

1.1 jps

jps是jdk提供的一个查看当前java进程的小工具， 可以看做是JavaVirtual Machine Process Status Tool的缩写。

jps常用命令：

jps # 显示进程的ID 和 类的名称
jps –l # 输出输出完全的包名，应用主类名，jar的完全路径名 
jps –v # 输出jvm参数
jps –q # 显示java进程号
jps -m # main 方法
jps -l xxx.xxx.xx.xx # 远程查看

jps参数：

-q：仅输出VM标识符，不包括classname,jar name,arguments in main method 
-m：输出main method的参数 
-l：输出完全的包名，应用主类名，jar的完全路径名 
-v：输出jvm参数 
-V：输出通过flag文件传递到JVM中的参数(.hotspotrc文件或-XX:Flags=所指定的文件 
-Joption：传递参数到vm,例如:-J-Xms512m

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了。

上一页Java 调试排错下一页Java

最后更新于

这有帮助吗？