使用jvm命令定位线上问题

目录：

一、常见线上故障定位步骤

二、jmap命令查看进程对象的内存情况

三、jstack命令查看栈情况

四、jstat查看垃圾回收情况

一、常见线上故障定位步骤：

1、进程卡死：

发生进程卡死的情况：

（1）线程阻塞死锁，多线程竞争锁，线程等待。

（2）线程进入死循环，cpu打满，对于复杂的计算近似于死循环也会将cpu打满。

基本思路：可能是进程的某个线程极有可能是出现了类似 while 死循环的复杂计算，因此要定位出是哪个线程，程序的哪个位置。

1. 首先用top命令查看一下服务器整体运行情况，是否出现内存不足、某个进程cpu占用较高等情况。
2. jstat -gcutil pid 查看一下gc情况，看看gc是否合理，gc次数、fullgc时间，查看是否有内存泄漏的情况。
3. 使用top -H -p pid 查看进程的各个线程占用cpu的情况。
4. 发现占用cpu过高的线程，记录pid，转换成16进制。
5. 使用 jstack -l 5682 > scanner_debug.txt，命令查看线程列表，利用16进制pid查找。
6. 找到线程所在的语句。

2、OOM：

发生oom可能是内存泄漏，oom有好几种oom，注意区分。

1. 首先top看整体的内存使用情况。用shift + F 选择mem 再esc，看内存占用排名。记录占用最高内存的进程pid。
2. 使用jmap -histo pid > xxx.jmap，打印出进程所有对象的信息，查看对象的个数，占用内存情况，是否有个对象异常。
3. jstat -gcutil 3034 查看垃圾回收情况，是否fullgc时间太长。
4.  jstack -l 5682 > scanner_debug.txt打印进程的栈信息，查看是否有锁无法释放等情况。

二、jmap命令查看进程对象的相关信息

1、查看步骤：

（1）获取java进程的pid

ps -ef|grep tomcat

（2）查看前30的对象内存占用情况

jmap -histo pid|head -n 30

jmap -histo 20650 > jmap.out

2、JMAP介绍

　　打印出某个java进程（使用pid）内存内的，所有‘对象’的情况（如：产生那些对象，及其数量）。

　　可以输出所有内存中对象的工具，甚至可以将VM 中的heap，以二进制输出成文本。使用方法 jmap -histo pid。如果连用SHELL jmap -histo pid>a.log可以将其保存到文本中去，在一段时间后，使用文本对比工具，可以对比出GC回收了哪些对象。jmap -dump:format=b,file=outfile 3024可以将3024进程的内存heap输出出来到outfile文件里，再配合MAT（内存分析工具(Memory Analysis Tool），使用参见：http://blog.csdn.net/fenglibing/archive/2011/04/02/6298326.aspx）或与jhat (Java Heap Analysis Tool)一起使用，能够以图像的形式直观的展示当前内存是否有问题。

64位机上使用需要使用如下方式：

jmap -J-d64 -heap pid

2、命令格式

SYNOPSIS

       jmap [ option ] pid

       jmap [ option ] executable core

       jmap [ option ] [server-id@]remote-hostname-or-IP

3、参数说明

1)、options： 

executable Java executable from which the core dump was produced.

(可能是产生core dump的java可执行程序)

core 将被打印信息的core dump文件

remote-hostname-or-IP 远程debug服务的主机名或ip

server-id 唯一id,假如一台主机上多个远程debug服务 

2）、基本参数：

-dump:[live,]format=b,file=<filename> 使用hprof二进制形式,输出jvm的heap内容到文件=. live子选项是可选的，假如指定live选项,那么只输出活的对象到文件. 

-finalizerinfo 打印正等候回收的对象的信息.

-heap 打印heap的概要信息，GC使用的算法，heap的配置及wise heap的使用情况.

-histo[:live] 打印每个class的实例数目,内存占用,类全名信息. VM的内部类名字开头会加上前缀”*”. 如果live子参数加上后,只统计活的对象数量. 

-permstat 打印classload和jvm heap长久层的信息. 包含每个classloader的名字,活泼性,地址,父classloader和加载的class数量. 另外,内部String的数量和占用内存数也会打印出来. 

-F 强迫.在pid没有相应的时候使用-dump或者-histo参数. 在这个模式下,live子参数无效. 

-h | -help 打印辅助信息 

-J 传递参数给jmap启动的jvm. 

pid 需要被打印配相信息的java进程id,可以用jps查问.

4、使用示例

   jmap -histo 4939

[输出较多这里不贴了]

2）jmap -dump:format=b,file=test.bin 4939

Dumping heap to /home/fenglb/test.bin ...

Heap dump file created

3、查看java垃圾收集器 ，jmap -heap pid

    其中 using thread-local object allocation下面就是采用的java垃圾收集器

   下图事例中为：Concurrent Mark-Sweep GC

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

[root@iZ2zeapchxZ tomcat7]# jmap -heap 13297 Attaching to process ID 13297, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25.77-b03   using parallel threads in the new generation. using thread-local object allocation. Concurrent Mark-Sweep GC   Heap Configuration:    MinHeapFreeRatio         = 40    MaxHeapFreeRatio         = 70    MaxHeapSize              = 1073741824 (1024.0MB)    NewSize                  = 87228416 (83.1875MB)    MaxNewSize               = 87228416 (83.1875MB)    OldSize                  = 986513408 (940.8125MB)    NewRatio                 = 2    SurvivorRatio            = 8    MetaspaceSize            = 21807104 (20.796875MB)    CompressedClassSpaceSize = 1073741824 (1024.0MB)    MaxMetaspaceSize         = 17592186044415 MB    G1HeapRegionSize         = 0 (0.0MB)   Heap Usage: New Generation (Eden + 1 Survivor Space):    capacity = 78512128 (74.875MB)    used     = 17016048 (16.227767944335938MB)    free     = 61496080 (58.64723205566406MB)    21.673145835507096% used Eden Space:    capacity = 69795840 (66.5625MB)    used     = 10923608 (10.417564392089844MB)    free     = 58872232 (56.144935607910156MB)    15.650800964642018% used From Space:    capacity = 8716288 (8.3125MB)    used     = 6092440 (5.810203552246094MB)    free     = 2623848 (2.5022964477539062MB)    69.89718559093045% used To Space:    capacity = 8716288 (8.3125MB)    used     = 0 (0.0MB)    free     = 8716288 (8.3125MB)    0.0% used concurrent mark-sweep generation:    capacity = 986513408 (940.8125MB)    used     = 41311272 (39.397499084472656MB)    free     = 945202136 (901.4150009155273MB)    4.187603702594583% used   19916 interned Strings occupying 2422360 bytes.

Concurrent Mark-Sweep GC ：CMS回收器

Mark Sweep Compact GC：    串行GC（Serial GC）

Parallel GC with 2 thread(s)： 并行GC（ParNew）

如何修改GC回收器： 设置 JAVA_OPTS

三、jstack命令查看栈情况

jstack -l  6257  > scanner_debug.txt

强制打印进程的栈信息

1、介绍

　　jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息，如果是在64位机器上，需要指定选项"-J-d64"，Windows的jstack使用方式只支持以下的这种方式：

jstack [-l] pid

如果java程序崩溃生成core文件，jstack工具可以用来获得core文件的java stack和native stack的信息，从而可以轻松地知道java程序是如何崩溃和在程序何处发生问题。另外，jstack工具还可以附属到正在运行的java程序中，看到当时运行的java程序的java stack和native stack的信息, 如果现在运行的java程序呈现hung的状态，jstack是非常有用的。

2、命令格式
jstack [ option ] pid
jstack [ option ] executable core
jstack [ option ] [server-id@]remote-hostname-or-IP

3、常用参数说明

1)、options： 

executable Java executable from which the core dump was produced.

(可能是产生core dump的java可执行程序)

core 将被打印信息的core dump文件

remote-hostname-or-IP 远程debug服务的主机名或ip

server-id 唯一id,假如一台主机上多个远程debug服务 

2）、基本参数：

-F当’jstack [-l] pid’没有相应的时候强制打印栈信息

-l长列表. 打印关于锁的附加信息,例如属于java.util.concurrent的ownable synchronizers列表.

-m打印java和native c/c++框架的所有栈信息.

-h | -help打印帮助信息

pid 需要被打印配置信息的java进程id,可以用jps查询.

 

四、jstat查看垃圾回收情况

jstat -gcutil 3034

https://blog.csdn.net/fenglibing/article/details/6411951

列名	说明
S0	Heap上的 Survivor space 0 区已使用空间的百分比
S1	Heap上的 Survivor space 1 区已使用空间的百分比
E	Heap上的 Eden space 区已使用空间的百分比
O	Heap上的 Old space 区已使用空间的百分比
P	Perm space 区已使用空间的百分比
YGC	从应用程序启动到采样时发生 Young GC 的次数
YGCT	从应用程序启动到采样时 Young GC 所用的时间(单位秒)
FGC	从应用程序启动到采样时发生 Full GC 的次数
FGCT	从应用程序启动到采样时 Full GC 所用的时间(单位秒)
GCT	从应用程序启动到采样时用于垃圾回收的总时间(单位秒)，它的值等于YGC+FGC

看fullgc的次数、时间是否异常，若异常可能是内存泄漏。