6.1.1 概述
- Java 和 C++语言的区别，就在于垃圾收集技术和内存动态分配上，C++语言没有垃圾收集技术，需要程序员手动的收集。
- 垃圾收集，不是 Java 语言的伴生产物。早在 1960 年，第一门开始使用内存动态分配和垃圾收集技术的 Lisp 语言诞生。
- 关于垃圾收集有三个经典问题：
哪些内存需要回收？
什么时候回收？
如何回收？ - 垃圾收集机制是 Java 的招牌能力，极大地提高了开发效率。如今，垃圾收集几乎成为现代语言的标配，即使经过如此长时间的发展，Java 的垃圾收集机制仍然在不断的演进中，不同大小的设备、不同特征的应用场景，对垃圾收集提出了新的挑战。
6.1.2 什么是垃圾？
- 垃圾是指在运行程序中没有任何引用指向的对象，这个对象就是需要被回收的垃圾。
- 如果不及时对内存中的垃圾进行清理，那么，这些垃圾对象所占的内存空间会一直保留到应用程序结束，被保留的空间无法被其他对象使用。甚至可能导致内存溢出。
6.1.3 为什么需要 GC？
- 对于高级语言来说，一个基本认知是如果不进行垃圾回收，内存迟早都会被消耗完，因为不断地分配内存空间而不进行回收，就好像不停地生产生活垃圾而从来不打扫一样。
- 除了释放没用的对象，垃圾回收也可以清除内存里的记录碎片。碎片整理将所占用的堆内存移到堆的一端，以便 JVM 将整理出的内存分配给新的对象。
6.1.4 早期垃圾回收
6.1.5Java 垃圾回收机制
6.2.1 垃圾标记阶段算法
- 在堆里存放着几乎所有的 Java 对象实例，在 GC 执行垃圾回收之前，首先需要区分出内存中哪些是有用对象，哪些是垃圾对象。只有被标记为己经是垃圾对象，GC 才会在执行垃圾回收时，释放掉其所占用的内存空间，因此这个过程我们可以称为垃圾标记阶段。
- 那么在 JVM 中究竟是如何标记一个垃圾对象呢？简单来说，当一个对象已经不再被任何引用指向时，就可以宣判为垃圾对象。
- 判断对象是否为垃圾对象一般有两种方式：引用计数算法和可达性分析算法。
- 引用计数算法（Reference Counting）比较简单，对每个对象保存一个整型的引用计数器属性。用于记录对象被引用的情况。
- 对于一个对象 A，只要有任何一个引用指向了对象 A，则对象 A 的引用计数器就加 1；当引用失效时，引用计数器就减 1。只要对象 A 的引用计数器的值为 0，即表示对象 A 不可能再被使用，可进行回收。
- 优点：实现简单，垃圾对象便于辨识；判定效率高，回收没有延迟性。
- 缺点：
1.它需要单独的字段存储计数器，这样的做法增加了存储空间的开销。
2.每次赋值都需要更新计数器，伴随着加法和减法操作，这增加了时间开销。
3.引用计数器有一个严重的问题，即无法处理循环引用的情况。这是一条致命缺陷，导致在.Java 的垃圾回收器中没有使用这类算法。
- 相对于引用计数算法而言，可达性分析算法不仅同样具备实现简单和执行高效等特点，更重要的是该算法可以有效地解决在引用计数算法中循环引用的问题，防止内存泄漏的发生。
- 相较于引用计数算法，这里的可达性分析就是 Java、C#选择的。这种类型的垃圾收集通常也叫作追踪性垃圾收集（Tracing Garbage Collection）
- 虚拟机栈中引用的对象
比如：各个线程被调用的方法中使用到的参数、局部变量等。 - 方法区中类静态属性引用的对象
比如：Java 类的引用类型静态变量 - 所有被同步锁 synchronized 持有的对象
- Java 虚拟机内部的引用。
基 本 数 据 类 型 对 应 的 Class 对 象 ， 一 些 常 驻 的 异 常 对 象 （ 如 ： NullPointerException、OutofMemoryError），系统类加载器。
- 在 finalize()时可能会导致对象复活。
- finalize()方法的执行时间是没有保障的，它完全由 GC 线程决定，极端情况下，若不发生 GC，则 finalize()方法将没有执行机会。
- 一个糟糕的 finalize()会严重影响 GC 的性能。比如 finalize 是个死循环。
6.2.1.5 生存还是死亡？
- 可触及的：从根节点开始，可以到达这个对象。
- 可复活的：对象的所有引用都被释放，但是对象有可能在 finalize()中复活。
- 不可触及的：对象的 finalize()被调用，并且没有复活，那么就会进入不可触及状态。
判定一个对象 objA 是否可回收，至少要经历两次标记过程：
- 如果对象 objA 到 GC Roots 没有引用链，则进行第一次标记。
- 进行筛选，判断此对象是否有必要执行 finalize()方法：
- 如果对象 objA 没有重写 finalize()方法，或者 finalize()方法已经被虚拟机调用过，则虚拟机视为“没有必要执行”，objA 被判定为不可触及的。
- 如果对象 objA 重写了 finalize()方法，且还未执行过，那么 objA 会被插入到队列中，由一个虚拟机自动创建的、低优先级的 Finalizer 线程触发其finalize()方法执行。
- finalize()方法是对象逃脱死亡的最后机会，稍后 GC 会对队列中的对象进行第二次标记。如果 objA 在 finalize()方法中与引用链上的任何一个对象建立了联系，那么在第二次标记时，objA 会被移出“即将回收”集合。之后，对象会再次出现没有引用存在的情况。在这个情况下，finalize()方法不会被再次调用，对象会直接变成不可触及的状态。
6.2.2 垃圾回收阶段算法
当成功区分出内存中存活对象和死亡对象后，GC 接下来的任务就是执行垃圾回收，释放掉无用对象所占用的内存空间，以便有足够的可用内存空间为新对象分配内存。目前在 JVM 中比较常见的三种垃圾收集算法是:
- 标记-复制算法（Copying）
- 标记-清除算法（Mark-Sweep）
- 标记-压缩算法（Mark-Compact）
6.2.2.1 标记-复制算法
它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。在垃 圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后清除 正在使用的内存块中的所有对象，交换两个内存的角色，最后完成垃圾回收。
复制算法的优缺点
优点
- 没有标记和清除过程，实现简单，运行高效
- 复制过去以后保证空间的连续性，不会出现“碎片”问题。
- 此算法的缺点也是很明显的，就是需要两倍的内存空间。
- 对于 G1 这种分拆成为大量 region 的 GC，复制而不是移动，意味着 GC 需要维护 region 之间对象引用关系，不管是内存占用或者时间开销也不小.
复制算法的应用场景
- 如果系统中的垃圾对象很多，复制算法需要复制的存活对象数量并不会太大，效率较高
- 老年代大量的对象存活，那么复制的对象将会有很多，效率会很低
- 在新生代，对常规应用的垃圾回收，一次通常可以回收 70% - 99% 的内存空间。回收性价比很高。所以现在的商业虚拟机都是用这种收集算法回收新生代。
6.2.2.2 标记-清除算法
执行过程
当堆中的有效内存空间被耗尽的时候，然后进行这项工作.
清除：这里所谓的清除并不是真的置空，而是把需要清除的对象地址保存在空闲的地址列表里。下次有新对象需要加载时，判断垃圾的位置空间是否够，如果够，就存放（也就是覆盖原有的地址）
标记-清除算法的优点：
非常基础和常见的垃圾收集算法容易理解
标记-清除算法的缺点：
标记清除算法的效率不算高
这种方式清理出来的空闲内存是不连续的，产生内碎片。
6.2.2.3 标记-压缩算法
背景
复制算法的高效性是建立在存活对象少、垃圾对象多的前提下的。这种情况在新生代经常发生，但是在老年代，更常见的情况是大部分对象都是存活对象。 如果依然使用复制算法，由于存活对象较多，复制的成本也将很高。因此，基于老年代垃圾回收的特性，需要使用其他的算法。
标记-清除算法的确可以应用在老年代中，但是该算法不仅执行效率低下，而且在执行完内存回收后还会产生内存碎片，所以 JVM 的设计者需要在此基础之上进行改进
标记压缩算法执行过程
第一阶段和标记清除算法一样，从根节点开始标记所有被引用对象
第二阶段将所有的存活对象压缩到内存的一端，按顺序排放。之后，清理边界外所有的空间。
标记-压缩算法与标记-清除算法的比较
标记-压缩算法的最终效果等同于标记-清除算法执行完成后，再进行一次内存碎片整理，因此，也可以把它称为标记-清除-压缩（Mark-Sweep-Compact）算法。
二者的本质差异在于标记-清除算法是一种非移动式的回收算法（空闲列表记录位置），标记-压缩是移动式的。是否移动回收后的存活对象是一项优缺点并存的风险决策。
可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时JVM 只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。
标记-压缩算法的优缺点
优点
- 消除了标记-清除算法当中，内存区域分散的缺点，我们需要给新对象分配内存时，JVM 只需要持有一个内存的起始地址即可。
- 消除了复制算法当中，内存减半的高额代价。
- 从效率上来说，标记-压缩算法要低于复制算法。
- 移动对象的同时，如果对象被其他对象引用，则还需要调整引用的地址
- 移动过程中，需要全程暂停用户应用程序。即：STW
6.2.2.4 垃圾回收算法小结
效率上来说，复制算法是当之无愧的老大，但是却浪费了太多内存。而为了尽量兼顾上面提到的三个指标，标记-压缩算法相对来说更平滑一些，但是效率上不尽如人意，它比复制算法多了一个标记的阶段，比标记-清除多了一个整理内存的阶段。
6.2.2.5 分代收集
为什么要使用分代收集
前面所有这些算法中，并没有一种算法可以完全替代其他算法，它们都具有自己独特的优势和特点。分代收集应运而生。
分代收集，是基于这样一个事实：不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。一般是把 Java堆分为新生代和老年代，这样就可以根据各个年代的特点使用不同的回收算法，以提高垃圾回收的效率。
在 Java 程序运行的过程中，会产生大量的对象，其中有些对象是与业务信息相关: 比如 Http 请求中的 Session 对象、线程、Socket 连接，这类对象跟业务直接挂钩，因此生命周期比较长。 但是还有一些对象，主要是程序运行过程中生成的临时变量，这些对象生命周期会比较短，比如：String 对象，由于其不变类的特性，系统会产生大量的这些对象，有些对象甚至只用一次即可回收。
目前几乎所有的 GC 都采用分代手机算法执行垃圾回收的在 HotSpot 中，基于分代的概念，GC 所使用的内存回收算法必须结合年轻代和老年代各自的特点。
年轻代（Young Gen）
年轻代特点：区域相对老年代较小，对象生命周期短、存活率低，回收频繁。
这种情况复制算法的回收整理，速度是最快的。复制算法的效率只和当前存活对象大小有关，因此很适用于年轻代的回收。而复制算法内存利用率不高的问题，通过 hotspot 中的两个 survivor 的设计得到缓解。
老年代（Tenured Gen）
老年代特点：区域较大，对象生命周期长、存活率高，回收不及年轻代频繁。
这种情况存在大量存活率高的对象，复制算法明显变得不合适。一般是由标记- 清除或者是标记-清除与标记-压缩的混合实现。
- Mark 阶段的开销与存活对象的数量成正比。
- Sweep 阶段的开销与所管理区域的大小成正相关。
- Compact 阶段的开销与存活对象的数据成正比。
分代的思想被现有的虚拟机广泛使用。几乎所有的垃圾回收器都区分新生代和老年代。
6.3.1System.gc() 的理解
在默认情况下，通过 System.gc()者 Runtime.getRuntime().gc() 的调用，会显式触发 Full GC，同时对老年代和新生代进行回收，尝试释放被丢弃对象占用的内存。
然而 System.gc()调用附带一个免责声明，无法保证对垃圾收集器的调用(不能确保立即生效)。
JVM 实现者可以通过 System.gc() 调用来决定 JVM 的 GC 行为。而一般情况下，垃圾回收应该是自动进行的，无须手动触发，否则就太过于麻烦了。在一些特殊情况下，我们可以在运行之间调用 System.gc()。
6.3.2 内存溢出与内存泄漏
内存溢出
内存溢出相对于内存泄漏来说，尽管更容易被理解，但是同样的，内存溢出也是引发程序崩溃的罪魁祸首之一。
由于 GC 一直在发展，所有一般情况下，除非应用程序占用的内存增长速度非常快，造成垃圾回收已经跟不上内存消耗的速度，否则不太容易出现 OOM 的情况。
大多数情况下，GC 会进行各种年龄段的垃圾回收，实在不行了就放大招，来一次独占式的 Full GC 操作，这时候会回收大量的内存，供应用程序继续使用。
Javadoc 中对 OutofMemoryError 的解释是，没有空闲内存，并且垃圾收集器也无法提供更多内存。
内存泄漏
内存泄漏也称作“存储渗漏”。严格来说，只有对象不会再被程序用到了，但是 GC 又不能回收他们的情况，才叫内存泄漏。
但实际情况很多时候一些不太好的实践（或疏忽）会导致对象的生命周期变得很长甚至导致 OOM，也可以叫做宽泛意义上的“内存泄漏”。
尽管内存泄漏并不会立刻引起程序崩溃，但是一旦发生内存泄漏，程序中的可用内存就会被逐步蚕食，直至耗尽所有内存，最终出现 OutofMemory 异常，导致程序崩溃。注意，这里的存储空间并不是指物理内存，而是指虚拟内存大小，这个虚拟内存大小取决于磁盘交换区设定的大小。
注意，这里的存储空间并不是指物理内存，而是指虚拟内存大小，这个虚拟内存大小取决于磁盘交换区设定的大小。
常见例子
单例模式
单例的生命周期和应用程序是一样长的，所以在单例程序中，如果持有对外部对象的引用的话，那么这个外部对象是不能被回收的，则会导致内存泄漏的产生。
一些提供 close()的资源未关闭导致内存泄漏
数据库连接 dataSourse.getConnection()，网络连接 socket 和 io 连接必须手动 close，否则是不能被回收的。
6.3.3Stop the World
Stop-the-World，简称 STW，指的是 GC 事件发生过程中，会产生应用程序的停顿。停顿产生时整个应用程序线程都会被暂停，没有任何响应，有点像卡死的感觉，这个停顿称为 STW。
可达性分析算法中枚举根节点（GC Roots）会导致所有 Java 执行线程停顿，为什么需要停顿所有 Java 执行线程呢？
- 分析工作必须在一个能确保一致性的快照中进行
- 一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上
- 如果出现分析过程中对象引用关系还在不断变化，则分析结果的准确性无法保证,会出现漏标,错标问题
- 被 STW 中断的应用程序线程会在完成 GC 之后恢复，频繁中断会让用户感觉像是网速不快造成电影卡带一样，所以我们需要减少 STW 的发生。
- 越优秀，回收效率越来越高，尽可能地缩短了暂停时间。
STW 是 JVM 在后台自动发起和自动完成的。在用户不可见的情况下，把用户正常的工作线程全部停掉。
6.4.1 垃圾回收器概述
如果说垃圾收集算法是内存回收的方法论,那么收集器就是内存回收的实践者.
垃圾收集器没有在 java 虚拟机规范中进行过多的规定，可以由不同的厂商、不同版本的 JVM 来实现。
由于 JDK 的版本处于高速迭代过程中，因此 Java 发展至今已经衍生了众多的垃圾回收器。从不同角度分析垃圾收集器，可以将 GC 分为不同的类型。
实际使用时,可以根据实际的使用场景选择不同的垃圾回收器,这也是 JVM 调优的重要部
6.4.2 垃圾回收器分类
按线程数可以分为单线程(串行)垃圾回收器和多线程(并行)垃圾回收器
单线程垃圾回收器(Serial)
只有一个线程进行垃圾回收,使用于小型简单的使用场景,垃圾回收时,其他用户线程会暂停.
按照工作模式分，可以分为独占式和并发式垃圾回收器。
按工作的内存区间分，又可分为年轻代垃圾回收器和老年代垃圾回收器。
6.4.3GC 性能指标
- 垃圾收集开销：垃圾收集所用时间与总运行时间的比例。
- 内存占用：Java 堆区所占的内存大小。
- 快速：一个对象从诞生到被回收所经历的时间。
6.4.4HotSpot 垃圾收集器
图中展示了 7 种作用于不同分代的收集器，如果两个收集器之间存在连线，则说明它们可以搭配使用。虚拟机所处的区域则表示它是属于新生代还是老年代收集器。
6. 4.5CMS 回收器
CMS 概述
CMS(Concurrent Mark Sweep，并发标记清除)收集器是以获取最短回收停顿时间为目标的收集器（追求低停顿），它在垃圾收集时使得用户线程和 GC 线程并发执行，因此在垃圾收集过程中用户也不会感到明显的卡顿。
垃圾回收过程
初始标记：
Stop The World，仅使用一条初始标记线程对所有与 GC Roots 直接关联的对象进行标记。
并发标记：
垃圾回收线程，与用户线程并发执行。此过程进行可达性分析，标记出所有废弃对象。
重新标记：
Stop The World，使用多条标记线程并发执行，将刚才并发标记过程中新出现的废弃对象标记出来。
并发清除：
只使用一条 GC 线程，与用户线程并发执行，清除刚才标记的对象。 这个过程非常耗时。
并发标记与并发清除过程耗时最长，且可以与用户线程一起工作，因此，总体上 说，CMS 收集器的内存回收过程是与用户线程一起并发执行的。
CMS 的优点：
可以作到并发收集
CMS 的弊端：
- CMS 是基于标记-清除算法来实现的,会产生内存碎片。
- CMS 在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分线程而导致应用程序变慢，总吞吐量会降低。
- CMS 收集器无法处理浮动垃圾（floating garbage）。
三色标记算法
为了提高 JVM 垃圾回收的性能，从 CMS 垃圾收集器开始，引入了并发标记的概念。引入并发标记的过程就会带来一个问题，在业务执行的过程中，会对现有的引用关系链出现改变。
- 黑色:该对象已经被标记过了，且该对象下的属性也全部都被标记过了,例如GCRoots 对象。
- 灰色:对象已经被垃圾收集器扫描过了，但是对象中还存在没有扫描的引用(GC需要从此对象中去寻找垃圾);
- 白色:表示对象没有被垃圾收集器访问过，即表示不可达.
三色标记的过程:
为了解决并发的问题，引入中间状态(灰色)，当一个对象被标记的时候，会有下面几个过程：
- 刚开始，确定为 GC Roots 的对象为黑色。
- 将 GC Roots 直接关联的对象置为灰色。
- 遍历灰色对象的所有引用，灰色对象本身置为黑色，其引用置为灰色。
- 重复步骤 3，直到没有灰色对象为止。
- 结束时，黑色对象存活，白色对象回收。
这个过程正确执行的前提是没有其他线程改变对象间的引用关系，然而，并发标记的过程中，用户线程仍在运行，因此就会产生漏标和错标的情况。
漏标
假设 GC 已经在遍历对象 B 了，而此时用户线程执行了 A.B=null 的操作，切断了 A 到 B 的引用
只要打破任一条件，就可以解决错标的问题。
原始快照和增量更新
原始快照打破的是第一个条件：当灰色对象指向白色对象的引用被断开时，就将这条引用关系记录下来。当扫描结束后，再以这些灰色对象为根，重新扫描一次。
增量更新打破的是第二个条件：当黑色指向白色的引用被建立时，就将这个新的引用关系记录下来，等扫描结束后，再以这些记录中的黑色对象为根，重新扫描一次。相当于黑色对象一旦建立了指向白色对象的引用，就会变为灰色对象。
总结
CMS 为了让 GC 线程和用户线程一起工作，回收的算法和过程比以前旧的收集器要复杂很多。究其原因，就是因为 GC 标记对象的同时，用户线程还在修改对象的引用关系。因此 CMS 引入了三色算法，将对象标记为黑、灰、白三种颜色的对象，将用户线程修改的引用关系记录下来，以便在「重新标记」阶段可以修正对象的引用。
虽然 CMS 从来没有被 JDK 当做默认的垃圾收集器，存在很多的缺点，但是它开启了「GC 并发收集」的先河，为后面的收集器提供了思路。
6.4.6G1(Garbage First)回收器
既然我们已经有了前面几个强大的 GC，为什么还要发布 Garbage First（G1）GC？
原因就在于应用程序所应对的业务越来越庞大、复杂，用户越来越多，没有GC 就不能保证应用程序正常进行，而经常造成 STW 的 GC 又跟不上实际的需求，所以才会不断地尝试对 GC 进行优化。G1（Garbage-First）垃圾回收器是在 Java7 update 4 之后引入的一个新的垃圾回收器，是当今收集器技术发展的最前沿成果之一.
与此同时，为了适应现在不断扩大的内存和不断增加的处理器数量，进一步降低暂停时间（pause time），同时兼顾良好的吞吐量。
官方给 G1 设定的目标是在延迟可控的情况下获得尽可能高的吞吐量，所以才担当起“全功能收集器”的重任与期望。
G1 是一款面向服务端应用的垃圾收集器。
为什么名字叫做 Garbage First（G1）呢？
因为 G1 是一个并行回收器，它把堆内存分割为很多不相关的区域（Region）（物理上不连续的逻辑上连续的）。使用不同的 Region 来表示 Eden、幸存者0 区，幸存者 1 区，老年代等。
G1 GC 有计划地避免在整个 Java 堆中进行全区域的垃圾收集。G1 跟踪各个 Region 里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的 Region.
由于这种方式的侧重点在于回收垃圾最大量的区间（Region），所以我们给 G1 一个名字：垃圾优先（Garbage First）。
G1（Garbage-First）是一款面向服务端应用的垃圾收集器，主要针对配备多核 CPU 及大容量内存的机器，以极高概率满足 GC 停顿时间的同时，还兼具高吞吐量的性能特征。
如下图所示，G1 收集器收集器收集过程有初始标记、并发标记、最终标记、筛选回收，和 CMS 收集器前几步的收集过程很相似：
- 初始标记：标记出 GC Roots 直接关联的对象，这个阶段速度较快，需要停止用户线程，单线程执行。
- 并发标记：从 GC Root 开始对堆中的对象进行可达新分析，找出存活对象，这个阶段耗时较长，但可以和用户线程并发执行。
- 最终标记：修正在并发标记阶段引用户程序执行而产生变动的标记记录。
- 筛选回收：筛选回收阶段会对各个 Region 的回收价值和成本进行排序，根据用户所期望的 GC 停顿时间来指定回收计划（用最少的时间来回收包含垃圾最多的区域.这就是 Garbage First 的由来——第一时间清理垃圾最多的区块），这里为了提高回收效率，并没有采用和用户线程并发执行的方式，而是停顿用户线程。
适用场景：要求尽可能可控 GC 停顿时间；内存占用较大的应用。
6.4.7 查看 JVM 垃圾回收器设置垃圾回收器
打印默认垃圾回收器
JDK 8 默认的垃圾回收器
年轻代使用 Parallel Scavenge GC
老年代使用 Parallel Old GC
打印垃圾回收详细信息
设置默认垃圾回收器
Serial 回收器
ParNew 回收器
CMS 回收器
# G1 回收器
版权声明：
本文来源网络，所有图片文章版权属于原作者，如有侵权，联系删除。
本文网址：https://www.mushiming.com/mjsbk/9770.html