标签: gc

系统频繁Full gc问题分析及解决办法

一、场景描述

上周开始系统在业务高峰期一直收到Full gc报警,监控显示fgc频繁,下图是监控图,左边红框是优化前效果,右边是优化后,优化后fgc基本为0

监控
二、原因查找

1.查看gc日志,发现old区fgc后大小没有变化,如下图:

gclog
2.去线上dump内存看是什么对象,用memory analyzer分析,Retained Size竟然有2.4G,全是sun.awt.SunToolkit这个对象,其实到这一步已经可以确定是什么问题了,只是自己对系统不是很熟悉,导致定位具体的问题代码花了一些时间

ma

三、原因分析

系统中有一个调用频繁的接口会调用下面这个方法,目的是获取图片的宽高信息,但是Image这个对象用完不会自动释放,需要手动调用 flush()方法;以前没有调用这个方法,就导致一有请求就会有大对象进入old区,在业务高峰期old区一会就被打满,所以一直进行fgc
public static Image getImage(String path) {
ImageIcon icon = new ImageIcon(path);
Image img = icon.getImage();
return img;
}

四、解决办法

其实不管是用Image还是BufferedImage,读取图片的宽高不用把图片全部加载到内存,在图片的宽高信息其实是存储在文件头中的,只 要按不同的格式读取文件的头信息就可以拿到宽高信息
使用ImageReader代码如下

Iterator readers = ImageIO.getImageReadersByFormatName(StringUtil.getFileSuffix(filePath));
ImageReader reader = (ImageReader)readers.next();
iis = ImageIO.createImageInputStream(is);
reader.setInput(iis, true);
return Pair.of(reader.getWidth(0),reader.getHeight(0));

使用PrintGCDateStamps打印GC时间

之前打印gc日志的时候使用是:-XX:+PrintGCTimeStamps,这个选项记录的是jvm启动时间为起点的相对时间,可读性较差,不利于定位问题,使用PrintGCDateStamps记录的是系统时间,更humanreadable

5个不能不知的JVM参数

1. DisableExplicitGC
我已记不清有多少次用户要求我就应用程序性能问题提供咨询了,其实只要跨代码快速运行 grep,就会发现清单 1 所示的问题 — 原始 java 性能反模式:

清单 1. System.gc();

[java]
System.gc();

[/java]

显式垃圾收集是一个非常糟糕的主意 — 就像将您和一个疯狂的斗牛犬锁在一个电话亭里。尽管调用的语法是依赖实现的,但如果您的 JVM 正在运行一个分代的垃圾回收器(大多数是)System.gc(); 强迫 VM 执行一个堆的 “全部清扫”,虽然有的没有必要。全部清扫比一个常规 GC 操作要昂贵好几个数量级,这只是个简单数学问题。
您可以不把我的话放在心上 — Sun 的工程师为这个特殊的人工错误提供一个 JVM 标志; -XX:+DisableExplicitGC 标志自动将 System.gc() 调用转换成一个空操作,为您提供运行代码的机会,您自己看看 System.gc() 对于整个 JVM 执行有害还是有利。

阅读详细 »

JVM内存分配与回收策略

对象的内存分配,就是在堆上分配(但也可能经过JIT编译后被拆散为标量类型并间接地在栈上分配),对象主要分配在新生代的Eden区上,如果启动了本地线程分配缓冲,将按线程优先在TLAB上分配。少数情况下也可能会直接分配在老年代中,分配的规则并不是百分之百固定的,其细节取决于当前使用的是哪一种垃圾收集器组合,还有虚拟机中与内存相关的参数的设置。

新生代GC(Minor GC):指发生在新生代的垃圾收集动作,因为Java对象大多都具备朝生夕灭的特性,所以Minor GC非常频繁,一般回收速度也比较快。
老年代GC(Major GC / Full GC):指发生在老年代的GC,出现了Major GC,经常会伴随至少一次的Minor GC(但非绝对的,在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程)。MajorGC的速度一般会比Minor GC慢10倍以上。

下面是最普遍的内存分配规则,并通过代码去验证这些规则。下面的代码在测试时使用Client模式虚拟机运行,没有手工指定收集器组合,验证的是使用Serial / Serial Old收集器下(ParNew / Serial Old收集器组合的规则也基本一致)的内存分配和回收的策略。

虚拟机提供了-XX:+PrintGCDetails这个收集器日志参数,告诉虚拟机在发生垃圾收集行为时打印内存回收日志,并且在进程退出的时候输出当前内存各区域的分配情况。在实际应用中,内存回收日志一般是打印到文件后通过日志工具进行分析,不过本实验的日志并不多,直接阅读就能看得很清楚。

1. 对象优先在Eden分配

执行testAllocation()中分配allocation4对象的语句时会发生一次Minor GC,这次GC的结果是新生代6651KB变为148KB,而总内存占用量则几乎没有减少(因为allocation1、2、3三个对象都是存活的,虚拟机几乎没有找到可回收的对象)。这次GC发生的原因是给allocation4分配内存的时候,发现Eden已经被占用了6MB,剩余空间已不足以分配allocation4所需的4MB内存,因此发生Minor GC。GC期间虚拟机又发现已有的3个2MB大小的对象全部无法放入Survivor空间(Survivor空间只有1MB大小),所以只好通过分配担保机制提前转移到老年代去。这次GC结束后,4MB的allocation4对象被顺利分配在Eden中。因此程序执行完的结果是Eden占用4MB(被allocation4占用),Survivor空闲,老年代被占用6MB(被allocation1、2、3占用)。

阅读详细 »

JVM内存回收简介

Sun的JVM GC(垃圾回收)原理:把对象分为:年轻代(Young)、年老代(Tenured)、持久代(Perm),对不同生命周期的对象使用不同的算法。(基于对对象生命周期分析)

jvm_memory

1. Young(年轻代)
年轻代分三个区。一个Eden区,两个Survivor区。大部分对象在Eden区中生成。当Eden区满时,还存活的对象将被复制到Survivor区(两个中的一个),当这个Survivor区满时,此区的存活对象将被复制到另外一个Survivor区,当这个Survivor去也满了的时候,从第一个Survivor区复制过来的并且此时还存活的对象,将被复制年老区(Tenured。需要注意,Survivor的两个区是对称的,没先后关系,所以同一个区中可能同时存在从Eden复制过来 对象,和从前一个Survivor复制过来的对象,而复制到年老区的只有从第一个Survivor去过来的对象。而且,Survivor区总有一个是空的。
2. Tenured(年老代)
年老代存放从年轻代存活的对象。一般来说年老代存放的都是生命期较长的对象。
3. Perm(持久代)
用于存放静态文件,如今Java类、方法等。持久代对垃圾回收没有显著影响,但是有些应用可能动态生成或者调用一些class,例如Hibernate等,在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。持久代大小通过-XX:MaxPermSize=进行设置。

举个例子:当在程序中生成对象时,正常对象会在年轻代中分配空间,如果是过大的对象也可能会直接在年老代生成(据观测在运行某程序时候每次会生成一个十兆的空间用收发消息,这部分内存就会直接在年老代分配)。年轻代在空间被分配完的时候就会发起内存回收,大部分内存会被回收,一部分幸存的内存会被拷贝至Survivor的from区,经过多次回收以后如果from区内存也分配完毕,就会也发生内存回收然后将剩余的对象拷贝至to区。等到to区也满的时候,就会再次发生内存回收然后把幸存的对象拷贝至年老区。

通常我们说的JVM内存回收总是在指堆内存回收,确实只有堆中的内容是动态申请分配的,所以以上对象的年轻代和年老代都是指的JVM的Heap空间,而持久代则是之前提到的Method Area,不属于Heap。

JVM -verbose参数详解

java -verbose[:class|gc|jni] 在输出设备上显示虚拟机运行信息。

java -verbose:class

在程序运行的时候有多少类被加载!你可以用verbose:class来监视,在命令行输入java -verbose:class XXX  (XXX为程序名)你会在控制台看到加载的类的情况。
verbose和verbose:class含义相同,输出虚拟机装入的类的信息,显示的信息格式如下: 
[Opened D:\Java\jdk1.6.0_25\jre\lib\rt.jar]
[Loaded java.lang.Object from D:\Java\jdk1.6.0_25\jre\lib\rt.jar]
[Loaded java.io.Serializable from D:\Java\jdk1.6.0_25\jre\lib\rt.jar]
[Loaded java.lang.Comparable from D:\Java\jdk1.6.0_25\jre\lib\rt.jar]
[Loaded java.lang.CharSequence from D:\Java\jdk1.6.0_25\jre\lib\rt.jar]
[Loaded java.lang.String from D:\Java\jdk1.6.0_25\jre\lib\rt.jar]
[Loaded java.lang.reflect.GenericDeclaration from D:\Java\jdk1.6.0_25\jre\lib\rt.jar]
[Loaded java.lang.reflect.Type from D:\Java\jdk1.6.0_25\jre\lib\rt.jar]
[Loaded java.lang.reflect.AnnotatedElement from D:\Java\jdk1.6.0_25\jre\lib\rt.jar]
[Loaded java.lang.Class from D:\Java\jdk1.6.0_25\jre\lib\rt.jar]
[Loaded java.lang.Cloneable from D:\Java\jdk1.6.0_25\jre\lib\rt.jar]
[Loaded java.lang.ClassLoader from D:\Java\jdk1.6.0_25\jre\lib\rt.jar]
[Loaded java.lang.System from D:\Java\jdk1.6.0_25\jre\lib\rt.jar]
[Loaded java.lang.Throwable from D:\Java\jdk1.6.0_25\jre\lib\rt.jar]
当虚拟机报告类找不到或类冲突时可用此参数来诊断来查看虚拟机从装入类的情况。

java –verbose:gc

在虚拟机发生内存回收时在输出设备显示信息,格式如下: [Full GC 256K->160K(124096K), 0.0042708 secs] 该参数用来监视虚拟机内存回收的情况。
public class JvmVerbose {
/**
* JVM -verbose[:class|gc|jni] 参数测试
* @param args
*/
public static void main(String[] args) {
JvmVerbose jvmVerbose = new JvmVerbose();
System.gc();
}
}
在这个例子中,一个新的对象被创建,由于它没有使用,所以该对象迅速地变为可达,程序编译后,执行命令: java -verbose:gc JvmVerbose 后结果为:
[GC 647K->256K(124096K), 0.0274253 secs]
[Full GC 256K->160K(124096K), 0.0042708 secs]
箭头前后的数据256K和160K分别表示垃圾收集GC前后所有存活对象使用的内存容量,说明有256K-160K=96K的对象容量被回收,括号内的数据124096K为堆内存的总容量,收集所需要的时间是0.0042708秒(这个时间在每次执行的时候会有所不同)。

java –verbose:jni

-verbose:jni输出native方法调用的相关情况,一般用于诊断jni调用错误信息。
在虚拟机调用native方法时输出设备显示信息,格式如下: [Dynamic-linking native method java.lang.Object.registerNatives ... JNI] 该参数用来监视虚拟机调用本地方法的情况,在发生jni错误时可为诊断提供便利。

java jvm GC 参数设置

 

1: heap size 
a: -Xmx 
指定jvm的最大heap大小,如:-Xmx2g 

b: -Xms 
指定jvm的最小heap大小,如:-Xms1g 

c: -Xmn 
指定jvm中New Generation的大小,如:-Xmn256m 

d: -XX:PermSize 
指定jvm中Perm Generation的最小值,如:-XX:PermSize=32m 

e: -XX:MaxPermSize 
指定Perm Generation的最大值,如:-XX:MaxPermSize=64m 

f: -Xss 
指定线程桟大小,如:-Xss128k 

g: -XX:NewRatio 
指定jvm中Old Generation heap size与New Generation的比例,在使用CMS GC的情况下此参数失效, 如:-XX:NewRatio=2 

h: -XX:SurvivorRatio 
指定New Generation中Eden Space与一个Survivor Space的heap size比例,-XX:SurvivorRatio=8,那么在总共New Generation为10m的情况下,Eden Space为8m 

i: -XX:MinHeapFreeRatio 
指定jvm heap在使用率小于n的情况下,heap进行收缩,Xmx==Xms的情况下无效,如:-XX:MinHeapFreeRatio=30 

j: -XX:MaxHeapFreeRatio 
指定jvm heap在使用率大于n的情况下,heap进行扩张,Xmx==Xms的情况下无效,如:-XX:MaxHeapFreeRatio=70 

k: -XX:LargePageSizeInBytes 
指定Java heap的分页页面大小,如:-XX:LargePageSizeInBytes=128m 

2: garbage collector 
a: -XX:+UseParallelGC 
指定在New Generation使用parallel collector,并行收集,同时启动多个垃圾回收thread,不能和CMS gc一起使用.系统吨吐量优先,但是会有较长长时间的app pause,后台系统任务可以使用此gc 

b: -XX:ParallelGCThreads 
指定parallel collection时启动的thread个数,默认是物理processor的个数,如:-xx:ParallelGCThreads=8 

c: -XX:+UseParallelOldGC 
指定在Old Generation使用parallel collector 

d: -XX:+UseParNewGC 
指定在New Generation使用parallel collector,是UseParallelGC的gc的升级版本,有更好的性能或者优点,可以和CMS gc一起使用 

e: -XX:+CMSParallelRemarkEnabled 
在使用UseParNewGC的情况下,尽量减少mark的时间 

f: -XX:+UseConcMarkSweepGC 
指定在Old Generation使用concurrent cmark sweep gc,gc thread和app thread并行,所以称作concurrent.app pause时间较短,适合交互性强的系统,如web server 

g: -XX:+UseCMSCompactAtFullCollection 
在使用concurrent gc的情况下,防止memory fragmention,对live object进行整理,使memory碎片减少 

h: -XX:CMSInitiatingOccupancyFraction=n 
指示在old generation在使用了n%的比例后,启动concurrent collector,默认值是68,如:-XX:CMSInitiatingOccupancyFraction=70 
有个bug,在低版本的jvm上出现,http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6486089 

i: -XX:+UseCMSInitiatingOccupancyOnly 
指示只有在old generation在使用了初始化的比例后concurrent collector启动收集 

3:others 
a: -XX:MaxTenuringThreshold 
指定一个object在经历了n次young gc后转移到old generation区,在linux64的java6下默认值是15,此参数对于throughput collector无效,如:-XX:MaxTenuringThreshold=31 

b: -XX:+DisableExplicitGC 
禁止java程序中的full gc,如System.gc()的调用 

c: -XX:+UseFastAccessorMethods 
原始类型get,set方法的优化 

d: -XX:+PrintGCDetails 
打应垃圾收集的情况如: 
[GC 15610.466: [ParNew: 229689K->20221K(235968K), 0.0194460 secs] 1159829K->953935K(2070976K), 0.0196420 secs] 

e: -XX:+PrintGCTimeStamps 
打应垃圾收集的时间情况,如: 
[Times: user=0.09 sys=0.00, real=0.02 secs] 

f: -XX:+PrintGCApplicationStoppedTime 
打应垃圾收集时,系统的停顿时间,如: 
Total time for which application threads were stopped: 0.0225920 seconds 

4  -XX:+UseCompressedOops 
    压缩指针  64位机器,JDK1.6支持