JVM学习(五)--垃圾回收机制

JVM组合拳往期文章

• JVM学习(一)–概述和模型
• JVM学习(二)–类加载和双亲委派机制
• JVM学习(三)–JVM运行时数据区图文详解
• JVM学习(四)–JVM本地方法和执行引擎
• JVM学习(五)–垃圾回收机制
  

1垃圾回收概述

1.1概述

1. Java 和 C++语言的区别，就在于垃圾收集技术和内存动态分配上，C++语言没有垃圾收集技术，需要程序员手动的收集
2. 垃圾收集，不是 Java 语言的伴生产物。早在 1960 年，第一门开始使用内存动态分配和垃圾收集技术的 Lisp 语言诞生
3. 关于垃圾收集有三个经典问题：
   哪些内存需要回收？
   什么时候回收？
   如何回收？
4. 垃圾收集机制是 Java 的招牌能力，极大地提高了开发效率。

1.2什么是垃圾

垃圾是指在运行程序中没有任何指针指向的对象，这个对象就是需要被回收的垃圾.

如果不及时对内存中的垃圾进行清理，这些垃圾对象所占的内存空间会一直保留到应用程序结束。甚至可能导致内存溢出。

1.3为什么需要GC

1. 对于高级语言来说,运行时不断地分配内存空间,若不进行回收，内存就会被消耗完
2. 除了释放没用的对象，垃圾回收也可以清除内存里的记录碎片。碎片整理将所占用的堆内存移到堆的一端，以便 JVM 将整理出的内存分配给新的对象
3. 随着应用程序所应付的业务越来越庞大、复杂，用户越来越多，没有 GC就不能保证应用程序的正常进行

1.4早期垃圾回收

在早期的 C/C++时代，垃圾回收基本上是手工进行的。开发人员可以使用 new关键字进行内存申请，并使用 delete 关键字进行内存释放。

MibBridge *pBridge= new cmBaseGroupBridge（）；
//如果注册失败，使用 Delete 释放该对象所占内存区域
if（pBridge->Register（kDestroy）！=NO ERROR）
delete pBridge；

这种方式可以灵活控制内存释放的时间，但是会给开发人员带来频繁申请和释放内存的管理负担。倘若有一处内存区间由于程序员编码的问题忘记被回收，那么就会产生内存泄漏，垃圾对象永远无法被清除，随着系统运行时间的不断增长，垃圾对象所耗内存可能持续上升，直到出现内存溢出并造成应用程序崩溃。

有了垃圾回收机制后，上述代码极有可能变成这样

MibBridge *pBridge=new cmBaseGroupBridge();
pBridge->Register(kDestroy);

1.5java垃圾回收机制

1.5.1自动内存管理

优点:无序开发人员手动参与内存的分配与回收,降低内存泄漏和内存溢出的风险

将程序员从繁重的内存管理中释放出来,专注于业务开发

1.5.2关于自动内存管理的担忧

1. 过度依赖"自动",会严重弱化java开发人员在程序出现内存溢出时定位问题和解决问题的能力
2. 了解 JVM 的自动内存分配和内存回收原理就显得非常重要，只有在真正了解 JVM 是如何管理内存后，我们才能够在遇见 OutofMemoryError 时，快速地根据错误异常日志定位问题和解决问题
3. 当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就必须对这些“自动化”的技术实施必要的监控和调节

1.5.3应该关心那些区域的回收

垃圾收集器对年轻代回收,对老年代回收,对全栈和方法区回收,对java堆重点回收

次数上讲:频繁收集Yong区,较少收集Old区,基本不收集元空间(方法区)

2垃圾回收相关算法

2.1垃圾标记阶段算法

2.1.1标记阶段的目的

垃圾标记阶段：主要是为了判断对象是否存活

1. .堆里存放着几乎所有的 Java 对象实例，在 GC 执行垃圾回收之前，首先需要区分出内存中哪些是存活对象，哪些是已经死亡的对象。只有被标记为己经死亡的对象，GC 才会在执行垃圾回收时，释放掉其所占用的内存空间，因此这个过程我们可以称为垃圾标记阶段。
2. 那么在 JVM 中究竟是如何标记一个死亡对象呢？简单来说，当一个对象已经不再被任何的存活对象继续引用时，就可以宣判为已经死亡
3. 判断对象存活一般有两种方式：引用计数算法和可达性分析算法

2.1.2引用计数算法

1. 引用计数算法（Reference Counting）比较简单，对每个对象保存一个整型的引用计数器属性。用于记录对象被引用的情况。
2. 对于一个对象 A，只要有任何一个对象引用了 A，则 A 的引用计数器就加 1；当引用失效时，引用计数器就减 1。只要对象 A 的引用计数器的值为 0，即表示对象 A 不可能再被使用，可进行回收。
3. 优点：实现简单，垃圾对象便于辨识；判定效率高，回收没有延迟性
4. 缺点：增加了存储空间的开销。增加了时间开销。引用计数器有一个严重的问题，即无法处理循环引用的情况。这是一条致命缺陷，导致在.Java 的垃圾回收器中没有使用这类算法。

2.1.3可达性分析算法

可达性分析算法：也可以称为根搜索算法、追踪性垃圾收集

1. 可达性分析算法具有与引用计数算法相同的实现简单和执行高效的特点，要有效的解决，引用计数算法中循环引用的问题，防止内存泄漏的发生
2. 相较于引用计数算法，这里的可达性分析就是 Java、C#选择的。这种类型的垃圾收集通常也叫作追踪性垃圾收集

可达性分析实现思路

所谓"GCRoots”根集合就是一组必须活跃的引用

1. 可达性分析算法是以根对象集合（GCRoots）为起始点，按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达。
2. 使用可达性分析算法后，内存中的存活对象都会被根对象集合直接或间接连接着，搜索所走过的路径称为引用链
3. 如果目标对象没有任何引用链相连，则是不可达的，就意味着该对象己经死亡，可以标记为垃圾对象
4. 在可达性分析算法中，只有能够被根对象集合直接或者间接连接的对象才是存活对象。

GC Roots 可以是哪些元素

1. 虚拟机栈中引用的对象，线程被调用使用的参数，局部变量等
2. 本地方法栈内JNI（本地方法）引用的对象
3. 方法区中类静态属性引用的对象
4. 方法区中常量引用的对象（字符串常量池中的引用）
5. 被synchronized持有的对象
6. java虚拟机内部的引用（基 本 数 据 类 型 对 应 的 Class 对 象 ， 一 些 常 驻 的 异 常 对 象 如 ：NullPointerException、OutofMemoryError），系统类加载器）

总结：

1. 除了堆空间的周边，比如：虚拟机栈，本地方法栈，方法区，字符串常量池堆堆空间进行引用，都可以作为GC Roots进行可达性分析
2. 除了这些固定的 GC Roots 集合以外，根据用户所选用的垃圾收集器以及当前回收的内存区域不同，还可以有其他对象“临时性”地加入，共同构成完整 GCRoots 集合。比如：分代收集和局部回收

小技巧：

由于 Root 采用栈方式存放变量和指针，所以如果一个指针，它保存了堆内存里面的对象，但是自己又不存放在堆内存里面，那它就是一个 Root

2.1.4对象的finalization机制

finalize() 方法机制

对象销毁前的回调函数：finalize()；
Java 语言提供了对象终止（finalization）机制来允许开发人员提供对象被销毁之前的自定义处理逻辑。
当垃圾回收器发现没有引用指向一个对象，即：垃圾回收此对象之前，总会先调用这个对象的 finalize()方法。
finalize() 方法允许在子类中被重写，用于在对象被回收时进行资源释放。通常在这个方法中进行一些资源释放和清理的工作，比如关闭文件、套接字和数据库连接等

永远不要主动调用某个对象的 finalize()方法，应该交给垃圾回收机制调用。理
由包括下面三点：

1. 在 finalize()时可能会导致对象复活。
2. .finalize()方法的执行时间是没有保障的，它完全由 GC 线程决定，极端情况下，若不发生 GC，则 finalize()方法将没有执行机会。
3. 一个糟糕的 finalize()会严重影响 GC 的性能。比如 finalize 是个死循环。

2.1.5生存还是死亡?

由于 finalize()方法的存在，虚拟机中的对象一般处于三种可能的状态。

可触及的：从根节点开始，可以到达这个对象。
可复活的：对象的所有引用都被释放，但是对象有可能在 finalize()中复活。
不可触及的：对象的 finalize()被调用，并且没有复活，那么就会进入不可触及状态。不可触及的对象不可能被复活，因为 finalize()只会被调用一次。

具体过程

1. 如果对象 objA 到 GC Roots 没有引用链，则进行第一次标记。
2. 进行筛选，判断此对象是否有必要执行 finalize()方法
   • ​ 如果对象 objA 没有重写 finalize()方法，或者 finalize()方法已经被虚拟机调用过，则虚拟机视为“没有必要执行”，objA 被判定为不可触及的
   • 如果对象 objA 重写了 finalize()方法，且还未执行过，那么 objA 会被插入到 F-Queue 队列中，由一个虚拟机自动创建的、低优先级的 Finalizer 线程触发其 finalize()方法执行。
   • finalize()方法是对象逃脱死亡的最后机会，稍后 GC 会对 F-Queue 队列中的对象进行第二次标记。如果 objA 在 finalize()方法中与引用链上的任何一个对象建立了联系，那么在第二次标记时，objA 会被移出“即将回收”集合。之后，对象会再次出现没有引用存在的情况。在这个情况下，finalize()方法不会被再次调用，对象会直接变成不可触及的状态，也就是说，一个对象的 finalize()方法只会被调用一次。

2.2垃圾回收阶段算法

​ 当成功区分出内存中存活对象和死亡对象后，GC 接下来的任务就是执行垃圾回收，释放掉无用对象所占用的内存空间，以便有足够的可用内存空间为新对象分配内存。目前在 JVM 中比较常见的三种垃圾收集算法是:

• 标记-清除算法（Mark-Sweep）
• 复制算法（Copying）
• 标记-压缩算法（Mark-Compact）

2.2.1标记-清除算法

执行过程
当堆中的有效内存空间（available memory）被耗尽的时候，就会停止整个程序（也被称为 stop the world），然后进行两项工作，第一项则是标记，第二项则是清除
标记：Collector 从引用根节点开始遍历，标记所有被引用的对象。一般是在对象的 Header 中记录为可达对象。（注意：标记的是被引用的对象，也就是可达对象，并非标记的是即将被清除的垃圾对象）。
清除：Collector 对堆内存从头到尾进行线性的遍历，如果发现某个对象在其 Header 中没有标记为可达对象，则将其回收

标记-清除算法的优点：

​ 非常基础和常见的垃圾收集算法容易理解

标记-清除算法的缺点：
标记清除算法的效率不算高

​ 在进行 GC 的时候，需要停止整个应用程序，用户体验较差

​ 这种方式清理出来的空闲内存是不连续的，产生内碎片，需要维护一个空闲列表。（空闲列表-记录垃圾对象地址）。

注意：何为清除？

​ 这里所谓的清除并不是真的置空，而是把需要清除的对象地址保存在空闲的地址列表里。下次有新对象需要加载时，判断垃圾的位置空间是否够，如果够，就存放（也就是覆盖原有的地址）

2.2.2复制算法

为了解决标记-清除算法在垃圾收集效率方面的缺陷，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后清除正在使用的内存块中的所有对象，交换两个内存的角色，最后完成垃圾回收

优点

没有标记和清除过程，实现简单，运行高效

复制过去以后保证空间的连续性，不会出现“碎片”问题。
缺点

此算法的缺点也是很明显的，就是需要两倍的内存空间。

对于 G1 这种分拆成为大量 region 的 GC，复制而不是移动，意味着 GC 需要维护 region 之间对象引用关系，不管是内存占用或者时间开销也不小

主要使用这种收集算法回收新生代

2.2.3标记-压缩算法

标记压缩算法执行过程

第一阶段和标记清除算法一样，从根节点开始标记所有被引用对象

第二阶段将所有的存活对象压缩到内存的一端，按顺序排放。之后，清理边界外所有的空间

标记-压缩算法与标记-清除算法的比较

标记-压缩算法的最终效果等同于标记-清除算法执行完成后，再进行一次内存碎片整理，因此，也可以把它称为标记-清除-压缩（Mark-Sweep-Compact）算法。

二者的本质差异在于标记-清除算法是一种非移动式的回收算法（空闲列表记录位置），标记-压缩是移动式的。是否移动回收后的存活对象是一项优缺点并存的风险决策。

优点

​ 消除了标记-清除算法当中，内存区域分散的缺点，我们需要给新对象分配内存时，JVM 只需要持有一个内存的起始地址即可。

​ 消除了复制算法当中，内存减半的高额代价。
缺点

​ 从效率上来说，标记-整理算法要低于复制算法。

​ 移动对象的同时，如果对象被其他对象引用，则还需要调整引用的地址

​ 移动过程中，需要全程暂停用户应用程序。即：STW

2.2.4垃圾回收算法小结

效率上复制算法最快，但是浪费太多内存

标记-整理算法相对来说更平滑一些，但是效率上不尽如人意，它比复制算法多了一个标记的阶段，比标记-清除多了一个整理内存的阶段。

2.2.5分代收集算法

为什么要使用分代收集算法

​ 分代收集算法，是基于这样一个事实：不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。一般是把Java 堆分为新生代和老年代，这样就可以根据各个年代的特点使用不同的回收算法，以提高垃圾回收的效率

年轻代（Young Gen）

年轻代特点：区域相对老年代较小，对象生命周期短、存活率低，回收频繁。

这种情况复制算法的回收整理，速度是最快的。复制算法的效率只和当前存活对象大小有关，因此很适用于年轻代的回收。而复制算法内存利用率不高的问题，通过 hotspot 中的两个 survivor 的设计得到缓解

老年代（Tenured Gen）
老年代特点：区域较大，对象生命周期长、存活率高，回收不及年轻代频繁。

这种情况存在大量存活率高的对象，复制算法明显变得不合适。一般是由标记- 清除或者是标记-清除与标记-整理的混合实现。

1.Mark 阶段的开销与存活对象的数量成正比。
2.Sweep 阶段的开销与所管理区域的大小成正相关。
3.Compact 阶段的开销与存活对象的数据成正比。
以 HotSpot 中的 CMS 回收器为例，CMS 是基于 Mark-Sweep 实现的，对于对象的回收效率很高。对于碎片问题，CMS 采用基于 Mark-Compact 算法的Serial Old 回收器作为补偿措施：当内存回收不佳（碎片导致的 ConcurrentMode Failure 时），将采用 Serial Old 执行 Full GC 以达到对老年代内存的整理。

2.2.6增量手机算法和分区算法

增量收集算法

上述现有的算法，在垃圾回收过程中，应用软件将处于一种 Stop the World 的状态。在 Stop the World 状态下，应用程序所有的线程都会挂起，暂停一切正常的工作，等待垃圾回收的完成。如果垃圾回收时间过长，应用程序会被挂起很久，将严重影响用户体验或者系统的稳定性。为了解决这个问题，即对实时垃圾收集算法的研究直接导致了增量收集（Incremental Collecting）算法的诞生。

增量收集算法基本思想

如果一次性将所有的垃圾进行处理，需要造成系统长时间的停顿，那么就可以让垃圾收集线程和应用程序线程交替执行。每次，垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程。依次反复，直到垃圾收集完成。总的来说，增量收集算法的基础仍是传统的标记-清除和复制算法。增量收集算法通过对线程间冲突的妥善处理，允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作

增量收集算法的缺点

虽然减少系统的停顿时间。但是，因为线程切换和上下文转换的消耗，会使得垃圾回收的总体成本上升，造成系统吞吐量的下降。

分区算法

一般来说，在相同条件下，堆空间越大，一次 GC 时所需要的时间就越长，有关GC 产生的停顿也越长。为了更好地控制 GC 产生的停顿时间，将一块大的内存区域分割成多个小块，根据目标的停顿时间，每次合理地回收若干个小区间，而不是整个堆空间，从而减少一次 GC 所产生的停顿。

分代算法将按照对象的生命周期长短划分成两个部分，分区算法将整个堆空间划分成连续的不同小区间。每一个小区间都独立使用，独立回收。这种算法的好处是可以控制一次回收多少个小区间。

3垃圾回收相关概念

3.1System.gc()的理解

​ 在默认情况下，通过 System.gc()者 Runtime.getRuntime().gc() 的调用，会显式触发 Full GC，同时对老年代和新生代进行回收，尝试释放被丢弃对象占用的内存。

​ JVM 实现者可以通过 System.gc() 调用来决定 JVM 的 GC 行为。而一般情况下，垃圾回收应该是自动进行的，无须手动触发，否则就太过于麻烦了。在一些特殊情况下，如我们正在编写一个性能基准，我们可以在运行之间调用System.gc()。

3.2内存溢出和内存泄漏

内存溢出

​ 由于 GC 一直在发展，所有一般情况下，除非应用程序占用的内存增长速度非常快，造成垃圾回收已经跟不上内存消耗的速度，否则不太容易出现 OOM 的情况。
​ 大多数情况下，GC 会进行各种年龄段的垃圾回收，实在不行了就放大招，来一次独占式的 Full GC 操作，这时候会回收大量的内存，供应用程序继续使用。Javadoc 中对 OutofMemoryError 的解释是，没有空闲内存，并且垃圾收集器也无法提供更多内存

内存泄漏

​ 内存泄漏也称作“存储渗漏”。严格来说，只有对象不会再被程序用到了，但是 GC 又不能回收他们的情况，才叫内存泄漏。

​ 尽管内存泄漏并不会立刻引起程序崩溃，但是一旦发生内存泄漏，程序中的可用内存就会被逐步蚕食，直至耗尽所有内存，最终出现 OutofMemory 异常，导致程序崩溃。

一些提供 close()的资源未关闭导致内存泄漏
数据库连接 dataSourse.getConnection()，网络连接 socket 和 io 连接必须手动 close，否则是不能被回收的。

3.3Stop the World

Stop-the-World，简称 STW，指的是 GC 事件发生过程中，会产生应用程序的停顿。停顿产生时整个应用程序线程都会被暂停，没有任何响应，有点像卡死的感觉，这个停顿称为 STW。

可达性分析算法中枚举根节点（GC Roots）会导致所有 Java 执行线程停顿，为什么需要停顿所有 Java 执行线程呢？

1. 分析工作必须在一个能确保一致性的快照中进行
2. 一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上
3. 如果出现分析过程中对象引用关系还在不断变化，则分析结果的准确性无法保
   证
4. 被 STW 中断的应用程序线程会在完成 GC 之后恢复，频繁中断会让用户感觉像是网速不快造成电影卡带一样，所以我们需要减少 STW 的发生。
5. .STW 事件和采用哪款 GC 无关，所有的 GC 都有这个事件。
6. 越优秀，回收效率越来越高，尽可能地缩短了暂停时间

STW 是 JVM 在后台自动发起和自动完成的。在用户不可见的情况下，把用户正
常的工作线程全部停掉。

3.4对象的引用

3.4.1概述

当内存空间还足够时，则能保留在内存中；如果内存空间在进行垃圾收集后还是很紧张，则可以抛弃这些对象

强引用（StrongReference）：最传统的“引用”的定义，是指在程序代码之中普遍存在的引用赋值，即类似“object obj=new Object()”这种引用关系。无论任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象。宁可报 OOM，也不会 GC 强引用

软引用（SoftReference）：在系统将要发生内存溢出之前，将会把这些对象列入回收范围之中进行第二次回收。如果这次回收后还没有足够的内存，才会抛出内存溢出异常。

弱引用（WeakReference）：被弱引用关联的对象只能生存到下一次垃圾收集之前。当垃圾收集器工作时，无论内存空间是否足够，都会回收掉被弱引用关联的对象。

虚引用（PhantomReference）：一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来获得一个对象的实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。

3.4.2强引用

当在 Java 语言中使用 new 操作符创建一个新的对象，并将其赋值给一个变量的
时候，这个变量就成为指向该对象的一个强引用。

只要强引用的对象是可触及的，垃圾收集器就永远不会回收掉被引用的对象。

只要强引用的对象是可达的，jvm 宁可报 OOM，也不会回收强引用

对于一个普通的对象，如果没有其他的引用关系，只要超过了引用的作用域或者显式地将相应（强）引用赋值为 null，就是可以当做垃圾被收集了

强引用是造成 Java 内存泄漏的主要原因之一

3.4.3软引用（Soft Reference）：内存不足即回收

**软引用是用来描述一些还有用，但非必需的对象。**只被软引用关联着的对象，在系统将要发生内存溢出异常前，会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常。注意，这里的第一次回收是不可达的对象

软引用通常用来实现内存敏感的缓存。比如：高速缓存就有用到软引用。如果还有空闲内存，就可以暂时保留缓存，当内存不足时清理掉，这样就保证了使用缓存的同时，不会耗尽内存

Object obj = new Object();// 声明强引用
SoftReference<Object> sf = new SoftReference<>(obj);
obj = null; //销毁强引用

3.4.4弱引用(Weak Reference) 发现即回收

弱引用也是用来描述那些非必需对象，只被弱引用关联的对象只能生存到下一次垃圾收集发生为止。在系统 GC 时，只要发现弱引用，不管系统堆空间使用是否充足，都会回收掉只被弱引用关联的对象。

// 声明强引用
Object obj = new Object();
WeakReference<Object> sf = new WeakReference<>(obj);
obj = null; //销毁强引用

弱引用对象与软引用对象的最大不同就在于，当 GC 在进行回收时，需要通过算法检查是否回收软引用对象，而对于弱引用对象，GC 总是进行回收。弱引用对象更容易、更快被 GC 回收

3.4.5引用(Phantom Reference)对象回收跟踪

也称为“幽灵引用”或者“幻影引用”，是所有引用类型中最弱的一个

一个对象是否有虚引用的存在，完全不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它和没有引用几乎是一样的，随时都可能被垃圾回收器回收。它不能单独使用，也无法通过虚引用来获取被引用的对象。当试图通过虚引用的get()方法取得对象时，总是 null 。

虚引用必须和引用队列一起使用。虚引用在创建时必须提供一个引用队列作为参数。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象后，将这个虚引用加入引用队列，以通知应用程序对象的回收情况。

// 声明强引用
Object obj = new Object();
// 声明引用队列
ReferenceQueue phantomQueue = new ReferenceQueue();
// 声明虚引用（还需要传入引用队列）
PhantomReference<Object> sf = new PhantomReference<>(obj, phantomQueue);
obj = null;

4垃圾回收器

4.1垃圾回收器概述

垃圾收集器没有在规范中进行过多的规定，可以由不同的厂商、不同版本的JVM 来实现。
由于 JDK 的版本处于高速迭代过程中，因此 Java 发展至今已经衍生了众多的 GC 版本。
从不同角度分析垃圾收集器，可以将 GC 分为不同的类型。

4.2垃圾回收器分类

按线程数分，可以分为串行垃圾回收器和并行垃圾回收器。

串行回收指的是在同一时间段内只允许有一个 CPU 用于执行垃圾回收操作，此时工作线程被暂停，直至垃圾收集工作结束。

和串行回收相反，并行收集可以运用多个 CPU 同时执行垃圾回收，因此提升了应用的吞吐量，不过并行回收仍然与串行回收一样，采用独占式，使用"stop-the-world"机制。

按照工作模式分，可以分为并发式垃圾回收器和独占式垃圾回收器。

并发式垃圾回收器与应用程序线程交替工作，以尽可能减少应用程序的停顿时间

独占式垃圾回收器（stop the world）一旦运行，就停止应用程序中的所有用户线程，直到垃圾回收过程完全结束。

按工作的内存区间分，又可分为年轻代垃圾回收器和老年代垃圾回收器。

4.3 GC性能指标

吞吐量：运行用户代码的时间占总运行时间的比例（总运行时间：程序的运行时间+内存回收的时间）

垃圾收集开销：垃圾收集所用时间与总运行时间的比例。

暂停时间：执行垃圾收集时，程序的工作线程被暂停的时间。

收集频率：相对于应用程序的执行，收集操作发生的频率。

内存占用：Java 堆区所占的内存大小。

快速：一个对象从诞生到被回收所经历的时间

4.4 HotSpot垃圾收集器

串行回收器：Serial，Serial old

并行回收器：ParNew，Parallel scavenge，Parallel old

并发回收器：CMS、G1

新生代收集器：Serial，ParNew.Parallel scavenge；

老年代收集器：Serial old.Parallel old.cMS；

整堆收集器：G1；

4.4.1 Serial 垃圾收集器（单线程）

只开启一条 GC 线程进行垃圾回收，并且在垃圾收集过程中停止一切用户线程(Stop The World)

一般客户端应用所需内存较小，不会创建太多对象，而且堆内存不大，因此垃圾收集器回收时间短，即使在这段时间停止一切用户线程，也不会感觉明显卡顿。因此 Serial 垃圾收集器适合客户端使用。

由于 Serial 收集器只使用一条 GC 线程，避免了线程切换的开销，从而简单高效

6.4.4.2 ParNew 垃圾收集器（多线程）

ParNew 是 Serial 的多线程版本。由多条 GC 线程并行地进行垃圾清理。但清理过程依然需要 Stop The World。

ParNew 追求“低停顿时间”,与 Serial 唯一区别就是使用了多线程进行垃圾收集，在多 CPU 环境下性能比 Serial 会有一定程度的提升；但线程切换需要额外的开销，因此在单 CPU 环境中表现不如 Serial。

4.4.3 Parallel Scavenge 垃圾收集器（多线程）

Parallel Scavenge 和 ParNew 一样，都是多线程、新生代垃圾收集器。但是两者有巨大的不同点：

Parallel Scavenge：追求 CPU 吞吐量，能够在较短时间内完成指定任务，因此适合没有交互的后台计算。

ParNew：追求降低用户停顿时间，适合交互式应用。

吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)

追求高吞吐量，可以通过减少 GC 执行实际工作的时间，然而，仅仅偶尔运行 GC 意味着每当 GC 运行时将有许多工作要做，因为在此期间积累在堆中的对象数量很高。单个 GC 需要花更多的时间来完成，从而导致更高的暂停时间。而考虑到低暂停时间，最好频繁运行 GC 以便更快速完成，反过来又导致吞吐量下降。

4.4.4 Serial Old 垃圾收集器（单线程）

Serial Old 收集器是 Serial 的老年代版本，都是单线程收集器，只启用一条 GC线程，都适合客户端应用。它们唯一的区别就是：Serial Old 工作在老年代，使用“标记-整理”算法；Serial 工作在新生代，使用“复制”算法。

4.4.5 Parallel Old 垃圾收集器（多线程）

Parallel Old 收集器是 Parallel Scavenge 的老年代版本，追求 CPU 吞吐量。

4.4.6 CMS回收器(低延迟)

CMS:Concurrent Mark Sweep ,并发标记清除.

以获取最短回收停顿时间为目标的收集器,**在垃圾收集时是用户线程和GC线程并发执行,**所以在垃圾收集时用户并不会感到明显的卡顿

**初始标记:**Stop The World,仅使用一条初始标记线程对所有与GC ROOTS直接关联的对象进行标记

并发标记:使用多线标记线程,与用户线程并发执行.此过程可进行可达性分析,标记废弃对象

**重新标记:**Stop The World 使用多条标记线程并发执行,将并发标记过程新出现的废弃对象标记出来

**并发清除:**只是用一条GC线程,与用户线程并发执行,清除标记的对象,此过程非常耗时

并发标记与并发清除过程耗时最长，且可以与用户线程一起工作，因此，总体上说，CMS 收集器的内存回收过程是与用户线程一起并发执行的。

优点:

并发收集,低延迟

缺点:

1. 产生内存碎片,导致并发清除后,用户线程可用的空间不足
2. CMS收集器对CPU资源非常敏感,并发阶段,会占用一部分线程导致应用程序变慢,总吞吐量降低
3. CMS收集器无法处理浮动垃圾.可能出现"Concurrent Mode Failure"失败而导致另一次 Full GC 的产生。
4. G1(Garbage First)回收器

为什么要发布Garbage First GC

原因就在于应用程序所应对的业务越来越庞大、复杂，用户越来越多，没有GC 就不能保证应用程序正常进行，而经常造成 STW 的 GC 又跟不上实际的需求，所以才会不断地尝试对 GC 进行优化。G1（Garbage-First）垃圾回收器是在 Java7 update 4 之后引入的一个新的垃圾回收器，是当今收集器技术发展的最前沿成果之一.

与此同时，为了适应现在不断扩大的内存和不断增加的处理器数量，进一步降低暂停时间（pause time），同时兼顾良好的吞吐量。

为什么叫做G1呢?

G1是一个并行回收器,将堆内存分割为不相关的区域,使用不同的Region来表示Eden,s0,s1区,老年区

G1跟踪各个Region里面的垃圾堆积的价值大小(回收获得空间大小和回收所需时间),在后台维护优先列表,每次根据循序的收集时间,优先回收价值最大的Region

由于侧重回收垃圾最大量的区间,所以叫垃圾优先

G1（Garbage-First）是一款面向服务端应用的垃圾收集器，主要针对配备多核 CPU 及大容量内存的机器，以极高概率满足 Gc 停顿时间的同时，还兼具高吞吐量的性能特征。

从整体上看，G1 是基于“标记-整理”算法实现的收集器，从局部（两个 Region之间）上看是基于“复制”算法实现的，这意味着运行期间不会产生内存空间碎片。

问题:一个对象和它内部所引用的对象可能不在同一个 Region 中，那么当垃圾回收
时，是否需要扫描整个堆内存才能完整地进行一次可达性分析

并不！

每个 Region 都有一个 Remembered Set，用于记录本区域中所有对象引用的对象所在的区域，进行可达性分析时，只要在 GC Roots 中再加上Remembered Set 即可防止对整个堆内存进行遍历。

如果不计算维护 Remembered Set 的操作，G1 收集器的工作过程分为以下几个步骤：

初始标记：Stop The World，仅使用一条初始标记线程对所有与 GC Roots 直接关联的对象进行标记。

并发标记：使用一条标记线程与用户线程并发执行。此过程进行可达性分析，速度很慢。

最终标记：Stop The World，使用多条标记线程并发执行。

筛选回收：回收废弃对象，此时也要 Stop The World，并使用多条筛选回收线程并发执行。