Java虚拟机这一块 —— 垃圾回收算法与垃圾回收器

学习垃圾回收的意义

Java 与 C++等语言最大的技术区别：自动化的垃圾回收机制（GC）

为什么要了解 GC 和内存分配策略?

1. 面试需要
2. GC 对应用的性能是有影响的；
3. 写代码有好处
   栈：栈中的生命周期是跟随线程，所以一般不需要关注
   堆：堆中的对象是垃圾回收的重点
   方法区/元空间：这一块也会发生垃圾回收，不过这块的效率比较低，一般不是我们关注的重点

判断对象的存活

引用计数法

给对象添加一个引用计数器，当对象增加一个引用时计数器加 1，引用失效时计数器减 1。引用计数为 0 的对象可被回收。（Python 在用，但主流虚拟 机没有使用

• 优点：快，方便，实现简单。
• 缺陷：对象相互引用时（A.instance=B 同时 B.instance=A），很难判断对象是否该回收。

可达性分析（Java 中使用）

来判定对象是否存活的。这个算法的基本思路就是通过一系列的称为“GCRoots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为 引用链（ReferenceChain），当一个对象到 GCRoots 没有任何引用链相连时，则证明此对象是不可用的。

作为 GCRoots 的对象包括下面几种：

• 当前虚拟机栈中局部变量表中的引用的对象
• 当前本地方法栈中局部变量表中的引用的对象 (native)
• 方法区中类静态属性引用的对象
• 方法区中的常量引用的对象

请忘记 finalize

Object 中finalize方法

finalize 可以完成对象的拯救，但是 JVM 不保证一定能执行，所以请忘记这个“坑”。

各种引用（Reference）

传统定义：Reference 中存储的数据代表的是另一块内存的起始地址。

强引用

一般的 Objectobj=newObject() ，就属于强引用。 （如果有 GCroots 的强引用）垃圾回收器绝对不会回收它，当内存不足时宁愿抛出 OOM 错误，使得程序异常停止

软引用 SoftReference

• 垃圾回收器在内存充足的时候不会回收它，而在内存不足时会回收它
• 软引用非常适合于创建缓存。当系统内存不足的时候，缓存中的内容是可以被释放的。
• 一些有用但是并非必需，用软引用关联的对象，系统将要发生 OOM 之前，这些对象就会被回收。参见代码：
  VM 参数 -Xms10m -Xmx10m-XX:+PrintGC
  
  运行结果
  
  例如，一个程序用来处理用户提供的图片。如果将所有图片读入内存，这样虽然可以很快的打开图片，但内存空间使用巨大，一些使用较少的图片浪费 内存空间，需要手动从内存中移除。如果每次打开图片都从磁盘文件中读取到内存再显示出来，虽然内存占用较少，但一些经常使用的图片每次打开都 要访问磁盘，代价巨大。这个时候就可以用软引用构建缓存。

弱引用 WeakReferenc

• 垃圾回收器在扫描到该对象时，无论内存充足与否，都会回收该对象的内存。
• 一些有用（程度比软引用更低）但是并非必需，用弱引用关联的对象，只能生存到下一次垃圾回收之前，GC 发生时，不管内存够不够，都会被回收。 参看代码：
  
  
  注意：软引用 SoftReference 和弱引用 WeakReference，可以用在内存资源紧张的情况下以及创建不是很重要的数据缓存。当系统内存不足的时候，缓存 中的内容是可以被释放的。 实际运用（WeakHashMap、ThreadLocal）

虚引用 PhantomReference

• 幽灵引用，最弱，被垃圾回收的时候收到一个通知
• 如果一个对象只具有虚引用，那么它和没有任何引用一样，任何时候都可能被回收。
• 虚引用主要用来跟踪对象被垃圾回收器回收的活动

GC（GarbageCollection）

MinorGC

• 特点: 发生在新生代上，发生的较频繁，执行速度较快
• 触发条件:Eden 区空间不足\空间分配担保

FullGC

• 特点: 主要发生在老年代上（新生代也会回收），较少发生，执行速度较慢
• 触发条件:

1. 调用 System.gc()
2. 老年代区域空间不足
3. 空间分配担保失败
4. JDK1.7 及以前的永久代(方法区)空间不足
5. CMSGC 处理浮动垃圾时，如果新生代空间不足，则采用空间分配担保机制，如果老年代空间不足，则触发 FullGC

垃圾回收算法

复制算法（Copying）

将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使 用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要按顺序分配内存即可， 实现简单，运行高效。只是这种算法的代价是将内存缩小为了原来的一半。

注意：内存移动是必须实打实的移动（复制），不能使用指针玩。

优点：

• 简单高效，不会出现内存碎片的问题

缺点：

• 内存利用率低，只有一半
• 存活对象较多时效率明显会降低

专门研究表明，新生代中的对象 98%是“朝生夕死”的(不需要回收的)，所以一般来说回收占据 10%的空间够用了，所以并不需要按照 1:1的比例来划分内存空间，而是 将内存分为一块较大的 Eden 空间和两块较小的 Survivor 空间，每次使用 Eden 和其中一块 Survivor[1]。当回收时，将 Eden 和 Survivor 中还存活着的对象一 次性地复制到另外一块 Survivor空间上，最后清理掉 Eden 和刚才用过的 Survivor 空间。 HotSpot 虚拟机默认 Eden 和 Survivor的大小比例是 8:1，也就是每次新生代中可用内存空间为整个新生代容量的 90%（80%+10%），只有 10%的内存会被 “浪费”。

标记-清除算法（Mark-Sweep）

过程:

1. 首先标记所有需要回收的对象
2. 统一回收被标记的对象

优点：

1. 利用率百分之百

缺点：

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

标记-整理算法（Mark-Compact）

首先标记出所有需要回收的对象，在标记完成后，后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端 边界以外的内存。

优点：

1. 利用率百分之百
2. 没有内存碎片

缺点：

1. 效率问题，标记和清除效率都不高
2. 效率相对 标记-清除算法 较低

JVM中的垃圾回收器

分代收集

根据各个年代的特点选取不同的垃圾收集算法

• 新生代使用复制算法
• 老年代使用标记-整理或者标记-清除算法

jps -v显示当前使用的垃圾回收器

• 并行：垃圾收集的多线程的同时进行。
• 并发：垃圾收集的多线程和应用的多线程同时进行。

注：吞吐量=运行用户代码时间/(运行用户代码时间+ 垃圾收集时间) 垃圾收集时间= 垃圾回收频率 * 单次垃圾回收时间

各种垃圾回收器

• Serial/SerialOld
  最古老的，单线程，独占式，成熟，适合单 CPU 服务器 -XX:+UseSerialGC 新生代和老年代都用串行收集器 -XX:+UseParNewGC 新生代使用 ParNew，老年代使用 SerialOld -XX:+UseParallelGC 新生代使用 ParallerGC，老年代使用 SerialOld

• ParNew
  和 Serial 基本没区别，唯一的区别：多线程，多 CPU 的，停顿时间比 Serial 少 -XX:+UseParNewGC 新生代使用 ParNew，老年代使用 SerialOld 除了性能原因外，主要是因为除了 Serial 收集器，只有它能与 CMS 收集器配合工作。

• ParallelScavenge（ParallerGC）/ParallelOld
  关注吞吐量的垃圾收集器，高吞吐量则可以高效率地利用 CPU 时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
  所谓吞吐量就是 CPU 用于运行用户代码的时间与 CPU 总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总 共运行了 100 分钟，其中垃圾收集花掉 1 分钟，那吞吐量就是 99%。

• ConcurrentMarkSweep （CMS）
  收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的 Java 应用集中在互联网站或者 B/S 系统的服务端上，这类应用尤其重视服务 的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。
  CMS 收集器就非常符合这类应用的需求。-XX:+UseConcMarkSweepGC ，一般新生代使用 ParNew，老年代的用 CMS 从名字（包含“MarkSweep”）上就可以看出，CMS 收集器是基于“标记—清除”算法实现的，它的运作过程相对于前面几种收集器来说更复杂一些，

垃圾回收过程

简单的垃圾回收器工作示意图

单线程收集

多线程收集(并行收集)

ConcurrentMarkSweep （CMS）垃圾回收器工作示意图

整个过程分为 4 个步骤，包括：
 初始标记：仅仅只是标记一下 GCRoots 能直接关联到的对象，速度很快，需要停顿（STW-Stoptheworld）。
 并发标记：从 GCRoot 开始对堆中对象进行可达性分析，找到存活对象，它在整个回收过程中耗时最长，不需要停顿。
 重新标记：为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，需要停顿(STW)。这个阶段的停顿时间一般 会比初始标记阶段稍长一些，但远比并发标记的时间短。
 并发清除：不需要停顿。

优点：

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

缺点：

• CPU 资源敏感：因为并发阶段多线程占据 CPU 资源，如果 CPU 资源不足，效率会明显降低。
• 浮动垃圾：由于 CMS 并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS 无法 在当次收集中处理掉它们，只好留待下一次 GC 时再清理掉。这一部分垃圾就称为“浮动垃圾”。
• 由于浮动垃圾的存在，因此需要预留出一部分内存，意味着 CMS 收集不能像其它收集器那样等待老年代快满的时候再回收。
• 在 1.6 的版本中老年代空间使用率阈值(92%)
• 如果预留的内存不够存放浮动垃圾，就会出现 ConcurrentModeFailure，这时虚拟机将临时启用 SerialOld 来替代 CMS。
• 会产生空间碎片：标记 - 清除算法会导致产生不连续的空间碎片

G1 垃圾回收器

G1 中重要的参数： -XX:+UseG1GC 使用 G1 垃圾回收器

内部布局改变

• G1 把堆划分成多个大小相等的独立区域（Region），新生代和老年代不再物理隔离。
• 算法：标记—整理 （humongous） 和复制回收算法(survivor)。
  

GC 模式

YoungGC

选定所有年轻代里的 Region。通过控制年轻代的 region 个数，即年轻代内存大小，来控制 youngGC 的时间开销。（复制回收算法）

MixedGC

• 选定所有年轻代里的 Region，外加根据 globalconcurrentmarking 统计得出收集收益高的若干老年代 Region。在用户指定的开销目标范围内尽可能选择收 益高的老年代 Region。
• MixedGC 不是 fullGC，它只能回收部分老年代的 Region。如果 mixedGC 实在无法跟上程序分配内存的速度，导致老年代填满无法继续进行 MixedGC，就 会使用 serialoldGC（fullGC）来收集整个 GCheap。所以我们可以知道，G1 是不提供 fullGC 的。

全局并发标记（global concurrentmarking）

• 初始标记：
  仅仅只是标记一下 GCRoots 能直接关联到的对象，并且修改 TAMS（NestTopMarkStart）的值，让下一阶段用户程序并发运行时，能在正确 可以的 Region 中创建对象，此阶段需要停顿线程(STW)，但耗时很短。
• 并发标记：
  从 GCRoot 开始对堆中对象进行可达性分析，找到存活对象，此阶段耗时较长，但可与用户程序并发执行。
• 最终标记：
  为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程的
  RememberedSetLogs 里面，最终标记阶段需要把 RememberedSetLogs 的数据合并到 RememberedSet 中。这阶段需要停顿线程(STW)，但是可并行执 行。
• 筛选回收：
  首先对各个 Region 中的回收价值和成本进行排序，根据用户所期望的 GC 停顿时间来制定回收计划。此阶段其实也可以做到与用户程序一起 并发执行，但是因为只回收一部分 Region，时间是用户可控制的，而且停顿用户线程将大幅度提高收集效率。
  

特点

• 空间整合：
  不会产生内存碎片
• 算法：
  标记—整理 （humongous） 和复制回收算法(survivor)。
• 可预测的停顿：
  G1 收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个 Java 堆中进行全区域的垃圾收集。G1 跟踪各个 Region 里面的垃圾堆 积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的 Region （这也就是 Garbage-First 名称的来由）。这种使用 Region 划分内存空间以及有优先级的区域回收方式，保证了 G1 收集器在有限的时间内可以获取尽可能 高的收集效率。
  G1 把内存“化整为零”的思路

G1 GC主要的参数

参数	含义
-XX:G1HeapRegionSize=n	设置 Region 大小，并非最终值
-XX:MaxGCPauseMillis	设置 G1 收集过程目标时间，默认值 200ms，不是硬性条件
-XX:G1NewSizePercent	新生代最小值，默认值 5%
-XX:G1MaxNewSizePercent	新生代最大值，默认值 60%
-XX:ParallelGCThreads	STW 期间，并行 GC 线程数
-XX:ConcGCThreads=n	并发标记阶段，并行执行的线程数
-XX:InitiatingHeapOccupancyPercent	设置触发标记周期的 Java 堆占用率阈值。默认值是 45%。这里的 java 堆占比指的是 non_young_capacity_bytes，包括 old+humongous

垃圾回收器的重要参数（使用-XX:）

参数	描述
UseSerialGC	虚拟机运行在 Client 模式下的默认值，打开此开关后，使Serial+SerialOld 的收集器组合进行内存回收
UseParNewGC	打开此开关后，使用 ParNew+SerialOld 的收集器组合进行内存回收
UseParallelGC	虚拟机运行在 Server 模式下的默认值，打开此开关后，使用 ParallelScavenge+SerialOld(PSMarkSweep) 的收集 器组合进行内存回收
UseParallelOldGC	打开此开关后，使用 ParallelScavenge+ParallelOld 的收集器组合进行内存回收
SurvivorRatio	新生代中 Eden 区域与 Survivor 区域的容量比值，默认为 8，代表 Eden:Survivor=8:1
PretenureSizeThreshold	直接晋升到老年代的对象大小，设置这个参数后，大于这个参数的对象将直接在老年代分配
MaxTenuringThreshold	晋升到老年代的对象年龄，每个对象在坚持过一次 MinorGC 之后，年龄就增加 1，当超过这个参数值时就进入 老年代
UseAdaptiveSizePolicy	动态调整 Java 堆中各个区域的大小以及进入老年代的年龄
HandlePromotionFailure	是否允许分配担保失败，即老年代的剩余空间不足以应付新生代的整个 Eden 和 Survivor 区的所有对象都存活 的极端情况
ParallelGCThreads	设置并行 GC 时进行内存回收的线程数
GCTimeRatio	GC 时间占总时间的比率，默认值为 99，即允许 1% 的 GC 时间，仅在使用 ParallelScavenge 收集器生效
MaxGCPauseMillis	设置 GC 的最大停顿时间，仅在使用 ParallelScavenge 收集器时生效
CMSInitiatingOccupancyFraction	设置 CMS 收集器在老年代空间被使用多少后触发垃圾收集，默认值为 68%，仅在使用 CMS 收集器时生效
UseCMSCompactAtFullCollection	设置 CMS 收集器在完成垃圾收集后是否要进行一次内存碎片整理，仅在使用 CMS 收集器时生效
CMSFullGCsBeforeCompaction	设置 CMS 收集器在进行若干次垃圾收集后再启动一次内存碎片整理，仅在使用 CMS 收集器时生效

StopTheWorld 现象

GC 收集器和我们 GC 调优的目标就是尽可能的减少 STW 的时间和次数。