1、复制算法
复制（Copying）算法说到底也是为了解决 标记-清除算法 产生的那些碎片问题。
首先将内存分为大小相等的两部分（假设A、B两部分），每次呢只使用其中的一部分（这里我们假设为A区），等这部分用完了，这时候就将这里面还能活下来的对象复制到另一部分内存（这里设为B区）中，然后把A区中的剩下部分全部清理掉。
- 优势：这样一来每次清理都要对一半的内存进行回收操作，这样内存碎片的问题就解决了，可以说简单，高效。
- 缺点：但是呢，肯定发现了，本来挺大一片地方，现在只能用一半，搞得挺不爽的，世界上本来没有免费的饭菜，就算是用空间换取时间吧。
实际应用：CMS新生代的Young GC、G1和ZGC都基于标记-复制算法，但算法具体实现的不同就导致了巨大的性能差异。
2、年轻代GC过程
看完复制算法后，让我们看看虚拟机是如何用复制算法治理新生代的~
年轻代划分
Young Generation ：划分为Eden区和Survivor区，其中Survivor区又分为From区与To区，其中默认Eden : Survivor为8：1。-XX:SurvivorRatio=8
一个对象的这一辈子
我是一个普通的Java对象，我出生在Eden区，在Eden区我还看到和我长的很像的小兄弟，我们在Eden区中玩了挺长时间。有一天Eden区中的人实在是太多了，我就被迫去了Survivor区的“From”区，自从去了Survivor区，我就开始漂了，有时候在Survivor的“From”区，有时候在Survivor的“To”区，居无定所。直到我15（-XX:MaxTenuringThreshold）岁的时候，爸爸说我成人了，该去社会上闯闯了。于是我就去了年老代那边，年老代里，人很多，并且年龄都挺大的，我在这里也认识了很多人。在年老代里，我生活了20年(每次GC加一岁)，然后被回收。
3、MintorGC：
jvm 优化篇-（8）-跨代引用问题(RememberSet、CardTable、ModUnionTable、DirtyCard)<<<<<传送门
4、复制算法痛点分析：
标记-复制算法应用在CMS新生代（ParNew是CMS默认的新生代垃圾回收器）和G1垃圾回收器中。标记-复制算法可以分为三个阶段：
- 标记阶段，即从GC Roots集合开始，标记活跃对象；
- 转移阶段，即把活跃对象复制到新的内存地址上；
- 重定位阶段，因为转移导致对象的地址发生了变化，在重定位阶段，所有指向对象旧地址的指针都要调整到对象新的地址上。
面试常问问题：
-
为何新生代采用复制算法：
这和新生代中的对象生命周期息息相关，新生代对象共同特点朝生夕死，IBM的专门研究表明，新生代中的对象98%是朝生夕死的。
-
SurvivorRatio为何设置为8：
默认Eden和Survivor的大小比例是8∶1，也就是每次新生代中可用内存空间为整个新生代容量的90%（80%+10%），只有10%的内存是会被"浪费"的。
当然，98%的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于10%的对象存活，如果To空间没有足够的空间存放上一次新生代存活的对象，这些对象将直接通过分配担保机制进入老年代。
两个极端分析：
1、设置比例过大，Eden区相对会大，MonitorGC频次就会变少，一次MonitorGC的时间会拉长。From空间与To空间相对较小，这回加快对象老化，从而加快进入老年代时间。（缺点）
2、设置比例过小：
a、From空间与To空间相对会很大，浪费的空间相对会变大。（缺点）
b、Eden区相对会变小，MonitorGC执行频次会增加，MonitorGC执行时间会缩短。Eden区创建对象空间不足，直接通过分配担保机制进入老年代（对象年龄为1的直接进入老年代）。（缺点）
c、To空间变大，意味着可以存储更多在Monitor GC后任存活的对象，避免其进入老年代。（优点）
总结：-XX:SurvivorRatio=8 这个阀值不是绝对的，针对IO密集型的、CPU密集型的，开发人员应该动态调配，没有万能的配置参数来支撑所有应用场景。
Young Generation有关的jvm参数
-XX:NewSize和-XX:MaxNewSize
-XX:SurvivorRatio=8
-XX:NewRatio=3
