JDK8_JVM_GC日志

-Xmx200m 
-Xms200m 
-XX:MetaspaceSize=200M 
-XX:MaxMetaspaceSize=200M
-XX:+PrintGCDetails 
-XX:+PrintHeapAtGC 
-XX:-UseAdaptiveSizePolicy 
-XX:SurvivorRatio=8 
-XX:NewRatio=4

-Xmx200m   #最大堆内存
-Xms200m  #最小堆内存
-XX:MetaspaceSize=200M  #设置使用本地内存的元空间大小，放置class文件，classloader加载文件
-XX:MaxMetaspaceSize=200M
-XX:+PrintGCDetails   #打印gc日志
-XX:+PrintHeapAtGC   #打印零内存日志
-XX:-UseAdaptiveSizePolicy #禁用动态调整，使SurvivorRatio可以起作用
-XX:SurvivorRatio=8  #设置Eden:Survivior=8
-XX:NewRatio=4 
#设置Old:New=4  也可以指定 -XX:NewSize=10M -XX:MaxNewSize=10M 设置整个新生代的大小为10M

-XX:+PrintGC 输出GC日志
-XX:+PrintGCDetails 输出GC的详细日志
-XX:+PrintGCTimeStamps 输出GC的时间戳（以基准时间的形式）
-XX:+PrintGCDateStamps 输出GC的时间戳（以日期的形式，如 2013-05-04T21:53:59.234+0800）
-XX:+PrintHeapAtGC 在进行GC的前后打印出堆的信息
-Xloggc:../logs/gc.log 日志文件的输出路径

GC日志中的PSYoungGen（PS是指Parallel Scavenge）为Eden+FromSpace，而整个YoungGeneration为Eden+FromSpace+ToSpace。

我们设置的新生代大小为10240K，这包括9216K大小的PSYoungGen和1024K大小的ToSpace。其中，PSYoungGen中的Eden:FromSpace为8:1，

这包括8192K的Eden和1024K的FromSpace。

“[PSYoungGen”和”[ParOldGen”是指GC发生的区域，分别代表使用Parallel Scavenge垃圾收集器的新生代和使用Parallel old垃圾收集器的老生代。为什么是这两个垃圾收集器组合呢？因为我的jvm开启的模式是Server，而Server模式的默认垃圾收集器组合便是这个，在命令行输入java -version就可以看到自己的jvm默认开启模式。还有一种是client模式，默认组合是Serial收集器和Serial Old收集器组合。

在方括号中”PSYoungGen:”后面的”3686K->664K(38400K)”代表的是”GC前该内存区域已使用的容量->GC后该内存区域已使用的容量(该内存区域总容量)”

在方括号之外的”3686K->672K(125952K)”代表的是”GC前Java堆已使用容量->GC后Java堆已使用容量(Java堆总容量)”

再往后的”0.0016607 sec”代表该内存区域GC所占用的时间，单位是秒。

再后面的”[Times: user=0.00 sys=0.00, real=0.00 secs]”，user代表进程在用户态消耗的CPU时间，sys代表代表进程在内核态消耗的CPU时间、real代表程序从开始到结束所用的时钟时间。这个时间包括其他进程使用的时间片和进程阻塞的时间（比如等待 I/O 完成）。

MeataspaceSize建议

MetaspaceSize和MaxMetaspaceSize设置一样大；
具体设置多大，建议稳定运行一段时间后通过jstat -gc pid确认且这个值大一些，对于大部分项目256m即可。
如果metaspacesize过小则会导致触发Full gc

Metadata GC Threshold：metaspace空间不能满足分配时触发，这个阶段不会清理软引用；

Last ditch collection：经过Metadata GC Threshold触发的full gc后还是不能满足条件，这个时候会触发再一次的gc cause为Last ditch collection的full gc，这次full gc会清理掉软引用