1. 新生代GC场景

新生代的内存分为Eden和两个Survivor的。如果系统不停的运行，最终会把Eden给塞满。

一旦Eden塞满，就会触发Minor GC，而进行垃圾回收是有专门的垃圾回收线程的，不同的内存区域会有不同的垃圾回收器 。

简单来说，就是垃圾回收线程和垃圾回收器配合起来，使用自己的垃圾回收算法，对指定的内存区域进行垃圾回收，如下图：

2. GC的时候还能继续创建新的对象吗？

这里要思考，在GC的时候，我们写好的 Java系统在运行期间还能不能继续在新生代里创建新的对象了？

假设允许在GC期间，还可以继续让系统在新生代的Eden区里创建新的对象。那么，对于程序新创建的这些对象，垃圾回收器是无法去持续追踪这些对象的状态的。

并且在进行垃圾回收的过程中把新对象中的存活对象也转移到 Survivor1或Survivor2中去的想法是不可行的。

所以，在垃圾回收的过程中，同时还允许我们写的Java系统继续不停的运行在Eden里持续创建新的对象，目前来看是不合适的一件事。

3. JVM的痛点：Stop the World

JVM最大的痛点，是在垃圾回收的这个过程。

因为在垃圾回收的时候，尽可能要让垃圾回收器专心致志的工作，所以不能随便让我们的Java系统创建新对象，此时JVM会在后台直接进入 “Stop the World” 状态。

也就是说，他们会直接停止我们写的Java系统的所有工作线程，让我们写的代码不再运行。

然后让垃圾回收线程可以专心致志的进行垃圾回收的工作，如下图所示：

这样的话，就可以让我们的系统暂停运行，然后不再创建新的对象，同时让垃圾回收线程尽快完成垃圾回收的工作，就是标记和转移Eden以及Survivor2的存活对象到Survivor1中去，然后尽快一次性回收掉Eden和Survivor2中的垃圾对象，如下图：

接着垃圾回收完毕，就可以继续恢复Java系统的工作线程的运行了，然后我们的代码就可以继续运行，继续在Eden中创建新的对象

4. Stop the World造成的系统停顿

假设Minor GC要运行100ms，那么就会导致这100ms期间用户发起的所有请求都会出现短暂的卡顿，因为系统的工作线程不在运行，所以不能处理任何请求。

参考前面的案例，因为内存分配不合理，导致对象频繁进入老年代，平均七八分钟一次Full GC，而Full GC是最慢的，有的时候弄不好一次回收要进行几秒钟，甚至几十秒或几分钟。

那么一旦频繁的Full GC，就意味着系统每隔七八分钟后，会在30秒内任何用户的请求全部卡死无法处理，然后用户看到的都是系统超时之类的提示，这会让用户体验极差。

总得来说，无论是新生代GC还是老年代GC，都尽量不要让频率过高，也避免持续时间过长，避免影响系统正常运行。而这也是JVM过程中需要优化的一个重点。

5.不同的垃圾回收器的不同的影响

在对新生代的回收，Serial垃圾回收器就是用一个线程进行垃圾回收，然后暂停系统工作线程，所以一般很少用这种方式。

而平时常用的新生代垃圾回收区是ParNew，它针对服务器一般都是多核CPU做了优化，是支持多线程去垃圾回收的，可以大幅度提升回收的性能，缩短回收的时间。大致原理图如下：

综上所述，不同的垃圾回收器会有不同的机制和原理，使用多线程或者单线程，都是有区别的。