在java heap 空间中会分成两个区域 Young 和Old，Young部分主要存储的是 存活时间短的对象；而Old 部分主要保存的是存在时间更长对象

Young 部分又可以细分成三部分，分别为 Eden、Survivor1、Survivor2

简单描述下gc的过程：当Eden部分满，就触发一次在Eden上的小GC，将在Eden和Survivor1上的对象 拷贝到Surviv2，Survivor 区域会做切换。如果一个对象已经存在足够时间或Survivor2的空间满了，那就将对象挪到Old 区域。最终当Old区域快要消耗完时就触发 完整GC，会比较耗性能

• 在Spark的gc优化目标，确保长时间保留保留的RDDs被存储在Old 区域，在Young 区域有足够的空间来存储短时间存储的对象。尽量避免在task execution中产生的临时对象触发 full GC，可以采用以下几步设置来优化

1: 通过观察GC stats查看是是否再task还没结束前有多次的full GC，如果发现很多次，就表示执行task时内存不足
2: 在GC stats中，如果发现小gc触发次数比较多，就需要增加Eden区域的大小来优化。你可以设置一个超过task需要的内存数来设置Eden部分的大小。假设该预估值为E，你就可以设置Young 区域的大小 -Xmn=4/3E （扩展到4/3 因为还需要考虑到Survivor部分的）
3: 通过查看gc stats 发现OldGen部分的空间接近消耗完，减少缓存内存总量 spark.memory.fraction；通过缓存更少的对象，降低task执行速度。或 考虑减少Young区域的小大，如果上面有设置过-Xmn值，那就适当的减少该值。如果没有变更多-Xmn值就试着修改JVM的NewRatio参数，绝大部分JVM 中设置的默认值2，意思是说Old 部分占整个heap的2/3,它必须做够大要超过spark.memory.fraction的值
4: 开启G1GC 通过 -XX:+UseG1GC选项，在gc成为瓶颈的时候可以显著提升性能。注意在需要执行消耗过多内存的任务时，增加G1 region 的大小会非常关键 —XX:G1HeapRegionSize
5: 举一个例子，当你的task是从HDFS中读取数据，一个task需要消耗多少内存可以通过HDFS的block大小来预估，注意解压后的block一般会增加2_{3倍的大小，我们希望在同一个工作进程中可以有3}4个task，并且HDFS的block大小为128MB，所以可以得到预估值E Eden值 （34*128MB）
6: 设置完之后，在监控gc stats的信息是否有多改变

PS：监控gc的情况  -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps to the Java options.