JVM的G1对old区的一次回收日志
Jvm一共分配60G内存,old区涨到27G+之后,发生一轮old区的大规模回收,结束后old区降为8G。
原本以为会是一次full gc,或一次mixed gc,实际上是以一次带(initial-mark)的较长时间(600+毫秒)young gc开始,然后是一系列处理,其中remark是STW的,且耗时较长(300+毫秒),随后跟着一次young GC和三次mixed GC,这四次GC每一次old区都会下降,第三次mixed GC后,old区降到最低的8G,应该是本轮GC的结束。
找到一遍文章,对G1做了比较详细的解释:Understanding G1 GC Logs
这一轮过程被称为并发标记(concurrent-marking),从[initial-mark]起到[GC concurrent-cleanup-end]止,不包括后面的一次young GC和三次mixed GC。猜测是后续gc时会根据限定的暂停时间自动回收相应的内存。
其中较慢(300+毫秒)的remark(SATB buffers processing) 和较快(20+毫秒)的cleanup是stop-the-world(STW)的。
clean up: Cleanup phase which is again a stop-the-world phase. It goes through the marking information of all the regions, computes the live data information of each region, resets the marking data structures and sorts the regions according to their gc-efficiency.
大意是:Cleanup操作也是STW的,它通过各区标记的信息计算存活对象,重置这些数据结构,然后根据GC的效率对各区排序。
jvm启动参数:
[code]
java -server -Xmx60g -Xms60g -XX:MaxGCPauseMillis=300 -XX:PermSize=128m -XX:MaxPermSize=256m -Xss256k -XX:+DisableExplicitGC -XX:+UseG1GC -XX:LargePageSizeInBytes=128m -verbose:gc -Xloggc:/data/logs/gc_xxx.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -jar xxx.jar
[/code]
先用jstat看整体GC的统计
[code]
[[email protected] logs]# jstat -gcutil 2450 1000
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 100.00 58.62 41.51 71.09 3869 474.469 0 0.000 474.469
0.00 100.00 59.96 41.51 71.09 3869 474.469 0 0.000 474.469
[/code]
没有Full GC,OLD区已经从昨天看到的80+%降到41%