【JVM命令及问题排查】

栏目: Java · 发布时间: 6年前

java中的gc log解读

eclipse的优化 gc.log

一次让人难以忘怀的排查频繁Full GC过程

一个GC频繁的Case

堆内存占用很小 但是 JVM 频繁full gc 问题排查

JVM中GC时,堆内存是如何动态变化的(JDK1.7)

使用jmap和MAT分析JVM堆内存

Jmap+MAT 排查内存泄漏

关于内存溢出

Young(Nursery) :年轻代

Old(Tenured) :年老代

Permanent(Perm) :持久代

装载Class信息等基础数据

堆设置 

-Xms:初始堆大小 ,默认是物理内存的1/64

-Xmx:最大堆大小 

-Xmn:年轻代大小

-Xss:jvm启动的每个线程分配的内存大小

-XX:NewSize=n:设置年轻代大小 

-XX:PermSize=64m设置持久代大小

-XX:MaxPermSize=n:设置持久代最大大小

MaxPermSize过小会导致:java.lang.OutOfMemoryError: PermGen space

-XX:NewRatio=n:设置年轻代和年老代的比值。如:为3,表示年轻代与年老代比值为1:3,年轻代占整个年轻代年老代和的1/4 

-XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如:3,表示Eden:Survivor=3:2,一个Survivor区占整个年轻代的1/5 

-XX:MaxTenuringThreshold 

如果设置为0的话,则年轻代对象不经过Survivor区,直接进入年老代。对于年老代比较多的应用,可以提高效率。如果将此值设置为一个较大值,则年轻代对象会在Survivor区进行多次复制,这样可以增加对象再年轻代的存活时间,增加在年轻代即被回收的概论。

-Xmx512m: (max)堆最大可用内存为512M。

-Xms512m: (small)堆最小内存为512m。

此值可以设置与-Xmx最大值相同,以避免每次垃圾回收完成后JVM动态调节 Java 堆大小而耗费延长其周期。 

-Xmn192m :(new)设置年轻代大小为192m。

整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m,所以增大年轻代后,将会减小年老代大小。此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。

垃圾回收统计信息 

-XX:+PrintGC 

-XX:+PrintGCDetails 

-XX:+PrintGCTimeStamps 

-Xloggc:filename

-XX:+PrintGC 

输出形式:[GC 118250K->113543K(130112K), 0.0094143 secs] 

[Full GC 121376K->10414K(130112K), 0.0650971 secs]

-XX:+PrintGCDetails 

输出形式:[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs] 

[GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]

-XX:+PrintGCTimeStamps -XX:+PrintGC:PrintGCTimeStamps可与上面两个混合使用 

输出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]

默认java程序是不会开启gc log

对于生产环境下的java程序可以加上来生成gc log,方便出现问题的时候去排查

-verbose:gc -Xloggc:/usr/gclog -XX:+PrintGCDetails XX:+PrintGCTimeStamps

收集器设置 

-XX:+UseSerialGC:设置串行收集器 

-XX:+UseParallelGC:设置并行收集器 

-XX:+UseParalledlOldGC:设置并行年老代收集器 

-XX:+UseConcMarkSweepGC:设置并发收集器

-XX:+DisableExplicitGC这个将会忽略手动调用GC的代码使得 System.gc()的调用就会变成一个空调用,完全不会触发任何GC。

======================================================================

java中的gc log解读

https://my.oschina.net/hadooper/blog/418918

eclipse的优化 gc.log

https://blog.csdn.net/z69183787/article/details/39136119

默认java程序是不会开启gc log

对于生产环境下的java程序可以加上来生成gc log,方便出现问题的时候去排查

-verbose:gc -Xloggc:/usr/gclog -XX:+PrintGCDetails XX:+PrintGCTimeStamps

Linux如何开启tomcat的gc日志并查看

进入到了tomcat的bin的目录下中,命令中vi catalina.sh  来编辑

然后在该文件中cygwin=false上面

添加为

JAVA_OPTS="-Xms128m -Xmx256m -Xmn100m -XX:MaxPermSize=30m -Xloggc:/usr/local/tomcat/logs/gc.$$.log"

gc开启完成之后,只要启动了tomcat之后,就可目录下生成了gc的log的日志内容。

场景一:

[GC [DefNew: 3298K->149K (5504K) , 0.0053498 secs] 3298K->3221K( 9600K ), 0.0053750 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]

看一下这行:

DefNew表示新生态:3298K->149K(5504K), 0.0053498 secs

表示新生态由3298K回收变成了149K,即之前的3M回收了, 【5504K表示该区域的总内存大小】

3298K->3221K(9600K), 0.0053750 secs] 表示整个jvm堆的大小由于没有可以回收的对象,所以总大小本质没发生改变, 9600K是java的总堆大小9600K 。(虽然分配10M,其中还有持久态等其他内存区域)

[Times: user=0.00 sys=0.00, real=0.01 secs] 表示gc所花费的系统资源

场景二:

0.209: [GC 0.209: [DefNew: 4416K->511K( 4928K ), 0.0034707 secs] 4416K->614K(15872K), 0.0035239 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]  

6.383: [GC 6.383: [DefNew: 18880K->1985K( 21184K ), 0.0055311 secs] 46992K->30098K(68040K), 0.0055694 secs]

这6秒中GC日志打了69次, 而内存回收率还是蛮高的 young区18880-1985=16895 jvm 46992-30098=16894 都快接近100%了, 可以看出young区是由小到大在不断调整大小,所以不断GC,因此设一个初始值 吧,据说设置heap的1/4比较好,那就是 128M,所以eclipse.ini加入 

-Xmn128m

场景三:

103.759: [Full GC ( System ) 103.759: [Tenured: 81882K->66784K(393216K), 0.3287387 secs] 185350K->66784K(511232K), [Perm : 53464K->53414K(65536K)], 0.3287897 secs] [Times: user=0.33 sys=0.00, real=0.33 secs]

仔细观察日志,发现Full GC (System) 字样,这个意思是 eclipse里调用了System.gc()手动触发了系统GC ,在eclipse.ini里加入: 

-XX:+DisableExplicitGC

-XX:+DisableExplicitGC这个将会忽略手动调用GC的代码使得 System.gc()的调用就会变成一个空调用,完全不会触发任何GC。

======================================================================

关于内存溢出

https://blog.csdn.net/bbaiggey/article/details/50885943

第一类内存溢出,也是大家认为最多,第一反应认为是的内存溢出,就是堆栈溢出:

那什么样的情况就是堆栈溢出呢?当你看到下面的关键字的时候它就是堆栈溢出了:

java.lang.OutOfMemoryError: ......java heap space.....

也就是当你看到heap相关的时候就肯定是堆栈溢出了,此时如果代码没有问题的情况下, 适当调整-Xmx和-Xms是可以避免的 ,不过一定是代码没有问题的前提,为什么会溢出呢,要么代码有问题,要么访问量太多并且每个访问的时间太长或者数据太多,导致数据释放不掉,因为垃圾回收器是要找到那些是垃圾才能回收,这里它不会认为这些东西是垃圾,自然不会去回收了;主意这个溢出之前,可能系统会提前先报错关键字为:

java.lang.OutOfMemoryError:GC over head limit exceeded

这种情况是当系统处于高频的GC状态,而且回收的效果依然不佳的情况,就会开始报这个错误,这种情况一般是产生了很多不可以被释放的对象,有可能是引用使用不当导致,或申请大对象导致,但是java heap space的内存溢出有可能提前不会报这个错误,也就是可能内存就直接不够导致,而不是高频GC.

第二类内存溢出,PermGen的溢出,或者PermGen 满了的提示,你会看到这样的关键字:

关键信息为:

java.lang.OutOfMemoryError: PermGen space

原因:系统的代码非常多或引用的第三方包非常多、或 代码中使用了大量的常量、或通过intern注入常量、或者通过动态代码加载等方法,导致常量池的膨胀 ,虽然JDK 1.5以后可以通过设置对永久带进行回收,但是我们希望的是这个地方是不做GC的,它够用就行,所以一般情况下今年少做类似的操作,所以 在面对这种情况常用的手段是:增加-XX:PermSize和-XX:MaxPermSize的大小。

第三类内存溢出:在使用ByteBuffer中的allocateDirect()的时候会用到,很多javaNIO的框架中被封装为其他的方法

溢出关键字:

java.lang. OutOfMemoryError: Direct buffer memory

如果你在直接或间接使用了ByteBuffer中的allocateDirect方法的时候,而不做clear的时候就会出现类似的问题,常规的引用程序IO输出存在一个内核态与用户态的转换过程,也就是对应直接内存与非直接内存,如果常规的应用程序你要将一个文件的内容输出到客户端需要通过OS的直接内存转换拷贝到程序的非直接内存(也就是heap中),然后再输出到直接内存由操作系统发送出去,而直接内存就是由OS和应用程序共同管理的,而非直接内存可以直接由应用程序自己控制的内存,jvm垃圾回收不会回收掉直接内存这部分的内存,所以要注意了哦。

如果经常有类似的操作,可以考虑设置参数:-XX:MaxDirectMemorySize

第四类内存溢出错误:

溢出关键字:

java.lang. StackOverflowError

这个参数直接说明一个内容, 就是-Xss太小了 ,我们申请 很多局部调用的栈针等内容是存放在用户当前所持有的线程中的 ,线程在jdk 1.4以前默认是256K,1.5以后是1M,如果报这个错,只能说明-Xss设置得太小,当然有些厂商的JVM不是这个参数,本文仅仅针对Hotspot VM而已;不过在有必要的情况下可以对系统做一些优化,使得-Xss的值是可用的。


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

UML用户指南

UML用户指南

[美] Grady Booch、James Rumbaugh、Ivar Jacobson / 邵维忠、麻志毅、马浩海、刘辉 / 人民邮电出版社 / 2006-6 / 49.00元

《UML用户指南》(第2版)是UML方面最权威的一本著作,三位作者是面向对象方法最早的倡导者,是UML的创始人。本版涵盖了UML 2.0。书中为具体的UML特征提供了参考,描述了一个使用UML进行开发的过程,旨在让读者掌握UML的术语、规则和语言特点,以及如何有效地使用这种语言,知道如何应用UML去解决一些常见的建模问题。《UML用户指南》(第2版)由7个部分组成,而且每章都描述了一个特定UML特......一起来看看 《UML用户指南》 这本书的介绍吧!

HTML 压缩/解压工具
HTML 压缩/解压工具

在线压缩/解压 HTML 代码

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

Base64 编码/解码
Base64 编码/解码

Base64 编码/解码