【2015工作总结】JVM监控总结

wangchen.ily

浏览: 126441 次
性别:
来自: 北京

最近访客更多访客>>

chenminghui1103

javahan

wangyy

youyanweixiao

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

性能
面试

一。讲解JVM结构

其中，

新生代是Heap，包括Eden(伊甸园)+S0(幸存0)+S1(幸存1)：新建对象都存储在这里。配置参数是Xms。

老生代是Old，存放从新生代迁移过来的生命周期较久的对象。新生代和老生代共同组成了堆内存。配置参数是Xmx减去Xmn。

永久代是Perm，是非堆内存的组成部分。存放加载的Class类级对象如class本身，method，field等。

二。一般程序内存溢出分析：

如果出现java.lang.OutOfMemoryError: Java heap space异常，说明Java虚拟机的堆内存不够。原因有二：

（1）Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整。

（2）代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）。

如果出现java.lang.OutOfMemoryError: PermGen space，说明是Java虚拟机对永久代Perm内存设置不够。

一般出现这种情况，都是程序启动需要加载大量的第三方jar包。例如：在一个Tomcat下部署了太多的应用。

三。具体JVM监控方法：

使用JDK1.7自带的jvisualvm.exe工具，文件路径：..\Java\jdk1.7.0_67\bin\jvisualvm.exe

需要操作以下几个步骤：

3.1修改服务器tomcat的catalina.sh，路径是.../tomcat/bin/catalina.sh（黄色是添加的）

JAVA_OPTS="$JAVA_OPTS  -server -Xms${xms_size} -Xmx${xmx_size}  -XX:PermSize=512m -XX:MaxNewSize=1024m -XX:MaxPermSize=512m -Djava.awt.headless=true -Dfile.encoding=utf-8 -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=19999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"

3.2添加服务器的应用列表

先创建一个java.policy文件：

grant codebase "file:${java.home}/../lib/tools.jar" {  
   permission java.security.AllPermission;  
};

放在服务器某个位置，比如我放在JDK1.7的bin路径下，进入对应路径，执行以下命令：

jstatd -J-Djava.security.policy=java.policy -J-Djava.rmi.server.logCalls=true

3.3然后在本地打开jvisualvm.exe，安装完GC插件，就可以看到某个端口的应用JVM监控了。

四。简单介绍JVM的其他知识：

4.1 高并发下 JVM占用TOP100 （假设进程号19771）：jmap -histo:live 19771 | head -n 100

开发可以从中分析哪些代码存在不断实例，不断增大，且没有释放的问题。

4.2 内存申请过程

4.2.1 JVM会试图为相关Java对象在Eden中初始化一块内存区域；

4.2.2当Eden空间足够时，内存申请结束。否则到下一步；

4.2.3JVM试图释放在Eden中所有不活跃的对象（minor collection），释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区；

4.2.4.Survivor区被用来作为Eden及old的中间交换区域，当OLD区空间足够时，Survivor区的对象会被移到Old区，否则会被保留在Survivor区；

4.2.5当old区空间不够时，JVM会在old区进行major collection；

4.2.6完全垃圾收集后，若Survivor及old区仍然无法存放从Eden复制过来的部分对象，导致JVM无法在Eden区为新对象创建内存区域，则出现"Out of memory错误"。

4.3 GC

JVM有2个GC线程：

第一个线程负责回收Heap的新生代区

第二个线程在Heap不足时，遍历Heap，将新生代区升级为老生代区

堆内存GC：JVM(采用分代回收的策略)，用较高的频率对年轻的对象(young generation)进行YGC，而对老对象(tenured generation)较少(tenured generation 满了后才进行)进行Full GC。这样就不需要每次GC都将内存中所有对象都检查一遍。

非堆内存不GC：GC不会在主程序运行期对PermGen Space进行清理，所以如果你的应用中有很多CLASS(特别是动态生成类，当然permgen space存放的内容不仅限于类)的话,就很可能出现PermGen Space错误。

监视JVM GC：可以用JDK中的jstat工具，也可以在java程序启动的opt里加上如下几个参数（注:这两个参数只针对SUN的HotSpotVM）

[java] view plaincopy
-XX:-PrintGCPrintmessagesatgarbagecollection.Manageable.    
-XX:-PrintGCDetailsPrintmoredetailsatgarbagecollection.Manageable.(Introducedin1.4.0.)    
-XX:-PrintGCTimeStampsPrinttimestampsatgarbagecollection.Manageable(Introducedin1.4.0.)   
[java] view plain copy
-XX:-PrintGCPrintmessagesatgarbagecollection.Manageable.    
-XX:-PrintGCDetailsPrintmoredetailsatgarbagecollection.Manageable.(Introducedin1.4.0.)    
-XX:-PrintGCTimeStampsPrinttimestampsatgarbagecollection.Manageable(Introducedin1.4.0.)

当把-XX:-PrintGCDetails加入到javaopt里以后可以看见如下输出：

[GC[DefNew:34538K->2311K(36352K),0.0232439secs]45898K->15874K(520320K),0.0233874secs]

[FullGC[Tenured:13563K->15402K(483968K),0.2368177secs]21163K->15402K(520320K),[Perm:28671K->28635K(28672K)],0.2371537secs]

他们分别显示了JVM GC的过程，清理出了多少空间。第一行GC使用的是‘普通GC’(MinorCollections)，第二行使用的是‘全GC’(MajorCollections)。他们的区别很大，在第一行最后我们可以看见他的时间是0.0233874秒，而第二行的FullGC的时间是0.2371537秒。第二行的时间是第一行的接近10倍，也就是我们这次调优的重点，减少FullGC的次数，以为FullGC会暂停程序比较长的时间，如果FullGC的次数比较多。程序就会经常性的假死。