频繁GC (Allocation Failure)

现指脊象是频繁 [GC (Allocation Failure) [PSYoungGen: 513920K->2752K(516608K)] 2166534K->1660094K(2551808K), 0.0995743 secs] [Times: user=0.06 sys=0.00, real=0.10 secs] 

参考文章：https://juejin.im/post/5a9b811a6fb9a028e46e1c88

设置 G1回芦逗烂收陪漏器，JAVA_OPTS= -XX:+UseG1GC

GC会stop the world。会暂停程序的执行，带来延迟的代价。所以在开发中，我们不希望GC的次数过多。

本文将讨论如何在开发中改善各种细节，从而减少GC的次数。

(1)对象不用时最好显式置为 Null

一般而言,为 Null 的对象都会被作为垃圾处理,所以将不用的对象显式地设

为 Null,有利于 GC 收集器判定垃圾,从而提高了 GC 的效率。

(2)尽量少用 System.gc()

此函数建议 JVM进行主 GC,虽然只是建议而非一定,但很多情况下它会触发

主 GC,从而增加主 GC 的频率,也即增加了间歇性停顿的次数。

(3)尽量少用静态变量

静态变量属于全局变量,不会被 GC 回收,它们会一直占用内存。

(4)尽量使用 StringBuffer,而不用 String 来累加字符串

由于 String 是固定长的字符串对象,累加 String 对象时,并非在一个 String对象中扩增,而是重新创建新的 String 对象,如 Str5=Str1+Str2+Str3+Str4,这条语句执行过程中会产生多个垃圾对象,因为对次作“+” *** 作时都必须创建新的 String 对象,但这些过渡对象对系统来说是没有实际意义的,只会增加更多的垃圾。 避免这种情况可以改用 StringBuffer 来累加字符串,因 StringBuffer是可变长的,它在原有基础上进行扩增,不会产生中间对象

(5)分散对象创建颤毕或删除的时间

集中在短时间内大量创建新对象,特别是大对象,会导致突然需要大量内存,JVM 在面临这种情况时,只能进行主 GC,以回收内存或整合内存碎片,从而增加主 GC 的频率。

集中删除对象,道理也是茄敬芹一样的。 它使得突然出现了大量的垃圾对象,空闲空间必然减少,从而大大增加了下一次创建新对象时强制主 GC 的机会。

（6） 尽量少用 finalize 函数

因为它会加大 GC 的工作量， 因此尽量少用finalize 方式回收资源。

（7） 使用软引用类型

如果需要使用经常用到的图片， 可以使用软引用类型， 它可以尽可能将图片保存在内存中， 供程稿嫌序调用， 而不引起 OutOfMemory。

本文主要分析一答改派个频繁GC (Allocation Failure)及young gc时间过长的case。

jdk版本

这里使用的是java8，参数没有明确指定metaspace的大小和上限，查看一下

相关参数

这里可以到full gc的reason是Ergonomics，是因为开启了UseAdaptiveSizePolicy，jvm自己进行自适应调整引发的full gc

分析完full gc之后我们看下young gc，看log里头99%都是GC (Allocation Failure)造成的young gc。Allocation Failure表示向young generation(eden)给新对象申请空间，但是young generation(eden)剩余的合适空间不歼闷够所需的大清贺小导致的minor gc。

gc之后survivor有对象的例子

从上面的分析可以看出，young generation貌似有点大，ygc时间长；另外每次ygc之后survivor空间基本是空的，说明新生对象产生快，生命周期也短，原本设计的survivor空间没有派上用场。因此可以考虑缩小下young generation的大小，或者改为G1试试。

关于-XX:+PrintTenuringDistribution有几个要点，要明确一下：

---