3.3.8 如何判断一个对象需要被干掉

垃圾回收算法 - 图1
图中程序计数器、虚拟机栈、本地方法栈，3 个区域随着线程的生存而生存的。内存分配和回收都是确定的。随着线程的结束内存自然就被回收了，因此不需要考虑垃圾回收的问题。而 Java 堆和方法区则不一样，各线程共享，内存的分配和回收都是动态的。因此垃圾收集器所关注的都是堆和方法这部分内存。
在进行回收前就要判断哪些对象还存活，哪些已经死去。下面介绍两个基础的计算方法
1. 引用计数器计算：给对象添加一个引用计数器，每次引用这个对象时计数器加一，引用失效时减一，计数器等于 0 时就是不会再次使用的。不过这个方法有一种情况就是出现对象的循环引用时 GC 没法回收。
2. 可达性分析计算：这是一种类似于二叉树的实现，将一系列的 GC ROOTS 作为起始的存活对象集，从这个节点往下搜索，搜索所走过的路径成为引用链，把能被该集合引用到的对象加入到集合中。搜索当一个对象到 GC Roots 没有使用任何引用链时，则说明该对象是不可用的。主流的商用程序语言，例如 Java，C# 等都是靠这招去判定对象是否存活的。
（了解一下即可）在 Java 语言汇总能作为 GC Roots 的对象分为以下几种：

  1. 虚拟机栈（栈帧中的本地方法表）中引用的对象（局部变量）
  2. 方法区中静态变量所引用的对象（静态变量）
  3. 方法区中常量引用的对象
  4. 本地方法栈（即 native 修饰的方法）中 JNI 引用的对象（JNI 是 Java 虚拟机调用对应的 C 函数的方式，通过 JNI 函数也可以创建新的 Java 对象。且 JNI 对于对象的局部引用或者全局引用都会把它们指向的对象都标记为不可回收）
  5. 已启动的且未终止的 Java 线程

这种方法的优点是能够解决循环引用的问题，可它的实现需要耗费大量资源和时间，也需要 GC（它的分析过程引用关系不能发生变化，所以需要停止所有进程）

3.3.9 如何宣告一个对象的真正死亡

首先必须要提到的是一个名叫 finalize() 的方法
finalize () 是 Object 类的一个方法、一个对象的 finalize () 方法只会被系统自动调用一次，经过 finalize () 方法逃脱死亡的对象，第二次不会再调用。
补充一句：并不提倡在程序中调用 finalize () 来进行自救。建议忘掉 Java 程序中该方法的存在。因为它执行的时间不确定，甚至是否被执行也不确定（Java 程序的不正常退出），而且运行代价高昂，无法保证各个对象的调用顺序（甚至有不同线程中调用）。在 Java9 中已经被标记为 deprecated ，且 java.lang.ref.Cleaner（也就是强、软、弱、幻象引用的那一套）中已经逐步替换掉它，会比 finalize 来的更加的轻量及可靠。 垃圾回收算法 - 图2
判断一个对象的死亡至少需要两次标记

  1. 如果对象进行可达性分析之后没发现与 GC Roots 相连的引用链，那它将会第一次标记并且进行一次筛选。判断的条件是决定这个对象是否有必要执行 finalize () 方法。如果对象有必要执行 finalize () 方法，则被放入 F-Queue 队列中。
  2. GC 对 F-Queue 队列中的对象进行二次标记。如果对象在 finalize () 方法中重新与引用链上的任何一个对象建立了关联，那么二次标记时则会将它移出 “即将回收” 集合。如果此时对象还没成功逃脱，那么只能被回收了。

如果确定对象已经死亡，我们又该如何回收这些垃圾呢

3.4 垃圾回收算法

不会非常详细的展开，常用的有标记清除，复制，标记整理和分代收集算法

3.4.1 标记清除算法

标记清除算法就是分为 “标记” 和 “清除” 两个阶段。标记出所有需要回收的对象，标记结束后统一回收。这个套路很简单，也存在不足，后续的算法都是根据这个基础来加以改进的。
其实它就是把已死亡的对象标记为空闲内存，然后记录在一个空闲列表中，当我们需要 new 一个对象时，内存管理模块会从空闲列表中寻找空闲的内存来分给新的对象。
不足的方面就是标记和清除的效率比较低下。且这种做法会让内存中的碎片非常多。这个导致了如果我们需要使用到较大的内存块时，无法分配到足够的连续内存。比如下图
垃圾回收算法 - 图3
此时可使用的内存块都是零零散散的，导致了刚刚提到的大内存对象问题

3.4.2 复制算法

为了解决效率问题，复制算法就出现了。它将可用内存按容量划分成两等分，每次只使用其中的一块。和 survivor 一样也是用 from 和 to 两个指针这样的玩法。fromPlace 存满了，就把存活的对象 copy 到另一块 toPlace 上，然后交换指针的内容。这样就解决了碎片的问题。
这个算法的代价就是把内存缩水了，这样堆内存的使用效率就会变得十分低下了
垃圾回收算法 - 图4
不过它们分配的时候也不是按照 1:1 这样进行分配的，就类似于 Eden 和 Survivor 也不是等价分配是一个道理。

3.4.3 标记整理算法

复制算法在对象存活率高的时候会有一定的效率问题，标记过程仍然与 “标记 - 清除” 算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉边界以外的内存
垃圾回收算法 - 图5

3.4.4 分代收集算法

这种算法并没有什么新的思想，只是根据对象存活周期的不同将内存划分为几块。一般是把 Java 堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用 “标记 - 清理” 或者 “标记 - 整理” 算法来进行回收。
说白了就是八仙过海各显神通，具体问题具体分析了而已。

3.5 （了解）各种各样的垃圾回收器

HotSpot VM 中的垃圾回收器，以及适用场景
垃圾回收算法 - 图6
到 jdk8 为止，默认的垃圾收集器是 Parallel Scavenge 和 Parallel Old
从 jdk9 开始，G1 收集器成为默认的垃圾收集器 目前来看，G1 回收器停顿时间最短而且没有明显缺点，非常适合 Web 应用。在 jdk8 中测试 Web 应用，堆内存 6G，新生代 4.5G 的情况下，Parallel Scavenge 回收新生代停顿长达 1.5 秒。G1 回收器回收同样大小的新生代只停顿 0.2 秒。