卡顿优化的重中之重“垃圾回收算法“，万文肝货

一、什么是垃圾回收？

垃圾回收，也叫GC(Garbage Collection)，指的是释放垃圾占用的空间，防止内存泄露。有效的使用可以使用的内存，对内存堆中已经死亡的或者长时间没有使用的对象进行清除和回收。

JVM的内存区域主要分为程序计数器、虚拟机栈、本地方法栈、方法区、堆。那么哪个才是GC作用的区域呢？答案是堆区，前面几块数据区域都不进行 GC。对象实例和数组都是在堆上分配的，GC 也主要对这两类数据进行回收。

二、判断什么是垃圾？

所谓垃圾就是内存中已经没有用的对象。 既然是”垃圾回收"，那就必须知道哪些对象是垃圾。Java 虚拟机中使用一种叫作可达性分析的算法来决定对象是否可以被回收。

可达性分析

JVM 把内存中所有的对象之间的引用关系看作一张图，通过一组名为”GC Root"的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，最后通过判断对象的引用链是否可达来决定对象是否可以被回收。如下图所示：

注意：上图中圆形图标虽然标记的是对象，但实际上代表的是此对象在内存中的引用。包括 GC Root 也是一组引用而并非对象。

GC Root 对象

在 Java 中，有以下几种对象可以作为 GC Root：

1. Java 虚拟机栈（局部变量表）中的引用的对象。
2. 方法区中静态引用指向的对象。
3. 仍处于存活状态中的线程对象。
4. Native 方法中 JNI 引用的对象。

注意：全局变量同静态变量不同，它不会被当作 GC Root。

什么时候回收

不同的虚拟机实现有着不同的 GC 实现机制，但是一般情况下每一种 GC 实现都会在以下两种情况下触发垃圾回收。

1. Allocation Failure：在堆内存中分配时，如果因为可用剩余空间不足导致对象内存分配失败，这时系统会触发一次 GC。
2. System.gc()：在应用层，Java 开发工程师可以主动调用此 API 来请求一次 GC。

如何回收垃圾

由于垃圾收集算法的实现涉及大量的程序细节，各家虚拟机厂商对其实现细节各不相同，因此并不会过多的讨论算法的实现，只是介绍几种算法的思想以及优缺点。

三、垃圾回收算法

虚拟机在对对象进行回收前，需要对垃圾进行采集，不同的虚拟机实现可能使用不同的垃圾收集算法，不同的收集算法的实现也不尽相同。不同的算法各有各的优劣势。

1.标记-清除算法 MARK-SWEEP

Mark-Sweep 算法分为标记和清除两个部分，会先标记出所有需要回收的对象，然后统一进行回收。

缺点：
Mark-Sweep 算法的标记和清除过程效率都不高。另外， Mark-Sweep 算法没有进行对象的移动，只是单纯的进行对象回收，这样很容易造成内存碎片。

如上图，如果这时候我们需要创建一个 10 格子大小的内存对象，虽然有足够的内存空间，但是没有连续的 10 个格子内存，这时候是无法申请下来的，OOM。

2.复制算法 COPYING

Copying 算法是将内存分成相等的两块区域，然后使用其中的一块。当这块内存不足时候，将存货的对象复制到另一块上，然后清除已使用的这块上所有对象。

缺点：
这样虽然不会产生内存碎片这种问题，但是他的缺点也很明显：内存只有原来的一半。特别是当被使用的一半内存中，对象存活率较高的时候，需要复制的对象，以及复制的次数增加，导致效率低下。

如果不想浪费 50% 的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都 100% 存活的极端情况。

3.标记整理算法 MARK-COMPACT

考虑到 Copying 算法会浪费一半的内存，出现了 Mark-Compact 算法。用 Mark-Sweep 算法中的标记过程，然后让所有存活的对象移到一端，然后直接清理掉端边界以外的内存。

缺点：
Mark-Compact 算法虽然没有内存碎片问题，也不会浪费一半内存，但是它也引用了额外的开销，比如说额外的空间来保存迁移地址，需要遍历多次堆内存等。

四、分代收集算法

Android进阶性能优化大全解析，希望大家都能学到这里面的知识点。
无论是一般的 JVM 还是 DVM，不会只使用一种垃圾收集算法。它会根据内存的划分实现不同的收集算法。基于不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。

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

在 Java 程序运行的过程中，会产生大量的对象，因每个对象所能承担的职责不同所具有的功能不同所以也有着不一样的生命周期，有的对象生命周期较长，比如 Android中 的 Application、启动的 Service等；有的对象生命周期较短，比如一些函数内部 new 出来的 String 对象。

1.新生代 YOUNG GENERATION

现在的商业虚拟机都采用 Copying 算法来回收新生代，IBM 公司的专门研究表明，新生代中的对象 98% 是“朝生夕死”的，所以并不需要按照1:1的比例来划分内存空间。

1.新生代内存按照 8:1:1 的比例分为一个 Eden Space （亚丹）区和两个 Survivor（夏娃）区，From Space 和 To Space。

2.新建的对象都是在新生代分配内存。

• 首先，每次使用 Eden 区和一块 Survivor 区 From Space。（即每次新生代可用内存为 90%）
• 当 Eden 和 From Space 满时，触发新生代回收 Minor GC ，将 Eden 和 From Space 中还存活着的对象一次性地复制到 To Space 空间上，最后清理掉 Eden 和刚 From Space 空间。然后交换 From Space 和 To Space。
• 每一次 Minor GC，把存活下来的对象年龄 +1，当某个对象的年龄达到老年的标准，就移到老年代中。

3.上面的 98% 的对象可回收只是一般场景下的数据，我们没有办法保证每次回收都只有不多于 10% 的对象存活，当Survivor 空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion），这些对象将直接通过分配担保机制进入老年代。

4.通过担保，如果这时候老年代内存也满了，会触发老年代的回收。新生代和老年代一起回收（Full GC）。

5.新生代采用 Copying 算法。

2.老年代 OLD GENERATION

1.用于存放新生代中经过 N 次垃圾回收仍然存活的对象，以及 To From 不足时候，担保的对象。

2.内存比新生代也大很多(大概比例是1:2)。

3.当老年代内存满时触发回收 Major GC 。

4.老年代采用 Mark-Compact 算法。

3.永久代 PERMANENT GENERATION

1.主要存放所有已加载的类信息，方法信息，常量池等等。

2.并不等同于方法区，只不过是主流的 Sun 公司的 Hotspot JVM 用永久代来实现方法区而已，有些虚拟机没有永久带而用其他机制来实现方法区。

3.这个区域存放的内容与垃圾回收要回收的Java对象关系并不大。

五、垃圾收集器

垃圾回收器是内存回收的实践者。不同的垃圾回收器有不同的特性，并没有一个万能或最好的垃圾回收器，只能根据不同的业务场景选择最合适的垃圾回收器，所以这节就来了解下各个垃圾回收器的特性。

1、Stop The World（STW）

先看看jvm的 “Stop The World” 问题。

1）STW：

可达性分析算法从 GC Roots 集合找引用链时，需要枚举根节点，然后从根节点标记存活的对象，根节点枚举以及整理内存碎片时，都会发生 Stop The World，此时 jvm 会直接暂停应用程序的所有用户线程，然后进行垃圾回收。因为垃圾回收时如果还在继续创建对象或更新对象引用，就会导致这些对象可能无法跟踪和回收、跟节点不断变化等比较复杂的问题，因此垃圾回收过程必须暂停所有用户线程，进入 STW 状态。垃圾回收完成后，jvm 会恢复应用程序的所有用户线程。

所有垃圾回收器都无法避免 STW，只能尽量缩短用户线程的停顿时间。系统停顿期间，无法处理任何请求，所有用户请求都会出现短暂的卡顿。如果因为内存分配不合理或垃圾回收器使用不合理，导致频繁的垃圾回收，而且每次回收系统停顿时间过长，这会让用户体验极差。jvm 最重要的一个优化就是通过合理的内存分配，使用合适的垃圾回收器，使得垃圾回收频率最小、停顿时间最短，避免影响系统正常运行。

2）安全点（Safe Point）：

用户程序执行时并非在代码指令流的任意位置都能够停顿下来开始垃圾收集，而是强制要求必须执行到达安全点后才能够暂停。安全点可以理解成是在代码执行过程中的一些特殊位置，当线程执行到这些位置的时候，说明虚拟机当前的状态是安全的，如果有需要，可以在这个位置暂停。

安全点位置的选取基本上是以“是否具有让程序长时间执行的特征”为标准进行选定的，“长时间执行”的最明显特征就是指令序列的复用，例如方法调用、循环跳转、异常跳转等都属于指令序列复用，所以只有具有这些功能的指令才会产生安全点。

jvm 采用主动式中断的方式，在垃圾回收发生时让所有线程都跑到最近的安全点。主动式中断的思想是当垃圾回收需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志位，各个线程执行过程时会不停地主动去轮询这个标志，一旦发现中断标志为真时就自己在最近的安全点上主动中断挂起。

3）安全区域（Safe Region）：

安全点机制保证了程序执行时，在不太长的时间内就会遇到可进入垃圾回收过程的安全点。但是，程序“不执行”的时候，线程就无法响应虚拟机的中断请求，如用户线程处于Sleep状态或者Blocked状态，这个时候就没法再走到安全的地方去中断挂起自己。这就需要安全区域来解决了。

安全区域是指能够确保在某一段代码片段之中，引用关系不会发生变化，因此，在这个区域中任意地方开始垃圾回收都是安全的。当用户线程执行到安全区域里面的代码时，首先会标识自己已经进入了安全区域，那样当这段时间里虚拟机要发起垃圾回收时就不必去管这些已声明自己在安全区域内的线程了。当线程要离开安全区域时，它要检查虚拟机是否已经完成了需要暂停用户线程的阶段，如果完成了，那线程就继续执行；否则它就必须一直等待，直到收到可以离开安全区域的信号为止。

2、Serial 垃圾回收器

Serial 垃圾回收器是一个单线程回收器，它进行垃圾回收时，必须暂停其他所有用户线程，直到它回收结束。Serial 主要用于新生代垃圾回收，采用复制算法实现。

服务端程序几乎不会使用 Serial 回收器，服务端程序一般会分配较大的内存，可能几个G，如果使用 Serial 回收器，由于是单线程，标记、清理阶段就会花费很长的时间，就会导致系统较长时间的停顿。

Serial 一般用在客户端程序或占用内存较小的微服务，因为客户端程序一般分配的内存都比较小，可能几十兆或一两百兆，回收时的停顿时间是完全可以接受的。而且 Serial 是所有回收器里额外消耗内存最小的，也没有线程切换的开销，非常简单高效。

3、Serial Old 垃圾回收器

Serial Old 是 Serial 的老年代版本，它同样是一个单线程回收器，主要用于客户端程序。Serial Old 用于老年代垃圾回收，采用标记-整理算法实现。

Serial Old 也可以用在服务端程序，主要有两种用途：一种是与 Parallel Scavenge 回收器搭配使用，另外一种就是作为 CMS 回收器发生失败时的后备预案，在并发收集发生 Concurrent Mode Failure 时使用。

4、ParNew 垃圾回收器

ParNew 回收器实质上是 Serial 回收器的多线程并行版本，除了同时使用多条线程进行垃圾收集之外，其余的行为都与 Serial 回收完全一致，控制参数、回收算法、对象分配规则等都是一致的。除了 Serial 回收器外，目前只有 ParNew 回收器能与 CMS 回收器配合工作，ParNew 是激活CMS后的默认新生代回收器。

ParNew 默认开启的回收线程数与处理器核心数量相同，在处理器核心非常多的环境中，可以使用 -XX: ParallelGCThreads 参数来限制垃圾回收的线程数。

5、Parallel Scavenge 垃圾回收器

Parallel Scavenge是新生代回收器，采用复制算法实现，也是能够并行回收的多线程回收器。Parallel Scavenge 主要关注可控制的吞吐量，其它回收器的关注点是尽可能地缩短垃圾回收时的停顿时间。吞吐量就是处理器用于运行程序代码的时间与处理器总消耗时间的比值，总消耗时间等于运行程序代码的时间加上垃圾回收的时间。

Parallel Scavenge 提供了两个参数用于精确控制吞吐量：

-XX: MaxGCPauseMillis：控制最大垃圾回收停顿时间，参数值是一个大于0的毫秒数，回收器将尽力保证垃圾回收花费的时间不超过这个值。
-XX: GCTimeRatio：直接设置吞吐量大小，参数值是一个大于0小于100的整数，就是垃圾回收时间占总时间的比率。默认值为 99，即允许最大1%（即1/(1+99)）的垃圾收集时间。
Parallel Scavenge 还有一个参数 -XX: +UseAdaptiveSizePolicy，当设置这个参数之后，就不需要人工指定新生代的大小、Eden与Survivor区的比例等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量。

6、Parallel Old 垃圾回收器

Parallel Old 是 Parallel Scavenge 的老年代版本，支持多线程并发回收，采用标记-整理算法实现。在注重吞吐量或者处理器资源较为稀缺的场合，可以优先考虑 Parallel Scavenge 加 Parallel Old 这个组合。

7、CMS 垃圾回收器

CMS（Concurrent Mark Sweep）是一种以获取最短回收停顿时间为目标的回收器。CMS 用于老年代垃圾回收，采用标记-清除算法实现。

1）CMS 回收过程：

CMS 垃圾回收总体分为四个步骤：

1）初始标记（会STW）：

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

2）并发标记：

并发标记阶段就是从 GC Roots 的直接关联对象开始遍历整个对象引用链的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾回收线程一起并发运行。

3）重新标记（会STW）：

重新标记需要 Stop The World，重新标记阶段是为了修正并发标记期间，因程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短。

4）并发清除：

清除阶段是清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发进行的。

最耗时的并发标记和并发清除阶段是和用户线程并发进行的，总体上来说，CMS 回收过程是与用户线程一起并发执行的，是一款并发低停顿的回收器。

2）触发CMS的条件

CMS GC 在实现上分成 foreground collector 和 background collector。

① foreground collector

foreground collector 触发条件比较简单，一般是遇到对象分配但空间不够，就会直接触发 GC，来立即进行空间回收。采用的算法是 mark sweep，不压缩。

② background collector

background collector 是通过 CMS 后台线程不断的去扫描，过程中主要是判断是否符合 background collector 的触发条件，一旦有符合的情况，就会进行一次 background 的 collect。每次扫描过程中，先等 CMSWaitDuration 时间（默认2秒），然后再判断是否满足 background collector 的触发条件。

background collector 的触发条件：

并行 Full GC，如调用了 System.gc()
未配置 UseCMSInitiatingOccupancyOnly 时，会根据统计数据动态判断是否需要进行一次 CMS GC。如果预测 CMS GC 完成所需要的时间大于预计的老年代将要填满的时间，则进行 GC。这些判断是需要基于历史的 CMS GC 统计指标，第一次 CMS GC 时，统计数据还没有形成，是无效的，这时会跟据 Old Gen 的使用占比来判断是否要进行 GC。
未配置 UseCMSInitiatingOccupancyOnly 时，判断 CMS 的使用率大于 CMSBootstrapOccupancy（默认50%）时触发 Old GC。
老年代内存使用率阀值超过 CMSInitiatingOccupancyFraction（默认为92%）时触发 OldGC，CMSInitiatingOccupancyFraction 默认值为 -1，没有配置时默认阀值为 92%。
未配置 UseCMSInitiatingOccupancyOnly 时，因为分配对象时内存不足导致的扩容等触发GC

③ CMS参数设置

在没有配置
UseCMSInitiatingOccupancyOnly 参数的情况下，会多出很多种触发可能，一般在生产环境会配置 UseCMSInitiatingOccupancyOnly 参数，配了之后就不用设置 CMSBootstrapOccupancy 参数了。

CMSInitiatingOccupancyFraction 设置得太高将会很容易导致频繁的并发失败，性能反而降低；太低又可能频繁触发CMS background collector，一般在生产环境中应根据实际应用情况来权衡设置。

-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=92
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSBootstrapOccupancy=92
-xx:CMSWaitDuration=2000
3）CMS 的问题：

① 并发回收导致CPU资源紧张：

在并发阶段，它虽然不会导致用户线程停顿，但却会因为占用了一部分线程而导致应用程序变慢，降低程序总吞吐量。CMS默认启动的回收线程数是：（CPU核数 + 3）/ 4，当CPU核数不足四个时，CMS对用户程序的影响就可能变得很大。

② 无法清理浮动垃圾：

在CMS的并发标记和并发清理阶段，用户线程还在继续运行，就还会伴随有新的垃圾对象不断产生，但这一部分垃圾对象是出现在标记过程结束以后，CMS无法在当次收集中处理掉它们，只好留到下一次垃圾收集时再清理掉。这一部分垃圾称为“浮动垃圾”。

③ 并发失败（Concurrent Mode Failure）：

由于在垃圾回收阶段用户线程还在并发运行，那就还需要预留足够的内存空间提供给用户线程使用，因此CMS不能像其他回收器那样等到老年代几乎完全被填满了再进行回收，必须预留一部分空间供并发回收时的程序运行使用。默认情况下，当老年代使用了 92% 的空间后就会触发 CMS 垃圾回收，这个值可以通过 -XX:
CMSInitiatingOccupancyFraction 参数来设置。

这里会有一个风险：要是CMS运行期间预留的内存无法满足程序分配新对象的需要，就会出现一次“并发失败”（Concurrent Mode Failure），这时候虚拟机将不得不启动后备预案：Stop The World，临时启用 Serial Old 来重新进行老年代的垃圾回收，这样一来停顿时间就很长了。

④ 内存碎片问题：

CMS是一款基于“标记-清除”算法实现的回收器，这意味着回收结束时会有内存碎片产生。内存碎片过多时，将会给大对象分配带来麻烦，往往会出现老年代还有很多剩余空间，但就是无法找到足够大的连续空间来分配当前对象，而不得不提前触发一次 Full GC 的情况。

为了解决这个问题，CMS收集器提供了一个 -XX:+
UseCMSCompactAtFullCollection 开关参数（默认开启），用于在 Full GC 时开启内存碎片的合并整理过程，由于这个内存整理必须移动存活对象，是无法并发的，这样停顿时间就会变长。还有另外一个参数 -XX:
CMSFullGCsBeforeCompaction，这个参数的作用是要求CMS在执行过若干次不整理空间的 Full GC 之后，下一次进入 Full GC 前会先进行碎片整理（默认值为0，表示每次进入 Full GC 时都进行碎片整理）。

8、G1 垃圾回收器

G1（Garbage First）回收器采用面向局部收集的设计思路和基于Region的内存布局形式，是一款主要面向服务端应用的垃圾回收器。G1设计初衷就是替换 CMS，成为一种全功能收集器。G1 在JDK9 之后成为服务端模式下的默认垃圾回收器，取代了 Parallel Scavenge 加 Parallel Old 的默认组合，而 CMS 被声明为不推荐使用的垃圾回收器。G1从整体来看是基于 标记-整理 算法实现的回收器，但从局部（两个Region之间）上看又是基于 标记-复制 算法实现的。

1）可预期的回收停顿时间

G1 可以指定垃圾回收的停顿时间，通过 -XX: MaxGCPauseMillis 参数指定，默认为 200 毫秒。这个值不宜设置过低，否则会导致每次回收只占堆内存很小的一部分，回收器的回收速度逐渐赶不上对象分配速度，导致垃圾慢慢堆积，最终占满堆内存导致 Full GC 反而降低性能。

G1之所以能建立可预测的停顿时间模型，是因为它将 Region 作为单次回收的最小单元，即每次回收到的内存空间都是 Region 大小的整数倍，这样可以有计划地避免在整个Java堆中进行全区域的垃圾回收。G1会去跟踪各个Region的垃圾回收价值，价值即回收所获得的空间大小以及回收所需时间的经验值，然后在后台维护一个优先级列表，每次根据用户设定允许的回收停顿时间，优先处理回收价值收益最大的那些Region。这种使用Region划分内存空间，以及具有优先级的区域回收方式，保证了G1回收器在有限的时间内得到尽可能高的回收效率。

由于Region数量比传统回收器的分代数量明显要多得多，因此G1回收器要比其他的传统垃圾回收器有着更高的内存占用负担。G1至少要耗费大约相当于Java堆容量10%至20%的额外内存来维持回收器工作。

2）G1内存布局

G1不再是固定大小以及固定数量的分代区域划分，而是把堆划分为多个大小相等的Region，每个Region的大小默认情况下是堆内存大小除以2048，因为JVM最多可以有2048个Region，而且每个Region的大小必须是2的N次冥。每个Region的大小也可以通过参数 -XX:G1HeapRegionSize 设定，取值范围为1MB～32MB，且应为2的N次幂。

G1也有新生代和老年代的概念，不过是逻辑上的区分，每一个 Region 都可以根据需要，作为新生代的Eden空间、Survivor空间，或者老年代空间。新生代默认占堆内存的5%，但最多不超过60%，这个默认值可以使用 -XX:G1NewSizePercent 参数设置，最大值可以通过 -XX:G1MaxNewSizePercent 参数设置。新生代 Region 的数量并不是固定的，随着使用和垃圾回收会动态的变化。同样的，G1新生代也有 eden 区和 survivor 区的划分，也可以通过 -XX:SurvivorRatio 设置其比例，默认为8。

3）大对象Region

Region中还有一类特殊的 Humongous 区域，专门用来存储大对象，而不是直接进入老年代的Region。G1认为一个对象只要大小超过了一个Region容量的一半就判定为大对象。而对于那些超过了整个Region容量的超级大对象，将会被存放在N个连续的 Humongous Region 之中，G1的大多数行为都把 Humongous Region 作为老年代的一部分来看待。

4）G1 回收过程

G1 回收器的运作过程大致可分为四个步骤：

1）初始标记（会STW）：

仅仅只是标记一下 GC Roots 能直接关联到的对象，并且修改TAMS指针的值，让下一阶段用户线程并发运行时，能正确地在可用的Region中分配新对象。这个阶段需要停顿线程，但耗时很短，而且是借用进行Minor GC的时候同步完成的，所以G1收集器在这个阶段实际并没有额外的停顿。

2）并发标记：

从 GC Roots 开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这阶段耗时较长，但可与用户程序并发执行。当对象图扫描完成以后，还要重新处理在并发时有引用变动的对象。

3）最终标记（会STW）：

对用户线程做短暂的暂停，处理并发阶段结束后仍有引用变动的对象。

4）清理阶段（会STW）：

更新Region的统计数据，对各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个Region构成回收集，然后把决定回收的那一部分Region的存活对象复制到空的Region中，再清理掉整个旧Region的全部空间。这里的操作涉及存活对象的移动，必须暂停用户线程，由多条回收器线程并行完成的。

5）G1新生代回收

根据G1的内存布局举个例子，例如：设置堆内存 4G，就是 4096M，除以2048个Region，每个Region就是2M；新生代期初占5%，就是约100个Region，此时eden区占80个Region，两个survivor区各占10个Region；不过随着对象的在新生代分配，属于新生代的Region会不断增加，eden和survivor对应的Region也会不断增加。直到新生代占用60%，也就是约1200个Region，就会触发新生代的GC，这个时候就会采用复制算法将eden对应Region存活的对象复制到 from survivor 对应的Region。只不过这里会根据用户期望的停顿时间来选取部分最有回收价值的Region进行回收。

6）G1混合回收

G1有一个参数，
-XX:InitiatingHeapOccupancyPercent，它的默认值是45%，就是如果老年代占堆内存45%的Region的时候，此时就会触发一次年轻代+老年代的混合回收。

混合回收阶段，因为我们设定了最大停顿时间，所以 G1 会从新生代、老年代、大对象里挑选一些 Region，保证指定的时间内回收尽可能多的垃圾。所以 G1 可能一次无法将所有Region回收完，它就会执行多次混合回收，先停止程序，执行一次混合回收回收掉一些Region，接着恢复系统运行，然后再次停止系统运行，再执行一次混合回收回收掉一些Region。可以通过参数 -XX:G1MixedGCCountTarget 设置一次回收的过程中，最后一个阶段最多执行几次混合回收，默认值是8次。通过这种反复回收的方式，避免系统长时间的停顿。

G1还有一个参数 -XX:G1HeapWastePercent，默认值是 5%。就是在混合回收时，Region回收后，就会不断的有新的Region空出来，一旦空闲出来的Region数量超过堆内存的5%，就会立即停止混合回收，即本次混合回收就结束了。

G1还有一个参数
-XX:G1MixedGCLiveThresholdPercent，默认值是85%。意思是回收Region的时候，必须存活对象低于Region大小的85%时才可以进行回收，一个Region存活对象超过85%，就不必回收它了，因为要复制大部分存活对象到别的Region，这个成本是比较高的。

7）回收失败

① 并发回收失败

在并发标记阶段，用户线程还在并发运行，程序继续运行就会持续有新对象产生，也需要预留足够的空间提供给用户线程使用。G1为每一个Region设计了两个名为TAMS（Top at Mark Start）的指针，把Region中的一部分空间划分出来用于并发回收过程中的新对象分配，并发回收时新分配的对象地址都必须要在这两个指针位置以上。G1默认在这个地址以上的对象是被隐式标记过的，即默认它们是存活的，不纳入回收范围。如果内存回收的速度赶不上内存分配的速度，跟CMS会发生并发失败一样，G1也要被迫暂停程序，导致 Full GC 而产生长时间 Stop The World。

② 混合回收失败

混合回收阶段，年轻代和老年代都是基于复制算法进行回收，复制的过程中如果没有空闲的Region了，就会触发失败。一旦失败，就会停止程序，然后采用单线程标记、清理和内存碎片整理，然后空闲出来一批Region。这个过程是很慢的，因此要尽量调优避免混合回收失败的发生。

六、内存抖动

内存抖动是指内存频繁地分配和回收，而频繁的 GC 会导致卡顿，严重时和内存泄漏一样会导致 OOM。

1.抖动导致 OOM

Dalvik 虚拟机主要使用标记清除算法，也可以选择使用拷贝算法。这取决于编译时期:

ART 是在 Android 4.4 中引入的一个开发者选项，也是 Android 5.0 及更高版本的默认 Android 运行时。google 已不再继续维护和提供 Dalvik 运行时，现在 ART 采用了其字节码格式。

ART 有多个不同的 GC 方案，这些方案包括运行不同垃圾回收器。默认方案是 CMS。

**结论：**不论是 Dalvik 虚拟机默认使用标记清除算法，还是 ART 虚拟机默认使用有 CMS 收集器，CMS 收集器使用的也是标记清除算法，所以都容易在内存抖动时候导致 OOM。

2.检测内存抖动

内存抖动在 Android Profile 中表现为：

在 Android Studio 中点击 memory profiler 中的红点录制一段时间的内存申请情况，再点击结束。

可以在下方看到，在这段时间内，各个类型对象创建的个数和占用的内存。

点击各个类型，可以显示其具体对象，在点击具体对象，可以显示其具体创建的地方。我们可以对占较多内存、或者个数较多的对象进行查看，分析其原因，对其进行优化，这样就可以避免内存抖动。

3.优化

对于基于内存抖动，我们主要需要注意是：

1.尽量避免在循环体或者频繁调用的函数内创建对象，应该把对象创建移到循环体外。

2.另外还有一个经典的 String 拼接创建大量小的对象造成的内存抖动。

String string = "a";
string += "b";
string += "c";123

这里会产生 3个 字符串对象， “a”、”ab”、 “abc”,，实际上我们需要的只有最后一个 “abc” 这个对象，但是由于中间采用 + 号进行拼接字符串，导致产生了较多无用的字符串常量，可以使用 StringBuilder 进行优化。

注： String string = “a” + “b” + “c” ; 如果一次性拼接完，这样是只会产生一个字符串常量。

七、总结

虚拟机垃圾回收机制很多时候都是影响系统性能、并发能力的主要因素之一。尤其是对于从事 Android 开发的工程师来说，有时候垃圾回收会很大程度上影响 UI 线程，并造成界面卡顿现象。这只是学会Android性能优化进阶，学习手册中其中卡顿优化的一小部分，因此理解垃圾回收机制并学会分析 GC Log 也是一项必不可少的技能。

Android 虚拟机中对垃圾回收所做的优化。