介绍
我们都知道,项目线上发布的时候尽量避免使用JVM 默认的配置参数,默认的堆栈空间就几百MB,而且有些参数不太满足自己项目的实际场景。因此我们需要自定义自己项目的JVM 配置信息,最主要的目的就是让生产环境的JVM 跑得更加流畅,更加的稳定。 其中,作为开发程序员我们最关心的莫过于GC,因为或导致STW(stop the world)停顿时间,特别是Full GC(注:现代垃圾收集器 一般进行老年代收集的时候都会将永久带,metadata space 等整个堆空间进行内存回收,所以我这里直接用Full GC,而不是 old GC,如果严谨或者精确来说 你说Old GC 也没毛病,除非面试时候遇到较真的面试官,那就问清楚再回答 ),如果系统动不动就停顿个几秒钟或者几十秒,估计要拉一个程序员祭天了。
最好的情况下,我们希望我们的线上系统尽量只发生Young GC,或者 至少 一天或几个小时 才发生一次Full GC,因为Full GC 的耗时 和 性能 消耗式 Young GC的 十几二十倍,因此,本文关注的重点在于 如何优化 Full GC 的场景。
Young GC 和 Full GC 触发的时机
Young GC 触发时机
- 年轻代Eden 区没有空间可以分配给新生对象,就会触发Young GC,然后将存活对象放入Suvivor 区 或者 进入老年代
Full GC 触发时间
- (1)老年代空间不足,这个很简单,就是字面上的不足,例如:大对象不停的直接进入老年代,最终造成空间不足。或者达到设置的触发Full GC 的时机
- (2)永久带 空间不足(jdk1.8 之后 metadata space 空间不足)。</