JVM调优系列：（五）JVM常用调试参数和工具

转自：http://blog.csdn.net/opensure/article/details/46715769

JVM常用调试参数:

–verbose:gc在虚拟机发生内存回收时在输出设备显示信息

-Xloggc:filename把GC相关日志信息记录到文件以便分析

-XX:-HeapDumpOnOutOfMemoryError当首次遭遇OOM时导出此时堆中相关信息

-XX:OnError="<cmdargs>;<cmd args>" 出现致命ERROR之后运行自定义命令

-XX:-PrintClassHistogram遇到Ctrl-Break后打印类实例的柱状信息，与jmap -histo功能相同

-XX:-PrintConcurrentLocks遇到Ctrl-Break后打印并发锁的相关信息，与jstack -l功能相同

-XX:-PrintGC每次GC时打印相关信息

-XX:-PrintGCDetails每次GC时打印详细信息

-XX:-PrintGCTimeStamps打印每次GC的时间戳

-XX:+PrintGCApplicationStoppedTime打印垃圾回收期间程序暂停的时间

-XX:+PrintHeapAtGC打印GC前后的详细堆栈信息

-XX:+PrintTenuringDistribution查看每次minor GC后新的存活周期的阈值,即在年轻代survivor中的复制次数.

-XX:-TraceClassLoading跟踪类的加载信息

-XX:-TraceClassUnloading跟踪类的卸载信息

-XX:-TraceLoaderConstraints跟踪类加载器约束的相关信息

-XX:ErrorFile=/opt/tomcat/bin/hs_error_%p.log  Crash日志

[GC [DefNew:209792K->4417K(235968K), 0.0201630 secs] 246722K->41347K(498112K),0.0204050 secs]

YoungGen内存区回收前209792K，回收后4417K, YoungGen大小是235968K, HEAP 内存区回收前246722K, 回收后41347K, heap的大小是498112K,GC消耗的时间是0.0204050 secs

[GC [1 CMS-initial-mark: 655374K(1310720K)] 662197K(1546688K), 0.0303050 secs] [Times: user=0.02 sys=0.02, real=0.03 secs]

[weak refs processing, 0.0417710 secs] [1 CMS-remark: 655734K(1310720K)] 766736K(1546688K), 0.0932010 secs] [Times: user=0.17 sys=0.00, real=0.09 secs]

CMS-initial-mark阶段暂停了0.0303050秒，而CMS-remark阶段暂停了0.0932010秒，因此两次暂停的总共时间是0.123506秒.

两种fail引起full gc：Prommotionfailed和Concurrent mode failed:

[ParNew (promotion failed): 320138K->320138K(353920K), 0.2365970 secs]

[CMS: 1458785K->1120688K(2520704K), 9.4584090 secs]

Prommotion failed由于救助空间不够，从而向年老代转移对象，年老代没有足够的空间来容纳这些对象; 或者老生代空闲空间存在碎片，导致没有足够大的连续空间开存放新生代对，导致一次fullgc的产生。解决这个问题的办法有两种完全相反的倾向：增大救助空间、增大年老代。调整-XX:SurvivorRatio参数

Concurrent mode failed的产生是由于CMS回收年老代的速度太慢，导致年老代在CMS完成前就被沾满，引起full gc，避免这个现象的产生就是调小-XX:CMSInitiatingOccupancyFraction参数的值.

java.lang.OutOfMemoryError:GC overhead limit exceeded:

JDK6新添的错误类型。是发生在GC占用大量时间为释放很小空间的时候发生的，是一种保护机制。解决方案是，关闭该功能，使用-XX:-UseGCOverheadLimit. 需要查看是否有使用大内存的代码或死循环。

JVM常用调试工具:

jconsole – jconsole是基于JavaManagementExtensions (JMX)的实时图形化监测工具，这个工具利用了内建到JVM里面的JMX指令来提供实时的性能和资源的监控，包括了Java程序的内存使用，Heap size, 线程的状态，类的分配状态和空间使用等等。Linux下设置环境变量如下：export DISPLAY=:0.0

jstatd–启动jvm监控服务。它是一个基于rmi的应用，向远程机器提供本机jvm应用程序的信息。默认端口1099。

-nr 当一个存在的RMI Registry没有找到时，不尝试创建一个内部的RMI Registry

-p port 端口号，默认为1099

-nrminame 默认为JStatRemoteHost；如果多个jstatd服务开始在同一台主机上，rminame唯一确定一个jstatd服务

-J jvm选项

$JAVA_HOME/jre/lib/security/java.policy文件中添加下面的代码：

grantcodebase "file:${java.home}/../lib/tools.jar" {

permission java.security.AllPermission;

};

默认端口为1099:   jstatd -J-Djava.security.policy=jstatd.all.policy

指定hostname 指定端口: jstatd -J-Djava.rmi.server.hostname=192.168.8.7-J-Djava.security.policy=test/jstatd.all.policy -p 6001

启动JMX: jstatd -J-Djava.rmi.server.hostname=192.168.8.7-J-Djava.security.policy=test/jstatd.all.policy  -J-Dcom.sun.management.jmxremote.port=6001 -J-Dcom.sun.management.jmxremote.ssl=false-J-Dcom.sun.management.jmxremote.authenticate=false -J -Djava.awt.headless=true

(java.net.MalformedURLException:Local host name unknown: java.net.UnknownHostException: a: a

原因是/etc/hosts文件里没有主机名为：a的，解决方法就是在hosts文件中加入a:

127.0.0.1   a   localhost)

 

jps –jps是用来查看JVM里面所有进程的具体状态, 包括进程ID，进程启动的路径等等。

-m 输出传递给main方法的参数，如果是内嵌的JVM则输出为null。

-l 输出应用程序主类的完整包名，或者是应用程序JAR文件的完整路径。

-v 输出传给JVM的参数。

 

jstack -- jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息，如果是在64位机器上，需要指定选项"-J-d64",如果java程序崩溃生成core文件，jstack工具可以用来获得core文件的java stack和nativestack的信息。Windows的jstack只支持-l.

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

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

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

Jstackpid  显示jvm中当前所有线程的运行情况和线程当前状态

jinfo –可以输出并修改运行时的java 进程的opts。用处比较简单，用于输出JAVA系统参数及命令行参数。查看和修改运行中的java程序的运行环境参数。

jinfo-flag MaxPermSize  4084

jmap –jmap 可以从core文件或进程中获得内存的具体匹配情况，包括Heap size, Perm size等等，打印出某个java进程（使用pid）内存内的，所有‘对象’的情况。

-heap ：打印jvm heap的情况
-histo： 打印jvm heap的直方图。其输出信息包括类名，对象数量，对象占用大小。
-histo：live ： 同上，但是只输出存活对象的情况,会触发FULL GC

-permstat： 打印permanentgeneration heap情况

jmap-dump:format=b,file=outfile 3024可以将3024进程的内存heap输出出来到outfile文件里，再配合JHAT进行分析.

Jhat用于对JAVA heap进行离线分析的工具，他可以对不同虚拟机中导出的heap信息文件进行分析，如LINUX上导出的文件可以拿到WINDOWS上进行分析

jhat -J-Xmx512m <heap dump file>

jstat – jstat利用了JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控, 可以观察到classloader，compiler，gc相关信息，包括了对Heap size和垃圾回收状况的监控等等。

-class：统计class loader行为信息
-compile：统计编译行为信息
-gc：统计jdk gc时heap信息
-gccapacity：统计不同的generations（不知道怎么翻译好，包括新生区，老年区，permanent区）相应的heap容量情况
-gccause：统计gc的情况，（同-gcutil）和引起gc的事件
-gcnew：统计gc时，新生代的情况
-gcnewcapacity：统计gc时，新生代heap容量
-gcold：统计gc时，老年区的情况
-gcoldcapacity：统计gc时，老年区heap容量
-gcpermcapacity：统计gc时，permanent区heap容量
-gcutil：统计gc时，heap情况

-compiler:显示VM实时编译的数量等信息

-snap: 查看Java进程的jvmstat的各个monitor的值

jstat-gc PID@172.30.0.160

java-verbose:class PID输出虚拟机装入的类的信息, 当虚拟机报告类找不到或类冲突时可用此参数来诊断来查看虚拟机从装入类的情况。

java –verbose:jni输出native方法调用的相关情况，一般用于诊断jni调用错误信息

常用JVM分析信息获取:

1、确认服务器上是否存在SUN JDK6，如果没有建议安装一个，我们需要使用里面的工具（jps、jmap、jstat、jconsole、jstack）

2、 获取MKEY的JAVA进程ID（后面简称PID）

a)   操作方法：进入SUN JDK的bin目录在命令行中输入jps，查看MKEY的进程ID

3、提取GC信息()

a)   操作方法：示例：jstat –gcPID 600000 43200 >> gc_20110909.log

4、 提取Heap区信息（间隔10分钟提取一次）

a)   操作方法：jmap -heap PID >>heap_20110909.log

5、提取对象信息（间隔10分钟提取一次）

a)      操作方法：jmap-histo PID > histo_*.log(文件较大,*按序号生成输入)

6、线程转储日志

a)      jstack PID

b)      宕机日志(在domain目录,如果没有宕机,条件允许的情况下可使用 kill -3 PID(此操作会杀掉进程))

精简版:

服务器挂起后,在重启之前执行以下命令:

jps-vl 查询到相应的JAVA进程,简称PID

jstat –gcutilPID 5000 >> /opt/tomcat/bin/gcutil.log

vmstat3

jstackPID > /opt/tomcat/bin/jstack.log

jmap-histo PID > /opt/tomcat/bin/histo.log

网络方面:

whiletrue; do A=$(netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a,S[a]}'); echo $A ; sleep 3; done

netstat -an | grep1521

再重启服务.提取相关日志发出来