JVM GC总结

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基础