gc日志分析

经过日志分析，我找到两个突破点，重点关注红色字体部分的日志，分析过程如下： 

1）FULL GC前后Java堆大小有变化；经研究发现是由于Java应用JVM参数XMS设置为默认值，在我们的系统环境下，Hotspot的Xms默认值为50M（-Xms默认是物理内存的1/64）；每次GC时，JVM会根据各种条件调节Java堆的大小，Java堆的取值范围为[Xms, Xmx]。根据以上分析，修改Xms值与Xmx相等，这样就不会因为所使用的Java堆不够用而进行调节，经过测试后发现FULL GC次数从四位数减少至个位数。

2）关键词“System”让我想到了System.gc调用，System.gc调用只是建议JVM执行年老代GC，而年老代GC触发FULL GC，JVM会根据系统条件决定是否执行FULL GC，正因为系统条件不好判断，所以很难构造System.gc调用触发FULL GC，几经周折终于成功，当System.gc触发FULL  GC时都会有关键词“（System）”，而　JVM自动触发的FULL GC却不带关键词“（System）”，可以断定是Java应用存在“System.gc”代码。经过本次测试我也发现System.gc的真正含义，通俗言之，“System.gc” 就是FULL GC触发的最后一根稻草。 

从本次分析中，我们可以得出如下的经验： 
1）Java应用的jvm参数Xms与Xmx保持一致，避免因所使用的Java堆内存不够导致频繁full gc以及full gc中因动态调节Java堆大小而耗费延长其周期。 

2）建议不要调用System.gc或者Runtime.getRuntime().gc，否则本次调用可能会成为“压死骆驼的最后一根稻草”。当然我们可以通过设置jvm参数禁止这种调用生效，但是除非特别有把握该参数有必要添加，否则不推荐这么设置。