【JVM】垃圾回收 GC
一、前言
垃圾回收（Garbage Collection，GC）是由 Java 虚拟机（JVM）垃圾回收器提供的一种对内存回收的一种机制，它一般会在内存空闲或者内存占用过高的时候对那些没有任何引用的对象不定时地进行回收。以避免内存溢出和崩溃的问题。JVM的垃圾回收算法包括引用类型、引用计数器法、可达性分析算法和标记-清除算法等。
Java 内存运行时区域中的程序计数器、虚拟机栈、本地方法栈随线程而生灭；栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的（尽管在运行期会由 JIT 编译器进行一些优化），因此这几个区域的内存分配和回收都具备确定性，不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。
而 Java 堆不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器所关注的是这部分内存。
二、内存中“垃圾”的定义
程序在运行过程中会创建对象，但是当方法执行完成或当这个对象使用完毕之后，被定义为垃圾。判定一个对象是否是垃圾，即判定一个对象的存活与否，常见的算法有两种：引用计数法 和 根搜索算法。
1. 引用计数算法（Reachability Counting）
一个对象被创建之后，系统会给这个对象初始化一个引用计数器，当这个对象被引用了，则计数器 +1，而当该引用失效后，计数器便 -1，直到计数器为 0，意味着该对象不再被使用了，则可以将其进行回收了。
这种算法其实很好用，判定比较简单，效率也很高，但是却有一个很致命的缺点，就是它无法避免循环引用，即两个对象之间循环引用的时候，各自的计数器始终不会变成 0，所以 引用计数算法 只出现在了早期的 JVM 中，现在基本不再使用了。
当程中出现序循环引用时，引用计数算法无法检测出来，被循环引用的内存对象就成了无法回收的内存。从而引起内存泄露。
2. 根搜索算法（Tracing Collector）
根搜索算法的中心思想（可达性分析算法），以一系列被称为GC Roots的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连时，证明该对象不再存活可以作为垃圾被回收。这种算法很好地解决了上面 引用计数算法 的循环引用的问题了。
算法的核心思想是很简单的，就是标记不可达对象，然后交由 GC 进行回收。
根对象，一般有如下几种：
-
虚拟机栈中引用的对象（栈帧中的本地变量表）；
-
方法区中常量引用的对象；
-
方法区中静态属性引用的对象；
-
本地方法栈中 JNI（Native 方法）引用的对象；
不可达的对象一定会被回收吗？
即使在根搜索算法（可达性分析算法）判断不可达的对象，也并非是 " 非死不可的 "。
如果对象在进行根搜索算法后发现没有与GC Roots相连的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法或finalize()方法已经被调用过，finalize()方法都不会执行，该对象将会被回收。
如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会被放置在一个叫做F-Queue的队列中，然后由Finalizer线程去执行。GC将会对F-Queue中的对象进行第二次标记，如果对象finalize()方法中重新与引用链上的任何一个对象建立关联，那么在第二次标记时将会被移除 " 即将回收 " 的集合，否则该对象将会被回收。
三、引用分类
1. 强引用：StrongReference
强引用是使用最普遍的引用。如果一个对象具有强引用，那垃圾回收器绝不会回收它。当内存空间不足，Java 虚拟机宁愿抛出 OutOfMemoryError 错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足的问题。
2. 软引用：SoftReference
软引用是用来描述一些有用但并不是必需的对象，在 Java 中用 java.lang.ref.SoftReference 类来表示。对于软引用关联着的对象，只有在内存不足的时候 JVM 才会回收该对象。因此，这一点可以很好地用来解决 OOM 的问题，并且这个特性很适合用来实现缓存：比如网页缓存、图片缓存等。
软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被JVM回收，这个软引用就会被加入到与之关联的引用队列中。
3. 弱引用：WeakReference
弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。
4. 虚引用：PhantomReference
“虚引用”也称为幽灵引用或幻影引用，顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。虚引用和前面的软引用、弱引用不同，它并不影响对象的生命周期。在 Java 中用 java.lang.ref.PhantomReference类表示。如果一个对象与虚引用关联，则跟没有引用与之关联一样，在任何时候都可能被垃圾回收器回收。要注意的是，虚引用必须和引用队列关联使用，当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会把这个虚引用加入到与之 关联的引用队列中。程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。如果程序发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存被回收之前采取必要的行动。
5. 跨代引用
跨代引用：也就是一个代中的对象引用另一个代中的对象。
跨代引用假说：跨代引用相对于同代引用来说只是极少数。
隐含推论：存在互相引用关系的两个对象，是应该倾向于同时生存或同时消亡。
四、垃圾回收算法
1. 标记-清除算法：Mark-Sweep
这是最基础的算法，就像它名字一样，算法分为“标记”和“清除”两个阶段：首先标记处所有需要回收的对象（如哪些内存需要回收所描述的对象），对标记完成后统一回收所有被标记的对象，如下图所示：
该算法的优点是当存活对象比较多的时候，性能比较高，因为该算法只需要处理待回收的对象，而不需要处理存活的对象。但是缺点也很明显，清除之后会产生大量不连续的内存碎片。导致之后程序在运行时需要分配较大的对象时，无法找到足够的连续内存。
2. 标记-整理算法：Mark-Compact
上述的 标记-清除 算法会产生内存区域使用的间断，所以为了将内存区域尽可能地连续使用， 标记-整理 算法应运而生。标记-整理 算法也是由两步组成，标记 和 整理。
和标记清除算法一样，先进行对象的标记，通过GC Roots节点扫描存活对象进行标记，将所有存活对象往一端空闲空间移动，按照内存地址依次排序，并更新对应引用的指针，然后清理末端内存地址以外的全部内存空间。
但是同样，标记整理算法也有它的缺点，一方面它要标记所有存活对象，另一方面还添加了对象的移动操作以及更新引用地址的操作，因此标记整理算法具有更高的使用成本。
3. 复制算法：Copying
无论是标记-清除算法还是标记-整理算法，都会涉及句柄的开销或是面对碎片化的内存回收，所以，复制算法 出现了。
复制算法将内存区域均分为了两块（记为S0和S1），而每次在创建对象的时候，只使用其中的一块区域（例如S0），当S0使用完之后，便将S0上面存活的对象全部复制到S1上面去，然后将S0全部清理掉。复制算法主要被应用于新生代，它将内存分为大小相同的两块，每次只使用其中的一块。在任意时间点，所有动态分配的对象都只能分配在其中一个内存空间，而另外一个内存空间则是空闲的。
但是缺点也是很明显的，可用的内存减小了一半，存在内存浪费的情况。所以 复制算法 一般会用于对象存活时间比较短的区域，例如 年轻代，而存活时间比较长的 老年代 是不适合的，因为老年代存在大量存活时间长的对象，采用复制算法的时候会要求复制的对象较多，效率也就急剧下降，所以老年代一般会使用上文提到的 标记-整理算法。
4. 分代收集算法
实际上，java中的垃圾回收器并不是只使用的一种垃圾收集算法，当前大多采用的都是分代收集法。一般根据对象存活周期的不同，将内存分为几块，一般是把堆内存分为新生代和老年代，再根据各个年代的特点选择最佳的垃圾收集算法。主要思想如下：
-
新生代中，每次收集都会有大量对象死去，所以可以选择复制算法，只需要复制少量对象以及更改引用，就可以完成垃圾收集。
-
老年代中，对象存活率比较高，使用复制算法不能很好的提高性能和效率。另外，没有额外的空间对它进行分配担保，因此选择标记-清除算法或标记-整理算法进行垃圾收集。
至于为什么在某一区域选择某种算法，还是和三种算法的特点息息相关的，再从3个维度进行一下对比：
-
执行效率：从算法的时间复杂度来看，复制算法最优，标记清除次之，标记整理最低。
-
内存利用率：标记整理算法和标记清除算法较高，复制算法最差。
-
内存整齐程度：复制算法和标记整理算法较整齐，标记清除算法最差。
尽管具有很多差异，但是除了都需要进行标记外，还有一个相同点，就是在gc线程开始工作时，都需要STW暂停所有工作线程。
| 标记-清除算法 | 标记-整理算法 | 复制算法 | |
| 速率 | 中等 | 最慢 | 最快 |
| 空间开销 | 少（会堆积碎片） | 少（无堆积碎片） | 通常需要活动对象的两倍空间（无堆积碎片） |
| 移动对象 | 否 | 是 | 是 |
五、垃圾回收器
如果说垃圾收集算法是内存回收的方法论，那么收集器就是内存回收的实践者。垃圾收集器没有在 java 虚拟机规范中进行过多的规定，可以由不同的厂商、不同版本的 JVM 来实现。由于 JDK 的版本处于高速迭代过程中，因此 Java 发展至今已经衍生了众多的垃圾回收器。从不同角度分析垃圾收集器，可以将 GC 分为不同的类型。实际使用时，可以根据实际的使用场景选择不同的垃圾回收器，这也是 JVM 调优的重要部分。
-
当老年代配了 CMS收集器时, 如果内存使用率超过了一定的比例, 系统会抛出 Concurrent Mode Failure，此时会自动采用 Serial Old收集器做 Full GC；
-
红色虚线在 Jdk8时, 将Serial与 CMS的组合和ParNew与 Serial Old的组合声明为废弃, 并在 Jdk9时完全弃用了；
-
黄色虚线在 Jdk14时, 弃用了 Parallel Scavenge与 Serial Old的组合；
-
绿色虚线在 Jdk14时, 完全弃用了 CMS垃圾收集器。
按线程数进行分类，可以分为单线程(串行)垃圾回收器和多线程(并行)垃圾回收器：
1. Serial GC
串行的垃圾收集器有两种，Serial与Serial Old，一般两者搭配使用。只有一个线程进行垃圾回收，使用于小型简单的使用场景，垃圾回收时，其他用户线程会暂停(Stop The World)。
-
优点是简单，对于单CPU，由于没有多线程的交互开销，可能更高效，是默认的Client模式下的新生代收集器。
-
通过-XX:+UseSerialGC开启，会使用Serial+Serial Old的收集器组合。
-
新生代采用Serial，是利用复制算法；老年代使用Serial Old采用标记-整理算法。
2. ParNew GC
多线程(并行)垃圾回收器内部提供多个线程进行垃圾回收，在多 cpu 情况下大大提升垃圾回收效率，但同样也是会暂停其他用户线程。
-
在并发能力好的cpu环境里面，它停顿的时间要比串行收集器短，但对于单cpu或并发能力较弱的CPU，由于多线程的交互开销，可能比串行收集器更差。
-
是Server模式下首选的新生代收集器，且能和CMS收集器配合使用。
-
默认开启的收集线程数和cpu数量一样，运行数量可以通过修改-XX:ParallelGCThreads设定。用于新生代收集，复制算法。
-
使用-XX:+UseParNewGC，和Serial Old收集器组合进行内存回收。
-
使用CMS默认开启ParNew。
3. Parallel GC
Parallel Scavenge 收集器的特点是它的关注点与其他收集器不同，CMS 等收集器的关注点尽可能地缩短垃圾收集时用户线程的停顿时间，而 Parallel Scavenge 收集器的目标则是达到一个可控制的吞吐量（Throughput）。Parallel Old 是 Parallel Scavenge 收集器的老年代版本，使用多线程和“标记－整理”算法。这个收集器是在 JDK 1.6 中才开始提供的。使用 -XX:+UseParallelOldGC 可以在新生代和老生代都使用并行回收回收器，这是一对非常关注吞吐量的垃圾回收器组合，在对吞吐量敏感的系统中，可以考虑使用。参数 -XX:ParallelGCThreads 也可以用于设置垃圾回收时的线程数量。
4. CMS GC
CMS( Concurrent Mark-Sweep ) 是以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾回收器，适用于对停顿比较敏感，并且有相对较多存活时间较长的对象（老年代较大）的应用程序；不过 CMS 虽然减少了回收的停顿时间，但是降低了堆空间的利用率。CMS GC 采用了 Mark-Sweep 算法，因此经过CMS收集的堆会产生空间碎片；为了解决堆空间浪费问题，CMS 回收器不再采用简单的指针指向一块可用堆空间来为下次对象分配使用。而是把一些未分配的空间汇总成一个列表，当 JVM 分配对象空间的时候，会搜索这个列表找到足够大的空间来存放住这个对象。另一方面，由于 CMS 线程和应用程序线程并发执行，CMS GC 需要更多的 CPU 资源。同时，因为 CMS 标记阶段应用程序的线程还是在执行的，那么就会有堆空间继续分配的情况，为了保证在 CMS 回收完堆之前还有空间分配给正在运行的应用程序，必须预留一部分空间。也就是说，CMS 不会在老年代满的时候才开始收集。相反，它会尝试更早的开始收集，已避免上面提到的情况：在回收完成之前，堆没有足够空间分配！默认当老年代使用 68% 的时候，CMS就开始行动了。– XX:CMSInitiatingOccupancyFraction = n 来设置这个阀值。
-
初始标记(STW initial mark)：在这个阶段，需要虚拟机停顿正在执行的任务，官方的叫法 STW(Stop The Word)。这个过程从垃圾回收的"根对象"开始，只扫描到能够和"根对象"直接关联的对象，并作标记。所以这个过程虽然暂停了整个 JVM，但是很快就完成了。
-
并发标记(Concurrent marking)：这个阶段紧随初始标记阶段，在初始标记的基础上继续向下追溯标记。并发标记阶段，应用程序的线程和并发标记的线程并发执行，所以用户不会感受到停顿。
-
并发预清理(Concurrent precleaning)：并发预清理阶段仍然是并发的。在这个阶段，虚拟机查找在执行并发标记阶段新进入老年代的对象(可能会有一些对象从新生代晋升到老年代，或者有一些对象被分配到老年代)。通过重新扫描，减少下一个阶段"重新标记"的工作，因为下一个阶段会 Stop The World。
-
重新标记(STW remark)：这个阶段会暂停虚拟机，回收器线程扫描在 CMS 堆中剩余的对象。扫描从"跟对象"开始向下追溯，并处理对象关联。
-
并发清理(Concurrent sweeping)：清理垃圾对象，这个阶段回收器线程和应用程序线程并发执行。
-
并发重置(Concurrent reset)：这个阶段，重置CMS回收器的数据结构，等待下一次垃圾回收。
5. G1 GC
G1 GC 是 JDK 1.7 中正式投入使用的用于取代 CMS 的压缩回收器，它虽然没有在物理上隔断新生代与老生代，但是仍然属于分代垃圾回收器；G1 GC 仍然会区分年轻代与老年代，年轻代依然分有 Eden 区与 Survivor 区。G1 GC 首先将堆分为大小相等的 Region，避免全区域的垃圾收集，然后追踪每个 Region 垃圾堆积的价值大小，在后台维护一个优先列表，根据允许的收集时间优先回收价值最大的Region；同时 G1 GC 采用 Remembered Set 来存放 Region 之间的对象引用以及其他回收器中的新生代与老年代之间的对象引用，从而避免全堆扫描。
随着 G1 GC 的出现，Java 垃圾回收器通过引入 Region 的概念，从传统的连续堆内存布局设计，逐步走向了物理上不连续但是逻辑上依旧连续的内存块；这样我们能够将某个 Region 动态地分配给 Eden、Survivor、老年代、大对象空间、空闲区间等任意一个。每个 Region 都有一个关联的 Remembered Set（简称 RS），RS 的数据结构是 Hash 表，里面的数据是 Card Table （堆中每 512byte 映射在 card table 1byte）。简单的说 RS 里面存在的是 Region 中存活对象的指针。当 Region 中数据发生变化时，首先反映到 Card Table 中的一个或多个 Card 上，RS 通过扫描内部的 Card Table 得知 Region 中内存使用情况和存活对象。在使用 Region 过程中，如果 Region 被填满了，分配内存的线程会重新选择一个新的 Region，空闲 Region 被组织到一个基于链表的数据结构（LinkedList）里面，这样可以快速找到新的 Region。
G1 GC 的特性如下：
-
并行性：G1在回收期间，可以有多个GC线程同时工作，有效利用多核计算能力；
-
并发性：G1拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行，因此，一般来说，不会在整个回收阶段发生完全阻塞应用程序的情况；
-
分代GC：G1依然是一个分代回收器，但是和之前的各类回收器不同，它同时兼顾年轻代和老年代。对比其他回收器，或者工作在年轻代，或者工作在老年代；
-
空间整理：G1在回收过程中，会进行适当的对象移动，不像CMS只是简单地标记清理对象。在若干次GC后，CMS必须进行一次碎片整理。而G1不同，它每次回收都会有效地复制对象，减少空间碎片，进而提升内部循环速度；
-
可预见性：为了缩短停顿时间，G1建立可预存停顿的模型，这样在用户设置的停顿时间范围内，G1会选择适当的区域进行收集，确保停顿时间不超过用户指定时间。
-
初始标记：标记一下GC Roots能直接关联的对象并修改TAMS值，需要STW但耗时很短。
-
并发标记：从GC Root从堆中对象进行可达性分析找存活的对象，耗时较长但可以与用户线程并发执行。
-
最终标记：为了修正并发标记期间产生变动的那一部分标记记录，这一期间的变化记录在Remembered Set Log 里，然后合并到Remembered Set里，该阶段需要STW但是可并行执行。
-
筛选回收：对各个Region回收价值排序，根据用户期望的GC停顿时间制定回收计划来回收。
按照工作模式分类，可以分为独占式和并发式垃圾回收器。
按工作的内存区间分类，又可分为年轻代垃圾回收器和老年代垃圾回收器。
六、垃圾回收相关概念
1. System.gc() 的理解
在默认情况下，通过 System.gc()者 Runtime.getRuntime().gc() 的调用，会显式触发 Full GC，同时对老年代和新生代进行回收，尝试释放被丢弃对象占用的内存。
然而 System.gc()调用附带一个免责声明，无法保证对垃圾收集器的调用(不能确保立即生效)。
JVM 实现者可以通过 System.gc() 调用来决定 JVM 的 GC 行为。而一般情况下，垃圾回收应该是自动进行的，无须手动触发，否则就太过于麻烦了。在一些特殊情况下，我们可以在运行之间调用 System.gc()。
2. 内存溢出
内存溢出相对于内存泄漏来说，尽管更容易被理解，但是同样的，内存溢出也是引发程序崩溃的罪魁祸首之一。
由于 GC 一直在发展，所有一般情况下，除非应用程序占用的内存增长速度非常快，造成垃圾回收已经跟不上内存消耗的速度，否则不太容易出现 OOM 的情况。
大多数情况下，GC 会进行各种年龄段的垃圾回收，实在不行了就放大招，来一次独占式的 Full GC 操作，这时候会回收大量的内存，供应用程序继续使用。
Javadoc 中对 OutofMemoryError 的解释是，没有空闲内存，并且垃圾收集器也无法提供更多内存。
3. 内存泄漏
内存泄漏也称作“存储渗漏”。严格来说，只有对象不会再被程序用到了，但是 GC 又不能回收他们的情况，才叫内存泄漏。
但实际情况很多时候一些不太好的实践（或疏忽）会导致对象的生命周期变得很长甚至导致 OOM，也可以叫做宽泛意义上的“内存泄漏”。
尽管内存泄漏并不会立刻引起程序崩溃，但是一旦发生内存泄漏，程序中的可用内存就会被逐步蚕食，直至耗尽所有内存，最终出现 OutofMemory 异常，导致程序崩溃。注意，这里的存储空间并不是指物理内存，而是指虚拟内存大小，这个虚拟内存大小取决于磁盘交换区设定的大小。
注意，这里的存储空间并不是指物理内存，而是指虚拟内存大小，这个虚拟内存大小取决于磁盘交换区设定的大小。
内存泄漏的常见例子
-
单例模式
单例的生命周期和应用程序是一样长的，所以在单例程序中，如果持有对外部对象的引用的话，那么这个外部对象是不能被回收的，则会导致内存泄漏的产生。
-
一些提供 close()的资源未关闭导致内存泄漏
数据库连接 dataSourse.getConnection()，网络连接 socket 和 io 连接必须手动 close，否则是不能被回收的。
4. Stop the World
Stop-the-World，简称 STW，指的是 GC 事件发生过程中，会产生应用程序的停顿。停顿产生时整个应用程序线程都会被暂停，没有任何响应，有点像卡死的感觉，这个停顿称为 STW。
可达性分析算法中枚举根节点（GC Roots）会导致所有 Java 执行线程停顿，为什么需要停顿所有 Java 执行线程呢？
-
分析工作必须在一个能确保一致性的快照中进行
-
一致性指整个分析期间整个执行系统看起来像被冻结在某个时间点上
-
如果出现分析过程中对象引用关系还在不断变化，则分析结果的准确性无法保证,会出现漏标,错标问题
-
被 STW 中断的应用程序线程会在完成 GC 之后恢复，频繁中断会让用户感觉像是网速不快造成电影卡带一样，所以我们需要减少 STW 的发生。
-
越优秀，回收效率越来越高，尽可能地缩短了暂停时间。
STW 是 JVM 在后台自动发起和自动完成的。在用户不可见的情况下，把用户正常的工作线程全部停掉。
七、查看 JVM 垃圾回收器和设置垃圾回收器
1. 打印默认垃圾回收器
-XX:+PrintCommandLineFlags -version
JDK 8 默认的垃圾回收器
年轻代使用 Parallel Scavenge GC
老年代使用 Parallel Old GC
2. 打印垃圾回收详细信息
-XX:+PrintGCDetails -version
3. 设置默认垃圾回收器
Serial 回收器
-XX:+UseSerialGC 年轻代使用 Serial GC， 老年代使用 Serial Old GC
ParNew 回收器
-XX:+UseParNewGC 年轻代使用 ParNew GC,不影响老年代。
CMS 回收器
-XX:+UseConcMarkSweepGC 老年代使用 CMS GC。
G1 回收器
-XX:+UseG1GC 手动指定使用 G1 收集器执行内存回收任务。
-XX:G1HeapRegionSize 设置每个 Region 的大小。
