java调试

命令 描述
jdb 命令行调试工具
jps 列出所有Java进程的PID
jstack 列出虚拟机进程的所有线程运行状态
jmap 列出堆内存上的对象状态
jstat 记录虚拟机运行的状态，监控性能
jconsole 虚拟机性能/状态检查可视化工具

具体用法可以参考JDK文档，这些大家在线上调试应用的时候用的也不少，比如一般线上load高的问题排查步骤是

  1. 先用top找到耗资源的进程
  2. ps+grep找到对应的java进程/线程
  3. jstack分析哪些线程阻塞了，阻塞在哪里
  4. jstat看看FullGC频率
  5. jmap看看有没有内存泄露

内存泄露排查

一 、问题定位

手段一：通过 jstat -gcutil 快速定位GC问题(首先)

  1. 命令格式： jstat  -gcutil  <pid>  <period> 
  3. 命令样例：jstat  -gcutil  11900  3s
  5. ------> 监控进程11900的GC情况, 每3s输出一条记录。
  7. 要点：O列(老年代内存使用率)一直接近100%；
  9. 　　    FG列(Full GC次数) 一直增长。

手段二：增加Xmx参数，加大堆内存排除堆内存过小因素影响。

  1. 在jstat   -gcutil 的O列占满情况，需进一步排除是否是堆内存分配过小，满足不了业务请求量导致。
  3. 查看最大堆内存命令：jinfo  -flag  MaxHeapSize  <pid> 。
  5. 假如开始是4G，修改成8G：java  -Xmx8G
  7. 要点：增加最大堆内存后，使用jstat  -gcutil 看O列是否满负,如果还是满负, 则可基本确定是内存泄露。

手段三：使用 jmap -histo 命令定位内存泄露具体对象。

  1. 该命令展示所有类的实例个数以及内存用量情况，并按照使用量降序输出，一般自己写的类有内存泄露，那会名列前茅。
  3. 命令1：jmap -histo  <pid>
  5. 命令样例：jmap  -histo 42530 | head  -n  20
  7. 输出对应进程当前所有存活对象的堆内存占用情况,找到"突出" 的嫌疑类。
  9. 命令2：jmap  -histo:live  <pid>
  11. 带上live,会触发一次Full GC后再输出结果,实际上就是回收了无用的对象,输出真正存活的对象情况。如果嫌疑类名实例数不减，那么十有八九这个类就是导致内存泄露根因。
  13. 要点：两个命令对比观察Full GC后,实例数不减的类,重点关注排在前面的几个自己写的类名。

手段四：使用 jmap -dump:file 导出堆内存数据。

  1. 通过手段三，一般可以定位出代码位置，但代码中很多地方引用了这个类，则要导出 Dump 文件，进一步分析泄露对象的GCRoot 。
  3. 命令：jmap  -dump:file=<文件名> <pid>
  5. 样例：jmap  -dump:file=app.dump  9336
  7. 分析dump文件的工具：除了JDK自带的 jhat , jvisualvm ，还有第三方的MAT，jprofiler等。
  9. 内存泄露的话，dump文件也会很大,为了防止卡死，一般会将Xmx控制在一个合适的大小(2G) ,重现问题后, 再导出dump 。
  11. 要点：将Xmx设小一点,再导出dump。

手段五：jhat分析dump文件，寻找GC Root。

  1. 因为网络拷贝大容量的dump文件诸多不便，所以需要现网直接分析dump文件，jhat可以启动一个http服务，提供页面远程分析对象引用情况。
  3. 命令：jhat  -J-Xmx2G  -port <port> <dump文件>
  5. 样例：jhat  -J-Xmx2G  app.dump
  7. 其中Xmx2G代表使用2G堆内存运行jhat，下一步可浏览器分析了，URL：http://ip:7000
  9. 要点：首先链接到嫌疑类的具体某个对象页面，分析这个对象的引用情况是否正常，再通过“Reference chains from Rootset ”获取所有的GC Root ,进而定位到具体代码位置。