Java虚拟机监控命令
熟悉java的人都知道jdk的bin目录中有很多小工具,其中就包括用于监视虚拟机和故障处理的工具,今天就来仔细了解下各个工具的用法
jps
JVM Process Status Tool,用于显示指定系统的内所有的Hotapot的虚拟机进程
1.用法
jps [options] [hostid]
2.参数列表
q:只输出LVMID,省略主类的名称 m:输出虚拟机进程启动时传递给主类main()函数的参数 l:输出主类的全名。若进程执行的是jar包,则输出jar路径 v:输出虚拟机进程启动时JVM参数
3.实际举例:
1. jps -q :只输出LVMID,省略主类的名称
2. jps -m:输出虚拟机进程启动时传递给主类main()函数的参数
3.jps -l:输出主类的全名。若进程执行的是jar包,则输出jar路径
4.jps -v:输出虚拟机进程启动时JVM参数
5.参数 vl一起:这样我们就能很方便的查看各个程序设定的参数了
jstat
Java Statisstic Monitoring Tool :一个极强的监视VM内存工具。可以用来监视VM内存内的各种堆和非堆的大小及其内存使用量
1.用法
jstat [Options] vmid [interval] [count]
Options,选项,我们一般使用 -gcutil 查看gc情况
vmid,VM的进程号,即当前运行的java进程号
interval,间隔时间,单位为秒或者毫秒
count,打印次数,如果缺省则打印无数次
2.参数列表
jstat -class pid:显示加载class的数量,及所占空间等信息。 jstat -compiler pid:显示VM实时编译的数量等信息。 jstat -gc pid:可以显示gc的信息,查看gc的次数,及时间。其中最后五项,分别是young gc的次数,young gc的时间,full gc的次数,full gc的时间,gc的总时间。 jstat -gccapacity:可以显示,VM内存中三代(young,old,perm)对象的使用和占用大小,如:PGCMN显示的是最小perm的内存使用量,PGCMX显示的是perm的内存最大使用量,PGC是当前新生成的perm内存占用量,PC是但前perm内存占用量。其他的可以根据这个类推, OC是old内纯的占用量。 jstat -gcnew pid:new对象的信息。 jstat -gcnewcapacity pid:new对象的信息及其占用量。 jstat -gcold pid:old对象的信息。 jstat -gcoldcapacity pid:old对象的信息及其占用量。 jstat -gcpermcapacity pid: perm对象的信息及其占用量。 jstat -util pid:统计gc信息统计。 jstat -printcompilation pid:当前VM执行的信息。 除了以上一个参数外,还可以同时加上 两个数字,如:jstat -printcompilation 3024 250 6是每250毫秒打印一次,一共打印6次,还可以加上-h3每三行显示一下标题。
3.实际举例
1. -gc:监视java堆状况
S0C:年轻代中第一个survivor(幸存区)的容量 (字节) S1C:年轻代中第二个survivor(幸存区)的容量 (字节) S0U:年轻代中第一个survivor(幸存区)目前已使用空间 (字节) S1U:年轻代中第二个survivor(幸存区)目前已使用空间 (字节) EC:年轻代中Eden的容量 (字节) EU:年轻代中Eden目前已使用空间 (字节) OC:Old代的容量 (字节) OU:Old代目前已使用空间 (字节) PC:Perm(持久代)的容量 (字节) PU:Perm(持久代)目前已使用空间 (字节) YGC:从应用程序启动到采样时年轻代中gc次数
2.-gcutil:与-gc基本相同,但输出的是已使用空间占总空间的大小
jinfo
Configuration Info for Java:实时的查看和调整虚拟机各项参数
1.用法:
jinfo [option] <pid>
2.参数:
jinfo 主要就是flag参数了,上图已经解释的很清楚了,这里直接做演示好了
3.实际举例
1.获取进程30018的SurvivorRatio信息
2.获取进程30018 所有的jvm信息
这个命令比jps -v更加详细
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)或与jhat (Java Heap Analysis Tool)一起使用, 能够以图像的形式直观的展示当前内存是否有问题。
1.用法
jmap [option] <pid>
2.参数
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
3.实际举例
1.jmap -heap 打印heap的概要信息,GC使用的算法,heap的配置及wise heap的使用情况.
Heap Configuration: //堆内存初始化配置 MinHeapFreeRatio = 0 //对应jvm启动参数-XX:MinHeapFreeRatio设置JVM堆最小空闲比率(default 40) MaxHeapFreeRatio = 100 //对应jvm启动参数 -XX:MaxHeapFreeRatio设置JVM堆最大空闲比率(default 70) MaxHeapSize = 2082471936 (1986.0MB) //对应jvm启动参数-XX:MaxHeapSize=设置JVM堆的最大大小 NewSize = 1310720 (1.25MB)//对应jvm启动参数-XX:NewSize=设置JVM堆的‘新生代’的默认大小 MaxNewSize = 17592186044415 MB//对应jvm启动参数-XX:MaxNewSize=设置JVM堆的‘新生代’的最大大小 OldSize = 5439488 (5.1875MB)//对应jvm启动参数-XX:OldSize=<value>:设置JVM堆的‘老生代’的大小 NewRatio = 2 //对应jvm启动参数-XX:NewRatio=:‘新生代’和‘老生代’的大小比率 SurvivorRatio = 8 //对应jvm启动参数-XX:SurvivorRatio=设置年轻代中Eden区与Survivor区的大小比值 PermSize = 21757952 (20.75MB) //对应jvm启动参数-XX:PermSize=<value>:设置JVM堆的‘永生代’的初始大小 MaxPermSize = 85983232 (82.0MB)//对应jvm启动参数-XX:MaxPermSize=<value>:设置JVM堆的‘永生代’的最大大小 G1HeapRegionSize = 0 (0.0MB) Heap Usage://堆内存使用情况 PS Young Generation Eden Space://Eden区内存分布 capacity = 33030144 (31.5MB)//Eden区总容量 used = 1524040 (1.4534378051757812MB) //Eden区已使用 free = 31506104 (30.04656219482422MB) //Eden区剩余容量 4.614088270399305% used //Eden区使用比率 From Space: //其中一个Survivor区的内存分布 capacity = 5242880 (5.0MB) used = 0 (0.0MB) free = 5242880 (5.0MB) 0.0% used To Space: //另一个Survivor区的内存分布 capacity = 5242880 (5.0MB) used = 0 (0.0MB) free = 5242880 (5.0MB) 0.0% used PS Old Generation //当前的Old区内存分布 capacity = 86507520 (82.5MB) used = 0 (0.0MB) free = 86507520 (82.5MB) 0.0% used PS Perm Generation//当前的 “永生代” 内存分布 capacity = 22020096 (21.0MB) used = 2496528 (2.3808746337890625MB) free = 19523568 (18.619125366210938MB) 11.337498256138392% used
这个命令非常直观的显示了JVM各个区域的生存情况,线上内存出现异常可以先用这个命令做一个大致的了解
2.jmap -histo:
这个命令会把所有的类都打出来,并按占用内存的大小进行排序
jmap -histo:live 10765 | more
加上live参数只会打印存活的对象
3.jmap -dump:
解释下 jmap -F -dump:format=b,file=payment.bin 30018: 使用hprof二进制形式,输出进程为30018的jvm的heap内容到文件payment.bin
jhat
是用来分析java堆的命令,可以将堆中的对象以html的形式显示出来,包括对象的数量,大小等等,并支持对象查询语言
我们现在来分析下上文产生的payment.bin
用浏览器访问http://localhost:7000/,会发现所有的类按包名进行分类,我们可以访问底部的这个标签,看到的内容和jmap -histo:是一样的
jstack
用于生成java虚拟机当前时刻的线程快照
1.用法
jstack [-l] <pid>
2.参数
3.用法
获取到各个线程的状态后,主要有以下几个注意点
死锁, Deadlock(重点关注):死锁线程,一般指多个线程调用间,进入相互资源占用,导致一直等待无法释放的情况。 执行中,Runnable 等待资源, Waiting on condition(重点关注) :
该状态出现在线程等待某个条件的发生。具体是什么原因,可以结合 stacktrace来分析。最常见的情况是线程在等待网络的读写,比如当网络数据没有准备好读时,线程处于这种等待状态,而一旦有数据准备好读之后,线程会重新激活,读取并处理数据。在 Java引入 NewIO之前,对于每个网络连接,都有一个对应的线程来处理网络的读写操作,即使没有可读写的数据,线程仍然阻塞在读写操作上,这样有可能造成资源浪费,而且给操作系统的线程调度也带来压力。在 NewIO里采用了新的机制,编写的服务器程序的性能和可扩展性都得到提高。如果发现有大量的线程都在处在 Wait on condition,从线程 stack看, 正等待网络读写,这可能是一个网络瓶颈的征兆。因为网络阻塞导致线程无法执行。一种情况是网络非常忙,几 乎消耗了所有的带宽,仍然有大量数据等待网络读 写;另一种情况也可能是网络空闲,但由于路由等问题,导致包无法正常的到达。所以要结合系统的一些性能观察工具来综合分析,比如 netstat统计单位时间的发送包的数目,如果很明显超过了所在网络带宽的限制 ; 观察 cpu的利用率,如果系统态的 CPU时间,相对于用户态的 CPU时间比例较高;如果程序运行在 Solaris 10平台上,可以用 dtrace工具看系统调用的情况,如果观察到 read/write的系统调用的次数或者运行时间遥遥领先;这些都指向由于网络带宽所限导致的网络瓶颈。另外一种出现 Wait on condition的常见情况是该线程在 sleep,等待 sleep的时间到了时候,将被唤醒。
等待获取监视器, Waiting on monitor entry(重点关注) 暂停,Suspended 对象等待中,Object.wait() 或 TIMED_WAITING 阻塞, Blocked(重点关注) 停止,Parked
参考
http://www.cnblogs.com/ggjucheng/archive/2013/04/16/3024986.html
http://blog.csdn.net/zlzlei/article/details/46471627
http://www.ccblog.cn/84.htm