这是我参与11月更文挑战的第11天，活动详情查看：2021最后一次更文挑战
今天，我们来分析GC日志，会分析GC日志呢，有助于我们可以判断JVM的内部运行情况，使我们更好的根据实际运行程序的情况，对JVM做出一些调整，来满足一些实际的性能需求。
本篇文章重点讲解GC日志的分支这块，我们应该看哪块，用哪些GC工具进行分析，能得出什么结论等等，算是对我们前面学习的知识的回顾，话不多说，我们一起来看下吧。
GC日志的解读
这里面是说：GC的原因是因为内存分配失败了，然后我们使用的GC算法是java8里的GC，那我们得查看一下使用的GC算法是什么，我们使用jps加jinfo进行查询。
使用jps，找到我们系统的进程ID，这里是3296
我们可以看到，使用的是并行GC。
然后我们知道并行GC是需要STW的，所以我们可以看到STW的时间是13毫秒，这13毫秒都发生了什么呢？我们可以看到young区的大小 [PSYoungGen: 262144K->43516K(305664K)]压缩了大概219M，整个young区的大小大概是305M,我们整个的这个堆内存设置的是1G：262144K->80620K(1005056K)，那整个堆内存压缩之后是80M左右，那我们整个堆内存大概压缩了是182M的内存，这里面好玩的事情就发生了，压缩之前：我们的young区是262，整个堆内存也是262，压缩之后，我们的young区和堆内存的数据不一致了，那我们不🈲会产生疑问：少的数据哪去了？
其实是扛过了GC回收，从年轻代跑到了老年代：一共多少数据呢那就是219-182是37M的数据，我们可以这样想：年轻代数据减的数据比整个堆内存都多，多了多少呢，多了37M，这37M哪去了，跑到了老年代，或者我们可以这样计算：整个堆内存压缩后是80M，我们的年轻代是43M，剩下的37M就到了老年代。
然后多次GC，发生了一FullGC，然后我们看young区，本来有36M的数据，全部清空掉了，然后看Old区，[ParOldGen: 613141K->337990K(699392K)] ，减少了接近一半的数据，然后我们的元数据区就是我们的非堆，几乎没有变，然后整个Full GC是41毫秒，所以减少Full GC有助于提升程序性能。
