一、RDD的容错机制

二、RDD持久化机制

1、RDD持久化（缓存）

2、使用缓存

3、缓存数据的清除

4、持久化理解

三、CheckPoint机制

1、概述

2、示例代码：

3、总结

4、Saprk懒执行的意义

四、GC回收机制及算法

1、概述

2、哪些内存数据需要被回收？

Ⅰ、引用计数法判定

Ⅱ、可达性分析法

3、常见的垃圾回收算法

Ⅰ、标记-清除算法

Ⅱ、复制算法

Ⅲ、标记-整理算法

Ⅳ、分代收集算法

五、GC收集器

1、概述

2、Serial系列收集器

3、ParNew收集器

4、Parallel Scavenge收集器

5、Parallel Old收集器

6、GMS收集器

7、G1 GC（Garbage First）

六、GC的配置

1、常见的4种配置

2、一些配置解释

一、RDD的容错机制

分布式系统通常在一个机器集群上运行，同时运行的几百台机器中某些出问题的概率大大增加，所以容错设计是分布式系统的一个重要能力。

Spark以前的集群容错处理模型，想MapReduce，将计算转换为一个有向无环图（DAG）的任务集合，这样可以通过重复执行DAG里的一部分任务来完成容错恢复。但是由于主要的数据存储在分布式文件系统中，没有其他存储的概念，容错过程需要在网络上进行数据复制，从而增加了大量的消耗。所以，分布式编程中经常需要做检查点，即将某个时机中间数据写到存储（一般是分布式文件系统）中

RDD也是一个DAG，每一个RDD都会记住该数据集需要做哪些操作，跟踪记录RDD的继承关系，这个关系在Spark里面叫lineage（血缘关系）。当一个RDD的某个分区丢失时，RDD是有足够的信息记录其如何通过其他的RDD进行计算，且只需重新计算该分区，这是Spark的一个创新。

二、RDD持久化机制

相比Hadoop MapReduce来说，Spark计算具有巨大的性能优势，其中很大一部分原因是Spark对于内存的充分利用，以及提供的缓存机制。

1、RDD持久化（缓存）

持久化在早期被称为缓存(cache)，但缓存一般指将内容放在内存中。虽然持久化操作在大部分的情况是将RDD缓存在内存中，但是一般都会在内存不够时用磁盘顶上去（比操作系统默认的磁盘交换性能高很多）。当然，也可以选择不使用内存，而是仅仅保存到磁盘中，所以，现在Spark使用持久化这个名字更加广泛。

如果一个RDD不止一次被用到，那么就可以持久化它，这样可以大幅提升程序的性能，甚至达10倍以上。

默认情况下，RDD只使用一次，用完即仍，再次使用时需要重新计算得到，而持久化操作避免了这里的重复计算，实际测试也显示持久化对性能提升明显，这也是Spark刚出现时被人称为内存计算框架的原因。

假设首先进行了RDD0→RDD1→RDD2的计算作业，那么计算结束时，RDD1就已经缓存在系统中了。在进行RDD0→RDD1→RDD3的计算作业时，由于RDD1已经缓存在系统中，因此RDD0→RDD1的转换不会重复进行，计算作业只须进行RDD1→RDD3的计算就可以了，因此计算速度可以得到很大提升。

持久化方法调用persist()函数，除了持久化至内存中，还可以在persist()中指定storage level参数使用其他的类型，具体如下：

①、MEMORY_ONLY：将RDD以反序列化的Java对象的形式存储在JVM中，如果内存空间不够，部分数据分区将不会被缓存，在每次需要用到这些数据时重新进行计算. 这是默认的级别。cache()方法对应的级别就是MEMORY_ONLY级别

②、MEMORY_AND_DISK：将 RDD 以反序列化的 Java 对象的形式存储在 JVM 中。如果内存空间不够，将未缓存的数据分区存储到磁盘，在需要使用这些分区时从磁盘读取。

③、MEMORY_ONLY_SER ：将 RDD 以序列化的 Java 对象的形式进行存储（每个分区为一个 byte 数组）。这种方式会比反序列化对象的方式节省很多空间，尤其是在使用 fast serialize时会节省更多的空间，但是在读取时会使得 CPU 的 read 变得更加密集。如果内存空间不够，部分数据分区将不会被缓存，在每次需要用到这些数据时重新进行计算。

④、MEMORY_AND_DISK_SER ：类似于 MEMORY_ONLY_SER ，但是溢出的分区会存储到磁盘，而不是在用到它们时重新计算。如果内存空间不够，将未缓存的数据分区存储到磁盘，在需要使用这些分区时从磁盘读取。

⑤、DISK_ONLY：只在磁盘上缓存 RDD。

⑥、MEMORY_ONLY_2, MEMORY_AND_DISK_2, etc. ：与上面的级别功能相同，只不过每个分区在集群中两个节点上建立副本。

⑦、OFF_HEAP 将数据存储在 off-heap memory 中。使用堆外内存，这是Java虚拟机里面的概念，堆外内存意味着把内存对象分配在Java虚拟机的堆以外的内存，这些内存直接受操作系统管理（而不是虚拟机）。使用堆外内存的好处：可能会利用到更大的内存存储空间。但是对于数据的垃圾回收会有影响，需要程序员来处理

注意，可能带来一些GC回收问题：

Spark 也会自动持久化一些在 shuffle 操作过程中产生的临时数据（比如 reduceByKey），即便是用户并没有调用持久化的方法。这样做可以避免当 shuffle 阶段时如果一个节点挂掉了就得重新计算整个数据的问题。如果用户打算多次重复使用这些数据，我们仍然建议用户自己调用持久化方法对数据进行持久化。

2、使用缓存

import org.apache.spark.storage._
val rdd1=sc.makeRDD(1 to 5)
rdd1.cache  //cache只有一种默认的缓存级别，即MEMORY_ONLY
rdd1.persist(StorageLevel.MEMORY_ONLY)

3、缓存数据的清除

Spark 会自动监控每个节点上的缓存数据，然后使用 least-recently-used (LRU) 机制来处理旧的缓存数据。如果你想手动清理这些缓存的 RDD 数据而不是去等待它们被自动清理掉，

可以使用 RDD.unpersist( ) 方法。

4、持久化理解

默认情况下，RDD的数据是用完即扔的（会被GC所回收掉），这种默认的机制并不会影响程序的正常执行。但是当分区数据丢失时，会导致较高的重新计算代价。

为了避免上述的问题，Spark的RDD提供了持久化机制。可以将指定的RDD持久化到缓存中或磁盘上，一般是选择持久到缓存中。也可以简单记忆为是RDD的缓存机制。

知识点：

1、RDD缓存方法：①cache ②persist

2、RDD清楚缓存的方法：①unpersist

3、cache和persist方法的区别：cache方法只有一种缓存级别(memory_only)，而persist方法可以指定多种缓存级别。

import org.apache.spark.storage._

import org.apache.spark.SparkConf
import org.apache.spark.SparkContext
import org.apache.spark.storage.StorageLevelobject Driver {def main(args: Array[String]): Unit = {val conf = new SparkConf().setMaster("local").setAppName("persist")val sc = new SparkContext(conf)val data = sc.textFile("hdfs://hadoop01:9000/1.txt")//经验上，可以将数据源RDD缓存，可以避免在数据容错恢复时从文件中读取数据，//即避免产生磁盘I/O，提高性能data.cache()val r1 = data.flatMap{line => line.split(" ")}val r2 = r1.map{word => (word,1)}//persist()默认的缓存机制同cache，是memory_only//也可以通过StorageLevel来指定其他缓存级别//经验上，一般将整个计算链中间位置的RDD进行缓存，此外将产生Shuffle操作的上游RDD缓存r2.persist(StorageLevel.MEMORY_AND_DISK)val r3 = r2.reduceByKey(_+_)r3.foreach(println)//当整个应用程序执行完毕，一定要记得清除缓存data.unpersist()r2.unpersist()}
}

三、CheckPoint机制

1、概述

checkpoint的意思就是建立检查点,类似于快照。

例如：

在spark计算里面，计算流程DAG特别长,服务器需要将整个DAG计算完成得出结果,但是如果在这很长的计算流程中突然中间算出的数据丢失了,

spark又会根据RDD的依赖关系从头到尾计算一遍,这样子就很费性能。

当然我们可以将中间的计算结果通过cache或者persist放到内存或者磁盘中,但是这样也不能保证数据完全不会丢失,存储的这个内存出问题了或者磁盘坏了,也会导致spark从头再根据RDD计算一遍。

所以就有了checkpoint,其中checkpoint的作用就是将DAG中比较重要的中间数据做一个检查点将结果存储到一个高可用的地方

2、示例代码：

object Driver2 {def main(args: Array[String]): Unit = {  val conf=new SparkConf().setMaster("local").setAppName("wordcount")val sc=new SparkContext(conf)// 设置检查点目录路径，可以是本地文件系统，也可以是HDFSsc.setCheckpointDir("hdfs://hadoop01:9000/check01")val data=sc.textFile("d://data/word.txt")data.cache()data.checkpoint()val wordcount=data.flatMap {_.split(" ")}.map {(_,1)}.reduceByKey(_+_)wordcount.cache()wordcount.checkpoint()wordcount.foreach{println}}
}

3、总结

Spark的CheckPoint机制很重要，也很常用，尤其在机器学习中的一些迭代算法中很常见。比如一个算法迭代10000次，如果不适用缓冲机制，如果某分区数据丢失，会导致整个计算链重新计算，所以引入缓存机制。但是光引入缓存，也不完全可靠，比如缓存丢失或缓存存储不下，也会导致重新计算，所以使用CheckPoint机制再做一层保证。

补充：检查目录的路径，一般都是设置到HDFS上

4、Saprk懒执行的意义

Spark中，Transformation方法都是懒操作方法，比如map,flatMap,reduceByKey等。当触发某个Action操作时才真正执行。

懒操作的意义：

①不运行job就触发计算，避免了大量的无意义的计算，即避免了大量的无意义的中间结果的产生，即避免产生无意义的磁盘I/O及网络传输

②更深层次的意义在于，执行运算时，看到之前的计算操作越多，执行优化的可能性就越高

四、GC回收机制及算法

1、概述

说起垃圾收集（Garbage Collection, GC），大部分人都把这项技术当做Java语言的伴生产物。事实上，GC的历史比Java久远，1960年诞生于MIT的Lisp是第一门真正使用内存动态分配和垃圾收集技术的语言。当Lisp还在胚胎时期时，人们就在思考GC需要完成的3件事情：

1）哪些内存数据需要回收？

2）如何回收？

3）具体由哪种收集器回收垃圾？

经过半个多世纪的发展，目前内存的动态分配与内存回收技术已经相当成熟，一切看起来都进入了“自动化”时代，那为什么我们还要去了解GC和内存分配呢？答案很简单：当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就需要对这些“自动化”的技术实施必要的监控和调节。

在JAVA中。Java内存运行时区域的各个部分，其中程序计数器、虚拟机栈、本地方法栈3个区域随线程而生，随线程而灭，因此这几个区域的内存分配和回收都具备确定性，在这几个区域内就不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。而Java堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，所以垃圾收集器所关注的是java的堆内存。

2、哪些内存数据需要被回收？

在堆里面存放着Java世界中几乎所有的对象实例，垃圾收集器在对堆进行回收前，第一件事情就是要确定这些对象之中哪些还“存活”着，哪些已经“死去”（即不可能再被任何途径使用的对象）。

那么如何判定哪些数据是垃圾数据呢？

Ⅰ、引用计数法判定

每个对象创建时，为此对象分配一个引用计数器。每当有其他对象引用此对象，则它的计数器+1.如果引用失效，计数器-1.当计数器为0时，则此对象被标记为垃圾对象，下次GC将其清理掉。

此种判定方法的优点：原理简单，底层容易实现。

缺点：不能解决对象之间的循环引用问题容易造成内存泄露。比如：

String a = "hello"
String b = "world"
a=b
b=a

上例中，由于对下个之间的循环调用，导致这两个的计数器永不为0，导致不能被GC收掉，一直驻留在缓存中，造成内存泄漏。

Ⅱ、可达性分析法

这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连（用图论的话来说，就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。

判断对象到GC Roots是否有相连的引用链，如果没有，则此对象为垃圾对象。比如上图中的对象5，6，7.能成为GC Roots的对象肯定都是常用或有用的对象。

在Java语言中，可作为GC Roots的对象包括下面几种：

1）虚拟机栈（栈帧中的本地变量表）中引用的对象。

2）方法区中类静态属性引用的对象。

3）方法区中常量引用的对象。

3、常见的垃圾回收算法

Ⅰ、标记-清除算法

最基础的收集算法是”标记-清除“（Mark-Sweep）算法，如同它的名字一样，算法分为”标记“和”清除“两个阶段：首先标记处所有需要回收的对象，在标记完成后统一回收所有被标记的对象

优点：此算法原理简单而且回收垃圾数据的效率较高

缺点：一个是效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。回收数据后，会产生大量的内存碎片，导致内存环境质量下降。

结果是当分配一个较大对象时，很可能找不到一块足够的连续的内存空间，则不得不提前触发下一次GC，而这一次的GC极有可能就是一次Full GC（全堆GC），但是并不是我们希望看到的（在GC调优中，其中一个目的就是尽量减少Full GC的出现或延迟Full GC的到来）

虚拟内存技术——用磁盘空间当做内存，可以将一部分不常用的内存数据交换到磁盘上，待用时，再从磁盘上进行恢复。但一般在使用技术框架时，会避免此情况产生，主要是为了避免磁盘I/O。比如使用Linux时，关闭Swap分区

Ⅱ、复制算法

为了解决碎片问题，一种称为“复制”（Copying）的收集算法出现了，

它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。

只是这种算法的代价是将内存缩小为了原来的一半，未免太高了一点。

改进后，即解决了内存碎片问题，也提高了内存利用率，达到了90%。其中，有一个比较重要的结论:新生代中的对象98%是"朝生夕死"的，所以并不需要按照1：1的比例来划分内存空间

补充：

①、对于新生代GC，称为Minor GC，发生了频率较高

②、对于老生代的GC，称为Major GC（Full GC），即发生Full GC，是全堆GC，所以时间相对较长

③、当新生代中的对象存活一定次数后，可以晋升到老生代。提示的临界是15次（可调整）

④、我们不希望经常发生Full GC，所以GC调优其中的一个目的是要减少Full GC的出现或延缓Full GC的到来

Ⅲ、标记-整理算法

标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存，“标记-整理”算法的示意如下图所示。

优点：清理完数据后，会对碎片进行整理，避免内存质量下降的我呢提

缺点：相比于MarkSweep，效率较低

Ⅳ、分代收集算法

当前商业虚拟机的垃圾收集都采用“分代收集”（Generational Collection）算法，这种算法并没有什么新的思想，只是根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。

在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记—清理”或者“标记—整理”算法来进行回收。

五、GC收集器

1、概述

用于回收垃圾数据，

上图展示了7种作用于不同分代的收集器，如果两个收集器之间存在连线，就说明它们可以搭配使用。虚拟机所处的区域，则表示它是属于新生代收集器还是老年代收集器。

Serial ParNew ParallelScanenge收集新生代数据，其它除G1比较特殊，即可回收新生代也可回收老生代，

两个收集器之间有连线，表示可以配合使用，如：ParNew和CMS可以一起使用

2、Serial系列收集器

这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。

Stop The World：这项工作实际上是由虚拟机在后台自动发起和自动完成的，在用户不可见的情况下把用户正常工作的线程全部停掉，设计者也表示：“你妈妈打扫房间的时候，也会要求你坐在板凳上或者出去。”

它也有着优于其他收集器的地方：简单而高效（与其他收集器的单线程比），Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。

3、ParNew收集器

ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数（例如：-XX:SurvivorRatio、-XX:PretenureSizeThreshold、-XX:HandlePromotionFailure等）、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样，在实现上，这两种收集器也共用了相当多的代码。ParNew收集器的工作过程如下图所示。

注意：有必要先解释两个名词：并发和并行。这两个名词都是并发编程中的概念，在谈论垃圾收集器的上下文语境中，它们可以解释如下。

并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。

并发（Concurrent）：指用户线程与垃圾收集线程同时工作，可能会交替执行，用户程序不必一直等待。

ParNew回收效率高，产生停顿短，还可以与CMS配合使用。CMS比较出名，停顿时间最短。

4、Parallel Scavenge收集器

Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器，看上去和ParNew都一样，那它有什么特别之处呢？

Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。所以，也称之为吞吐量优先收集器。

主要适合在后台运算而不需要太多交互的任务。

Spark默认用的是Parallel Scavenge收集器。

由于与吞吐量关系密切，Parallel Scavenge收集器也经常称为“吞吐量优先”收集器。

自适应调节策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。

5、Parallel Old收集器

Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。这个收集器是在JDK 1.6中才开始提供的。

Parallel Old收集器出现后，“吞吐量优先”收集器终于有了比较名副其实的应用组合，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。

6、GMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。

从名字（包含“Mark Sweep”）上就可以看出，CMS收集器是基于“标记—清除”算法实现的，它的运作过程相对于前面几种收集器来说更复杂一些，整个过程分为4个步骤，包括：

1）初始标记（CMS initial mark）产生停顿

2）并发标记（CMS concurrent mark）并发和工作线程一同工作

3）重新标记（CMS remark）产生停顿，为了修正并发标记阶段引起的引用链发生变化

4）并发清除（CMS concurrent sweep）并发和工作线程一同工作

其中，1）初始标记、2）重新标记这两个步骤仍然需要“Stop The World”。

初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快。

并发标记阶段就是进行GC RootsTracing的过程。CMS收集器允许在并发标记阶段，用户线程是可以继续工作，所以这个过程可能会导致GC Roots的路径规则发生变化，所以需要下一个阶段重新标记去进行修正。

重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些。

由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。

CMS是一款优秀的收集器，它的主要优点在名字上已经体现出来了：并发收集、低停顿，Sun公司的一些官方文档中也称之为并发低停顿收集器（Concurrent Low Pause Collector）。

优点：回收效率高，停顿时间短

缺点：

①、底层使用的是Mark Sweep（标记-清除）算法回收垃圾，虽然很高效，但是会产生内存碎片，所以需要定期进行碎片整理

②、会产生浮动垃圾（一边清除一边产生的垃圾），导致这些浮动垃圾需要等到下一次GC才会被回收掉

③、GMS是多线程收集器（可以配置），垃圾回收线程和用户线程一同工作，即共同抢占CPU时间片，可能在一定程度上降低用户工作线程的效率

7、G1 GC（Garbage First）

是JDK1.7之后开始商用的，是目前java最新的收集器，G1 GC设计的初衷是要结合GMS和Parallel各自的优点，既要达到低延迟，又要达到高吞吐量

G1 GC放弃了传统的思路，对整个堆不在进行新老分区，而是将整个堆划分为一个个的小区域块，每个区域快根据功能不同被标记：Eden，Survivor，Old

上图是G1 GC的示意图，可以得到以下结论：

1、G1 GC的内存利用率极高（利用了整个堆内存空间），集群内存越大，G1 GC的优势越明显

2、 G1 GC触发Full GC的条件是当整个堆找不到全空区域快时，才会发生Full GC，即G1 GC发生Full GC的频率会更低

3、G1 GC可以通过配置灵活的指定区域快大小，最小1MB，最大32MB

4、G1 GC针对每一个区域快会建立RememberSet，存储当前区域快中对象的引用链关系，可以避免在整个堆中扫描引用链关系，提高性能，并使得每个区域快的GC更加独立。

假天花板的概念：比如可用内存100GB,假天花板是10%，意味着G1最多能用90GB

六、GC的配置

1、常见的4种配置

①、 SerialGC

参数-XX:+UseSerialGC

就是Young区和old区都使用serial 垃圾回收算法

②、ParallelGC

参数-XX:+UseParallelGC

Young区：使用Parallel scavenge 回收算法

Old 区：可以使用单线程的或者Parallel 垃圾回收算法，由 -XX:+UseParallelOldGC 来控制

③、 CMS

参数-XX:+UseConcMarkSweepGC

Young区：可以使用普通的或者parallel 垃圾回收算法，由参数 -XX:+UseParNewGC来控制

Old 区：只能使用Concurrent Mark Sweep

④、G1

参数：-XX:+UseG1GC

没有young/old区

2、一些配置解释

-XX:+UseG1GC 使用 G1 (Garbage First) 垃圾收集器

-XX:MaxGCPauseMillis=n 设置最大GC停顿时间(GC pause time)指标(target). 这是一个软性指标(soft goal), JVM 会尽量去达成这个目标.

-XX:InitiatingHeapOccupancyPercent=n 启动并发GC周期时的堆内存占用百分比. G1之类的垃圾收集器用它来触发并发GC周期,基于整个堆的使用率,而不只是某一代内存的使用比. 值为 0 则表示"一直执行GC循环". 默认值为 45.

这个参数是一个常用的GC调优参数，上面的百分比控制的Minor GC的百分比

可以适当调低此参数，提高MinorGC的频次，从而延迟FullGC的到来

-XX:NewRatio=n 老生代与新生代(old/new generation)的大小比例(Ratio). 默认值为 2.如果是G1GC，此参数无效

-XX:SurvivorRatio=n eden/survivor 空间大小的比例(Ratio). 默认值为 8.如果是G1GC，此参数无效

-XX:MaxTenuringThreshold=n 提升老年代的最大临界值(tenuring threshold). 默认值为 15.

-XX:ParallelGCThreads=n 设置垃圾收集器在并行阶段使用的线程数,默认值随JVM运行的平台不同而不同.一般设置的数量=服务器的核数

-XX:ConcGCThreads=n 并发垃圾收集器使用的线程数量. 默认值随JVM运行的平台不同而不同(调节CMS）

-XX:G1ReservePercent=n 设置堆内存保留为假天花板的总量,以降低提升失败的可能性. 默认值是 10.

-XX:G1HeapRegionSize=n 使用G1时Java堆会被分为大小统一的的区(region)。此参数可以指定每个heap区的大小. 默认值将根据 heap size 算出最优解. 最小值为 1Mb, 最大值为 32Mb.

大数据笔记--Spark（第四篇）相关推荐

大数据之Spark（四）：Spark SQL
一.SparkSQL的发展 1.1 概述 SparkSQL是Spark⽣态体系中的构建在SparkCore基础之上的⼀个基于SQL的计算模块. SparkSQL的前身不叫SparkSQL,⽽叫Shar ...
大数据笔记9—java基础篇5（API)
java_API API String类创建字符串对象的区别对比 String字符串的特点字符串的比较例题(String) 例题1. 模拟登陆例题2遍历字符串例题3.案例 :统计字符次数例 ...
大数据笔记--SparkSQL（第一篇）
目录一.Spark Sql 1.概述 2.由来 3.Spark SQL特点 4.为什么SparkSQL的性能会的得到这么大的提升? Ⅰ.内存列存储二.SparkSql入门 1.概述 2.创建Dat ...
大数据笔记8—java基础篇4（面向对象-封装-继承-多态）
面向对象一.面向对象 1.面向过程 1.2.举例 1.3.总结二.面向对象 1.简述 2.举例 3.思想特点 2.1.类的定义格式 2.1.1.简述 2.2.2.格式 2.3.3.示例三.类的使 ...
大数据笔记10—java基础篇6（集合1-Collection)
集合集合(Collection) 一.迭代器<iterator> 案例一二.并发修改异常三.Collection集合案例一(Collection练习) 案例二(Collection ...
大数据笔记30—Hadoop基础篇13(Hive优化及数据倾斜)
Hive优化及数据倾斜知识点01:回顾知识点02:目标知识点03:Hive函数:多行转多列知识点04:Hive函数:多行转单列知识点05:Hive函数:多列转多行知识点06:Hive函数: ...
大数据笔记16—java基础篇12（JDBC 、连接池、事务)
目录 JDBC jdbc概述 jdbc入门案例 API详解 jdbc工具类预编译执行平台 1.SQL注入问题(安全问题) 2API详解:预处理对象(PreparedStatement) 使用连接池重 ...
大数据笔记11—java基础篇7（集合2-Map)
目录Map Map集合 2.1 Map入门 2.2 Map集合的成员方法 Collections类斗地主案例苟有恒,何必三更眠五更起: 最无益,莫过一日曝十日寒. Map集合概述: Map集合是 ...
尚硅谷大数据技术Spark教程-笔记02【SparkCore（核心编程，map、mapPartitions、mapPartitionsWithIndex、flatMap、glom、groupBy）】
视频地址:尚硅谷大数据Spark教程从入门到精通_哔哩哔哩_bilibili 尚硅谷大数据技术Spark教程-笔记01[Spark(概述.快速上手.运行环境.运行架构)] 尚硅谷大数据技术Spark教 ...

大数据笔记--Spark（第四篇）

一、RDD的容错机制

二、RDD持久化机制

1、RDD持久化（缓存）

2、使用缓存

3、缓存数据的清除

4、持久化理解

三、CheckPoint机制

1、概述

2、示例代码：

3、总结

4、Saprk懒执行的意义

四、GC回收机制及算法

1、概述

2、哪些内存数据需要被回收？

Ⅰ、引用计数法判定

Ⅱ、可达性分析法

3、常见的垃圾回收算法

Ⅰ、标记-清除算法

Ⅱ、复制算法

Ⅲ、标记-整理算法

Ⅳ、分代收集算法

五、GC收集器

1、概述

2、Serial系列收集器

3、ParNew收集器

4、Parallel Scavenge收集器

5、Parallel Old收集器

6、GMS收集器

7、G1 GC（Garbage First）

六、GC的配置

1、常见的4种配置

2、一些配置解释

大数据笔记--Spark（第四篇）相关推荐

最新文章

热门文章