jvm 命令使用调优 经过jstat、jmap对java程序进行性能调优

转载：http://blog.csdn.net/jerry024/article/details/8507589

转载： https://blog.csdn.net/zhaozheng7758/article/details/8623530

 

经过jstat、jmap对java程序进行性能调优

2013年01月16日 12:54:12 jerry在魔都 阅读数 1207

 

第一次写技术博客，本文记录了我对服务器cpu占用率100%问题的排查过程和最终结果，算是一篇学习日志。

 

本人属于学习中的菜鸟码农，若有什么理解上的误差的，还请各路大神指正。

 

关键词：

jstat , jmap, heap, GC, smartupload, 内存泄漏

 

1. 背景

硬件供应商屡次反映，在tomcat启动一段时间后，常常出现cpu占用率100%，且重启前一直保持在100%的状况。在重启后cpu占用率回落，可是一段时间后再次出现问题。

下图为cpu占用率100%时使用top命令的截图，能够看到java进程的cpu占用率几经几乎达到了400%（服务器为4核cpu）

 

<1>

2.问题定位

2.1问题猜想

对于cpu占用率100%的状况，产生如下两种猜想：

a. 程序长时间占用系统IO，致使CPU占用率100%

b.程序存在严重内存泄露，致使jvm频繁执行full GC，从而使cpu占用率提升，形成服务器假死

 

2.2jvm的内存管理和垃圾回收机制

java对内存的管理主要分为两种：栈（stack）和堆（heap） 方法区，程序计数器等不作讨论

 

stack: 在每一个线程启动时由jvm自动分配固定大小的地址，stack内主要保存操做符，值对象(int,float等基础数据类型)，和引用对象的指针因为stack固定大小，且主要操做为push和pop，并不涉及到垃圾回收等问题，所以不作展开。

heap:堆在线程执行过程当中自动分配大小，大小能够随时改变，主要用于保存对象(Object),对象在结束生命周期结束以后便会由JVM的垃圾回收机制自动进行回收堆可分为3大部分年轻代(Young Generation)、年老代(Old Generation)和持久代(Permanent Generation)。

年轻代：年轻代又可分为3个小区：Eden，两个等大的Survior区(from 和 to)。其中Eden主要存放新建的对象，当Eden区没法再存放更多的对象时，jvm会发起年轻代GC(Minor GC),释放Eden中的对象，Minor GC的特色是发生频率高，执行速度也极快，对系统效率的影响并非很大。当Eden区中的对象通过一次Minor GC仍然没有被释放时，这部分对象将被移入Survior区(对象可能进入from区，也可能进入to区，有具体算法，此处不作展开)。当Survior区中的对象经历过数次的Minor GC以后仍然存活，将被移入年老代。

年老代：年老代中用来存放从年轻代过来的长时间使用的对象，大部分的JVM内存溢出错误均发生在这个区域。当年老代被过分占用，没法存放下更多的数据时，jvm会发起一次年老代GC(Major GC\Full GC),该类型GC会释放年老代中的资源，虽然该GC触发频率很低，可是对硬件资源的消耗较高，且Full GC过程当中会暂停该线程的执行。若是系统中存在内存泄露，频繁的触发Full GC,将会严重的占用服务器资源，形成应用的假死，这也是我以前猜想b的依据。

 

持久代：持久代中用于存放jvm的反射类等，如class等，此区域对GC的影响不大，也不大会发生内存溢出的状况。

 

下图是引用网上的一张图片，更形象的描述了heap区的构成

<2>

 

2.3jstat、jmap实战

ok，在弄清楚jvm的GC机制以后，就有了努力的方向了，为了弄清楚GC具体的工做状况，就要使用到jstat命令了。

jstat(Java Virtual Machine Statistics Monitoring Tool)是jdk自带的监控工具，位置在%JAVA_HOME%/bin 下,命令使用方法为

 jstat [ generalOption | outputOptions vmid [interval[s|ms] [count]] ]

下图是我对系统中tomcat进程的监控状况

<3>

<4>

命令中 -gcutil表示统计GC状况，5125为tomcat的pid,10000表示没10s统计一次，5表示一共统计5次

结果中s0为from区，s1为to区，E为Eden区，O为Old区，P为Permanent区，YGC为yong GC次数，YGCT为yong GC执行的总时间，FGC为Full GC次数，FGCT为Full GC总时间，GCT为GC总时间。

上面图<3>为cpu占用率高时的截图，图<4>为正常状况下截图。

很明显的看到GC次数相差不大的状况下，GC耗时存在很大的差距，推测此时系统中可能存在内存泄漏的状况。

 

为了肯定jvm中具体有哪些生存的对象，就须要用到jdk自带的另外一个监控工具，jmap了

jmap(Memory Map)用于监控系统内存中存活的对象。

使用命令: jmap -histo:live 5125>> /opt/jmap.txt  

其中5125为pid ，因为数据较多，将数据保存在txt文件中进行分析，下图列出了对内存占用排名前几的对象

<5>

一眼看去，String对象稳居第一，好吧，项目中对String的处理确实有很多问题，可是，排名第三的这是什么东西？！

在代码中一查，这个对象只在一个上传文件中的Servlet中被用到了一次，很明显的内存泄漏！

 

3.问题解决

很明显，jspsmart这个插件正是内存泄漏的元凶，网上查找资料以后肯定，jspsmart因为自身bug，在长时间运行后会产生两个严重问题：

a. 客户端在未完成上传时便主动终止了上传操做，此时客户端再也不上传文件，可是服务端仍然会占用InputStream，而且不会主动释放，形成cpu占用率100%，猜想a证明

b. 客户上传的文件损坏，在建立File对象时没法找到文件终止标识，所以一直在建立新的File对象，形成内存泄漏。

 

由此，服务器内存溢出和cpu占用率100%两个问题都找到了关键所在，接下来的工做就像对简单了，使用apache的开源项目commons-upload替换原来的jspsmart来完成文件上传的工做，替换事后，系统资源占用正常，附上bug修复后的jmap截图

<6>