-
在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一般会增加23倍的大小，我们希望在同一个工作进程中可以有34个task，并且HDFS的block大小为128MB，所以可以得到预估值E Eden值 （34*128MB）
6: 设置完之后，在监控gc stats的信息是否有多改变
PS：监控gc的情况 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps to the Java options.对于新生代回收的一行日志，其基本内容如下：
2014-07-18T16:02:17.606+0800: 611.633: [GC 611.633: [DefNew: 843458K->2K(948864K), 0.0059180 secs] 2186589K->1343132K(3057292K), 0.0059490 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
其含义大概如下：
2014-07-18T16:02:17.606+0800（当前时间戳）: 611.633（时间戳）: [GC（表示Young GC） 611.633: [DefNew（单线程Serial年轻代GC）: 843458K（年轻代垃圾回收前的大小）->2K（年轻代回收后的大小）(948864K（年轻代总大小）), 0.0059180 secs（本次回收的时间）] 2186589K（整个堆回收前的大小）->1343132K（整个堆回收后的大小）(3057292K（堆总大小）), 0.0059490 secs（回收时间）] [Times: user=0.00（用户耗时） sys=0.00（系统耗时）, real=0.00 secs（实际耗时）]
老年代回收的日志如下：
2014-07-18T16:19:16.794+0800: 1630.821: [GC 1630.821: [DefNew: 1005567K->111679K(1005568K), 0.9152360 secs]1631.736: [Tenured:
2573912K->1340650K(2574068K), 1.8511050 secs] 3122548K->1340650K(3579636K), [Perm : 17882K->17882K(21248K)], 2.7854350 secs] [Times: user=2.57 sys=0.22, real=2.79 secs]
gc日志中的最后貌似是系统运行完成前的快照：
Heap
def new generation total 1005568K, used 111158K [0x00000006fae00000, 0x000000073f110000, 0x0000000750350000)
eden space 893888K, 12% used [0x00000006fae00000, 0x0000000701710e90, 0x00000007316f0000)
from space 111680K, 3% used [0x0000000738400000, 0x000000073877c9b0, 0x000000073f110000)
to space 111680K, 0% used [0x00000007316f0000, 0x00000007316f0000, 0x0000000738400000)
tenured generation total 2234420K, used 1347671K [0x0000000750350000, 0x00000007d895d000, 0x00000007fae00000)
the space 2234420K, 60% used [0x0000000750350000, 0x00000007a2765cb8, 0x00000007a2765e00, 0x00000007d895d000)
compacting perm gen total 21248K, used 17994K [0x00000007fae00000, 0x00000007fc2c0000, 0x0000000800000000)
the space 21248K, 84% used [0x00000007fae00000, 0x00000007fbf92a50, 0x00000007fbf92c00, 0x00000007fc2c0000)
No shared spaces configured.