FullGC

fullgc的时候除gc线程外的所有用户线程处于暂停状态,也就是不会有响应了。一般fullgc速度很快,毫秒级的,用户无感知。除非内存特别大上百G的,或者fullgc也无法收集到足够内存导致一直fullgc,应用的外在表现就是程序卡死了

 HotSpot虚拟机将其物理上划分为两个–新生代（young generation）和老年代（old generation)、永久代（PermanentGeneration）

涉及到的术语：

Stop-the-world

意味着 JVM 因为要执行GC而停止了应用程序的执行。当Stop-the-world发生时，除了GC所需的线程以外，所有线程都处于等待状态，直到GC任务完成。GC优化很多时候就是指减少Stop-the-world发生的时间。
MinGC\MajorGC都属于Stop-the-world, 那为什么MajorGC耗时较长呢？因为OldGen包含了大量存货下来的对象。

新生代（Young generation）

绝大多数最新被创建的对象会被分配到这里，由于大部分对象在创建后会很快变得不可到达，所以很多对象被创建在新生代，然后消失。对象从Young generation区域消失的过程我们称之为 minor GC

老年代（Old generation）

对象没有变得不可达，并且从新生代中存活下来，会被拷贝到这里。其所占用的空间要比新生代多。也正由于其相对较大的空间，发生在老年代上的GC要比新生代少得多。对象从老年代中消失的过程，我们称之为 major GC

minorGC 是清理整合YouGen的过程， eden 的清理，S0\S1的清理都由于MinorGC

MajorGC:清理整合OldGen的内存空间

持久代（ permanent generation ）:

也被称为方法区（method area）。PerGen主要存放.class等文件 ,Java8中，永久代已经被移除，被一个称为“元数据区”（元空间）的区域所取代。

FullGC触发场景：

1、System.gc

2、promotion failed (年代晋升失败,比如eden区的存活对象晋升到S区放不下，又尝试直接晋升到Old区又放不下，那么Promotion Failed,会触发FullGC)

3、CMS的Concurrent-Mode-Failure 由于CMS回收过程中主要分为四步:
      1.CMS initial mark 2.CMS Concurrent mark 3.CMS remark 4.CMS Concurrent sweep。

在2中gc线程与用户线程同时执行，那么用户线程依旧可能同时产生垃圾，
如果这个垃圾较多无法放入预留的空间就会产生CMS-Mode-Failure，
切换为SerialOld单线程做mark-sweep-compact。

4、新生代晋升的平均大小 大于 老年代的剩余空间 （为了避免新生代晋升到老年代失败）

当使用G1,CMS 时，FullGC发生的时候 是 Serial+SerialOld。
当使用ParalOld时，FullGC发生的时候是 ParallNew +ParallOld.

另外值得注意的是:日志里的 “Full”指非YGC的GC的STW次数! Full Gc 才是实际发生fullGC的次数。不要混淆。

5、新对象达到了XX:PretenureSizeThreshold，被直接担保分配进了老年代

————————————————
版权声明：本文为CSDN博主「张硕的博客」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/lemon89/article/details/45462229

深入探究

那么为什么会引起频繁FullGC 呢?

回答这个问题之前，先了解下，有哪些情况会触发 Full GC ？

1. 老年代内存空间不足时，会触发 FullGC.
2. 永久代/metaspace 内存空间不足时，也会触发FullGC.
3. 显示调用 GC,System.gc().(会建议jvm GC，但是不一定会GC).

产生 FullGC 的基本原因就上面三种。

故障服务就是创建很多对象，无法回收，导致内存不足，然后 GC 回收不了时，就会引起频繁 FullGC 了。

转载：

深入理解GC ——MinorGC\MajorGC\FullGC_张硕的博客-CSDN博客_minorgc

java 频繁 full gc_大对象引起的频繁FULL GC_六三门的博客-CSDN博客