存档

文章标签 ‘gc’

5个不能不知的JVM参数

2013年2月28日 没有评论

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

清单 1. System.gc();

System.gc();

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

阅读全文…

分类: jvm 标签: , , ,

JVM内存分配与回收策略

2013年2月26日 1 条评论

对象的内存分配,就是在堆上分配(但也可能经过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 标签: ,

JVM内存回收简介

2013年2月5日 没有评论

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 标签: , , ,

java jvm GC 参数设置

2012年11月3日 没有评论

 

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支持

 
分类: jvm 标签: , ,