jar包启动命令
java -jar -XX:+UseParallelGC -XX:+UseParallelOldGC -Xms64m -Xmx128m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:./gc.log -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=192.168.200.129 itcast-gc-demo-1.0-SNAPSHOT.jar
image.png
观查到年轻代和老年带的峰值已经很接近初始分配的值，说明内存不足
image.png
吞吐量达到98.35%较高
平均暂定时间 13.8稍微高
最大暂停时间200ms较高
可以看出，在初始状态时，吞吐量并不高，最大停顿时间较长，平均停顿时间表现不错。
image.png
在图表中可以看出，gc之后的堆内存的使用在高峰时，将占用到40m ~ 90m之间
image.png
在图表中可以看出，gc之前的堆内存的使用在高峰时，将占用到60m ~ 110m之间
image.png
在gc持续时间统计中，可以看出full gc的时间要远高于younggc的时间，在调优时应当尽量的减少full gc。
image.png
在清理垃圾的统计中，可以看出gc清理的垃圾基本维持在20m左右，最多的一次是发生在full gc，可以推断此次是
内存即将耗尽，发生了fullgc，释放了大量的内存空间，这也是在前面年轻代对象有部分进入到老年代，在此次
fullgc时被清理了。发现fullgc次数实在太多
image.png
从年轻代的gc情况来看，gc之前与gc之后差较大，说明垃圾对象在年轻代被清理的比较多，就是说临时性的对象居
多。大概差别20m左右
image.png
从老年代的gc情况来看，gc之前与之后的差并不大，说明老年代的垃圾对象并不是很多。
image.png
元空间大概占用35m左右，足够
image.png
从该图中看出，晋升到老年代的对象与可以分配对象相比，非常的少，也说明了上面我们看到的，对象主要集中在
young区。
image.png
在GC统计中，可以看出：
Minor GC清理掉的垃圾对象合计24.36gb，说明产生的临时对象非常的多
Minor GC的执行间隔为63ms，说明发生gc的行为是比较频繁的
Full GC发生了152次，较为频繁
Full GC的平均持续时间为81ms，时间较长
GC的暂停次数为1822次，暂停次数将影响到服务的响应时间
关注FUllGC 的频繁此时 持续时间 GC的暂停次数
image.png
在GC原因统计中可以看出，大部分发生gc的原因都为分配失败，也就说内存不足导致；
需要说明的是虽然发生了4次Metadata GC，并不是Metaspace不足导致，前面我们看到Metaspace空间充足，而
是该gc发生在最开始时间，说明初始的Metaspace不足，导致了Metaspace扩容，并发生了GC，可以适当调整
Metaspace初始大小以减少Metadata GC次数。
