日志文件中的部分内容如下：
分析：
让我们来挑几条典型的日志进行分析：
第一条：63.971: [GC (Allocation Failure) [PSYoungGen: 31073K->4210K(38400K)]
31073K->4234K(125952K), 0.0049946 secs] [Times: user=0.05 sys=0.02, real=0.01 secs]
1. 63.971：gc发生时，虚拟机运行了多少秒。
2. GC (Allocation Failure) ： 发生了一次垃圾回收，这是一次Minor GC 。注意它不表示只GC新生代，括号里的内容是gc发生的原因，这里的Allocation Failure的原因是年轻代中没有足够区域能够存放需要分配的数据而失败。
3. PSYoungGen: 使用的垃圾收集器的名字。
4. 31073K->4210K(38400K)指的是垃圾收集前->垃圾收集后(年轻代堆总大小)
5. 31073K->4234K(125952K),指的是垃圾收集前后，Java堆的大小（总堆125952K，堆大小包括新生代和年老代）
因此可以计算出年老代占用空间为125952k-38400k = 87552k
6. 0.0049946 secs：整个GC过程持续时间
7. [Times: user=0.05 sys=0.02, real=0.01 secs]分别表示用户态耗时，内核态耗时和总耗时。也是对gc耗时的一个记录。
第二条：106.840: [GC (System.gc()) [PSYoungGen: 130695K->5216K(472576K)] 228903K->121835K(644608K), 0.0342911 secs] [Times: user=0.13 sys=0.00, real=0.03 secs]
先对于第一条的(Allocation Failure) 变成了(System.gc())，说明这是一次成功的垃圾回收。
第三条：83.783: [Full GC (System.gc()) [PSYoungGen: 15361K->0K(372224K)] [ParOldGen: 83468K->98200K(172032K)] 98829K->98200K(544256K), [Metaspace: 9989K->9989K(1058816K)], 0.3036213 secs] [Times: user=1.03 sys=0.00, real=0.30 secs]
对于Full GC：
1 [PSYoungGen: 15361K->0K(372224K)] ：年轻代：垃圾收集前->垃圾收集后(年轻代堆总大小)
2 [ParOldGen: 83468K->98200K(172032K)] ：年老代：垃圾收集前->垃圾收集后(年老代堆总大小)
3 98829K->98200K(544256K), ：垃圾收集前->垃圾收集后(总堆大小)
4 [[Metaspace: 9989K->9989K(1058816K)], Metaspace空间信息，同上
5 0.3036213 secs：整个GC过程持续时间
6 [Times: user=1.03 sys=0.00, real=0.30 secs] 分别表示用户态耗时，内核态耗时和总耗时。也是对gc耗时的一个记录。
第四条：71.601: [Full GC (Ergonomics) [PSYoungGen: 20555K->0K(367616K)] [ParOldGen: 104080K->83460K(172032K)] 124636K->83460K(539648K), [Metaspace: 9959K->9959K(1058816K)], 0.2146493 secs] [Times: user=0.64 sys=0.00, real=0.21 secs]
这里可以到full gc的reason是Ergonomics，是因为开启了UseAdaptiveSizePolicy，jvm自己进行自适应调整引发的full gc。
对于底下Heap的输出情况，和上面是完全一致的。
只是增加了堆中每个部分total总大小，used使用情况。
PSYoungGen分为eden space 530336K, 3% used ， from space 48128K, 0% used ， to space 47104K, 0% used三个部分，分别显示了它们的大小和used比例。
ParOldGen分为object space246784K, 1% used，显示了其大小和used比例。
Metaspace中used大小为10174k。
解决方式：直接修改配置参数 -Xmn2g （这里需要根据需求来设置）