为什么我们需要调GC
如果是在以前，ETL为王的年代，我们其实大可不必去调试，使用默认的 Parallel GC就可以了。但是随着发展，实时流计算以及AdHoc查询，对JVM的要求：高吞吐低延迟，又变得非常重要。和传统Web不同，通常如果一个JVM发生Full GC,仅仅会影响当前到访问这个JVM的用户的响应。而对于Spark这种，一个用户的一个查询有可能会发生在所有的JVM身上，这意味着有任何一个JVM发生了Full GC都会导致极大的延迟。就如同海量服务器几乎时刻有可能发生硬盘损坏，而足够多的Executor也会使得几乎每次查询都能遇到Full GC。Parallel GC长达几十秒甚至分钟级别的Full GC 会使得即席查询化为泡影。
所以对于流式计算以及AdHoc查询，优化GC是必选项。
GC调优文章推荐
因为现阶段，相当部分的用户应该还在使用Spark 2.x 以及JDK8. JDK8 可选择不多，基本意味着你只有CMS以及G1可选。
CMS/G1都有较多的参数控制，这是优势也是缺点，缺点是你需要不断尝试直到找到适合你的参数，并且你还需要了解每个参数背后的含义。
这里推荐一篇文章：[为你的spark程序调优JAVA垃圾回收](https://xinze.fun/2020/01/11/为你的spark程序调优JAVA垃圾回收/) 该文翻译自数砖15年的一篇[博文](https://databricks.com/blog/2015/05/28/tuning-java-garbage-collection-for-spark-applications.html). 尽管五年过去了，我个人认为价值还是很大的。如果复制不方便，你也可以点击原文。
还有一个更好的选择
JDK 14中的ZGC 已经比较稳定了，ZGC也是近些年GC发展的最新成果，我个人认为是划时代的。ZGC有朋友实测效果非常好，55G的堆，可控制在10ms，通常3ms左右。缺点是Spark 3.0之前还不支持JDK 14，尽管你可以做一些修改使得当前的Spark(2.4.x)能够运行在JDK 14上。另外如果你使用到了老的版本的Guava库（<16）中的ClassPath,那么也可能无法正确的运行在JDK 14上。