JVM GC总结

11月 17, 2014 |

jvm gc常用垃圾收集算法有:
mark-sweep 简单低效,内存碎片
copy?????? 简单高效,但额外内存
mark-compact 前两种算法折中
新生代的收集器有:
Serial [copy算法]
ParNew [copy算法]
Parallel Scavenge [copy算法]

老年代收集器为:
Serial Old [mark-compact算法]
CMS [mark-sweep算法]
Parallel Old [mark-compact算法]

CMS [mark-sweep算法]分为四个阶段
initial mark[stop the world, singleThread] ->concurrent mark(root tracing)->remark[stop the world, multiThread]->concurrent sweep
由于采用sweep 收集算法,最后有可能内存碎片太严重导致"concurrent mode failure",需要额外触发一次full Gc[Serial Old ],
CMS算法也不能等待整个老年代区域耗尽才进行垃圾回收,默认老年代占用68%就触发垃圾回收。-XX:CMSInitiatingOccupancyFraction 指定触发CMS GC的老年代使用率
-XX:CMSFullGcsBeforeCompaction 多少次CMS后执行一次整理【serial old】操作

 

常见的jvm调试参数:
-Xms 最小内存大小
-Xmx 最大内存大小
-Xmn 新生代内存大小
-XX:PermSize=256m -XX:MaxPermSize=256m 调整永生代大小
-XX:SurvivorRatio=8 Eden/一个Survivor = 8:1
-XX:+PrintGCDetails 打印gc活动的详细
-verbose:gc 显示gc活动信息
-XX:PretenureSizeThreshold 当对象大于这个值时直接进入老年代
-XX:HandlePromotionFailure :如果为true,当历次Eden+Survivor中的对象晋升到老年代的平均大小 小鱼当前老年代的剩余空间,那么就执行一次minor GC,如果回收失败,再major GC;如果为false,当Eden+Survivor的总大小 大于老年代的剩余空间时,直接进行major gc。

gc输出格式:
gc后,live对象总大小由325407K变成了83000K,当前heap的总大小(Eden+one Survivor),本次collection耗时0.2300771s
[GC 325407K->83000K(776768K), 0.2300771 secs]

发生OutOfMemory后Dump
-XX:HeapDumpPath=D:/ -XX:+HeapDumpOnOutOfMemoryError

Posted in: java基础

Comments are closed.