13、JVM实战 – 内存与垃圾回收(六) — 垃圾回收(二)

1.标记阶段算法：引用计数算法、可达性分析算法

1.1 垃圾标记阶段：对象存活判断

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

1.2 引用计数算法：

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

1.2.1 循环引用举例：

对象之间互相调用，rc的值无法为0，造成内存泄漏
如图：

1、对象p调用一个对象A，A调用另一个对象B，B调用对象C，C又调用对象A，；
2、此时对象A计数2，B和C为1；
3、此时如果P不再调用对象A，A计数-1，但是A、B和C计数器还是1，无法被回收；

代码：

public class RefCountGC {

    private byte[] bigSize = new byte[5 * 1024 * 1024]; // 5M
    Object reference = null;

    public static void main(String[] args) {

        RefCountGC obj1 = new RefCountGC();
        RefCountGC obj2 = new RefCountGC();

        obj1.reference = obj2;
        obj2.reference = obj1;

        obj1 = null;
        obj2 = null;

        // 显示进行GC回收
        System.gc();
    }
}

如果使用引用计数算法，那么堆中的这2个对象就无法回收。

使用-Xlog:gc*查看回收情况：可以看到还是发生了回收

1.2.2 引用计数算法小结：

引用计数算法，是很多语言的资源回收选择，例如因人工智能而更加火热的Python，它更是同时支持引用计数和垃圾收集机制。
具体哪种最优是要看场景的，业界有大规模实践中仅保留引用计数机制，以提高吞吐量的尝试。
Java并没有选择引用计数，是因为其存在一个基本的难题，也就是很难处理循环引用关系。
Python 如何解决循环引用？
手动解除：很好理解，就是在合适的时机，解除引用关系。
使用弱引用weakref，weakref是Python提供的标准库，旨在解决循环引用。

1.3 可达性分析算法（根搜索或者追踪性垃圾收集）：

相对于引用计数算法而言，可达性分析算法不仅同样具备实现简单和执行高效等特点，更重要的是该算法可以有效地解决在引用计数算法中循环引用的问题，防止内存泄漏的发生。
相较于引用计数算法，这里的可达性分析就是Java、C#选择的。这种类型的垃圾收集通常也叫作追踪性垃圾收集（Tracing GarbageCollection）。
所谓"GC Roots"根对象集合就是一组必须活跃的引用。
基本思路：
可达性分析算法是以根对象集合(GCRoots）为起始点，按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达。
使用可达性分析算法后，内存中的存活对象都会被根对象集合直接或间接连接着，搜索所走过的路径称为引用链（Reference Chain）
如果目标对象没有任何引用链相连，则是不可达的，就意味着该对象己经死亡，可以标记为垃圾对象。
在可达性分析算法中，只有能够被根对象集合直接或者间接连接的对象才是存活对象。
可达性分析算法使用三色分析法来对对象进行标记

1.3.1 GC Roots包括以下几类元素：

虚拟机栈中引用的对象
比如：各个线程被调用的方法中使用到的参数、局部变量等。
本地方法栈内JNI（通常说的本地方法）引用的对象
方法区中类静态属性引用的对象
比如：Java类的引用类型静态变量
方法区中常量引用的对象
比如：字符串常量池（string Table）里的引用
所有被同步锁synchronized持有的对象
Java虚拟机内部的引用。
基本数据类型对应的Class对象，一些常驻的异常对象（如：NullPointerException、OutOfMemoryError），系统类加载器。
反映java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等
除了这些固定的GCRoots集合以外，根据用户所选用的垃圾收集器以及当前回收的内存区域不同，还可以有其他对象“临时性”地加入，共同构成完整GC Roots集合。比如：分代收集和局部回收（Partial GC）。
如果只针对Java堆中的某一块区域进行垃圾回收（比如：典型的只针对新生代），必须考虑到内存区域是虚拟机自己的实现细节，更不是孤立封闭的，这个区域的对象完全有可能被其他区域的对象所引用，这时候就需要一并将关联的区域对象也加入GC Roots集合中去考虑，才能保证可达性分析的准确性。

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

上述最后一点可以看成是，只针对新生代进行回收，把堆中其他区域如老年代当成GC Roots的集合。

1.3.2 注意：

如果要使用可达性分析算法来判断内存是否可回收，那么分析工作必须在一个能保障一致性的快照中进行。这点不满足的话分析结果的准确性就无法保证。
这点也是导致GC进行时必须“Stop The World"的一个重要原因。
即使是号称（几乎）不会发生停顿的CMS收集器中，枚举根节点时也是必须要停顿的。

1.4 可达性分析法的三色标记过程

可达性分析算法先找到存活的对象，然后给存活的对象打个标记，最终在清理的时候，如果一个对象没有任何标记，就表示这个对象不可达，需要被清理，标记算法就是使用的三色标记。并发标记阶段是从GC Root直接关联的对象开始枚举的过程。

对于三色标记算法而言，对象会根据是否被访问过（也就是是否在可达性分析过程中被检查过）被分为三个颜色：白色、灰色和黑色：

白色：这个对象还没有被访问过，在初始阶段，所有对象都是白色，所有都枚举完仍是白色的对象将会被当做垃圾对象被清理。
灰色：这个对象已经被访问过，但是这个对象所直接引用的对象中，至少还有一个没有被访问到，表示这个对象正在枚举中。
黑色：对象和它所直接引用的所有对象都被访问过。这里只要访问过就行，比如A只引用了B，B引用了C、D，那么只要A和B都被访问过，A就是黑色，即使B所引用的C或D还没有被访问到，此时B就是灰色。

根据这些定义，我们可以得出：

在可达性分析的初始阶段，所有对象都是白色，一旦访问了这个对象，那么就变成灰色，一旦这个对象所有直接引用的对象都访问过（或者没有引用其它对象），那么就变成黑色
初始标记之后，GC Root节点变为黑色（GC Root不会是垃圾），GC Root直接引用的对象变为灰色
正常情况下，一个对象如果是黑色，那么其直接引用的对象要么是黑色，要么是灰色，不可能是白色（如果出现了黑色对象直接引用白色对象的情况，就说明漏标了，就会导致对象误删，后面会介绍如何解决），这个特性也可以说是三色标记算法正确性保障的前提条件。

算法大致的流程是（初始状态所有对象都是白色）：

1、首先我们从GCRoots开始枚举，它们所有的直接引用变为灰色，自己变为黑色可以想象有一个队列用于存储灰色对象，会把这些灰色对象放到这个队列中；
2、然后从队列中取出一个灰色对象进行分析：将这个对象所有的直接引用变为灰色，放入队列中，然后这个对象变为黑色；如果取出的这个灰色对象没有直接引用，那么直接变成黑色；
3、继续从队列中取出一个灰色对象进行分析，分析步骤和第二步相同，一直重复直到灰色队列为空；
4、分析完成后仍然是白色的对象就是不可达的对象，可以作为垃圾被清理；
5、最后重置标记状态；

前面的描述都比较抽象，这里以一个例子进行说明，假设现在有以下引用关系：

首先，所有GC Root的直接引用（A、B、E）变为灰色，放入队列中，GC Root变为黑色：

然后从队列中取出一个灰色对象进行分析，比如取出A对象，将它的直接引用C、D变为灰色，放入队列，A对象变为黑色：

继续从队列中取出一个灰色对象，比如取出B对象，将它的直接引用F变为灰色，放入队列，B对象变为黑色：

继续从队列中取出一个灰色对象E，但是E对象没有直接引用，变为黑色：

同理依次取出C、D、F对象，他们都没有直接引用，那么变成黑色（这里就不一个一个的画了）：

到这里分析已经结束了，还剩一个G对象是白色，证明它是一个垃圾对象，不可访问，可以被清理掉。

1.4.1 并发标记带来的问题

如果整个标记过程是STW的，那么没有任何问题，但是并发标记的过程中，用户线程也在运行，那么对象引用关系就可能发生改变，进而导致两个问题出现。

1、 非垃圾变为了垃圾：；

比如我们回到上述流程中的这个状态：

此时E对象已经被标记为黑色，表示不是垃圾，不会被清除。此时某个用户线程将GC Root2和E对象之间的关联断开了（比如 xx.e=null;）:

后面的图就不用画了，很显然，E对象变为了垃圾对象，但是由于已经被标记为黑色，就不会被当做垃圾删除，姑且也可以称之为浮动垃圾。

1、 垃圾变为了非垃圾；

如果上面提到的浮动垃圾你觉得没啥所谓，即使本次不清理，下一次GC也会被清理，而且并发清理阶段也会产生所谓的浮动垃圾，影响不大。但是如果一个垃圾变为了非垃圾，那么后果就会比较严重。比如我们回到上述流程中的这个状态：

标记的下一步操作是从队列中取出B对象进行分析，但是这个时候GC线程的时间片用完了，操作系统调度用户线程来运行，而用户线程先执行了这个操作：A.f = F；那么引用关系变成了：

接着执行：B.f=null；那么引用关系变成了：

好了，用户线程的事儿干完了，GC线程重新开始运行，按照之前的标记流程继续走：从队列中取出B对象，发现B对象没有直接引用，那么将B对象变为黑色：

接着继续分别从队列中取出E、C、D三个灰色对象，它们都没有直接引用，那么变为黑色对象：

到现在所有灰色对象分析完毕，你肯定已经发现问题了，出现了黑色对象直接引用白色对象的情况，而且虽然F是白色对象，但是它是垃圾吗？显然不是垃圾，如果F被当做垃圾清理掉了，那就GG~

1.4.2 增量更新和原始快照(SATB)

上面一共出现了两个问题，从结果上来看，可以这样描述：

一个本应该是垃圾的对象被视为了非垃圾
一个本应该不是垃圾的对象被视为了垃圾

对于第一个问题，我们前文也提到了，即使不去处理它也无所谓，大不了等到下次GC再清理。最重要的是第二个问题，如果误清理了正在被使用的对象，那就是实打实的BUG了。那么如何解决这个问题呢？

出现这个问题的主要原因是，一个对象从被B引用，变更为了被A引用。那么对于A来说就是多了一个直接引用，对于B来说就是少了一个直接引用。我们可以从这两个方面入手来解决这个问题，对应了也有两个方案，分别是增量更新（Incremental Update）和原始快照（SATB，Snapshot At The Beginning）。

1、 读写屏障；
在这讲述解决方案之前，要描述两个名词：读屏障和写屏障。注意，这里的屏障和并发编程中的屏障是两码事儿。这里的屏障很简单，可以理解成就是在读写操作前后插入一段代码，用于记录一些信息、保存某些数据等，概念类似于AOP。
2、 增量更新；
增量更新是站在新增引用的对象（也就是例子中的A对象）的角度来解决问题。所谓增量更新，就是在赋值操作之前添加一个写屏障，在写屏障中记录新增的引用。比如，用户线程要执行：A.f = F；那么在写屏障中将新增的这个引用关系记录下来。标准的描述就是，当黑色对象新增一个白色对象的引用时，就通过写屏障将这个引用关系记录下来。然后在重新标记阶段，再以这些引用关系中的黑色对象为根，再扫描一次，以此保证不会漏标。
在我们这个例子中，在并发标记阶段，A是一个黑色对象，F是一个白色对象，A引用了F，这个引用关系会被记录下来，然后通过这个记录在重新标记阶段再从A对象开始枚举一次，保证如果A还是保持着F的引用，那么F会被正确标记；如果A到F的引用在并发标记阶段又断开了，此次枚举也无法访问到它，活该被清除。
要实现也很简单，在重新标记阶段直接把A对象（和其它有相同情况发生的对象）变为灰色，放入队列中，再来一次枚举过程。要注意，在重新标记阶段如果用户线程还是继续执行，那么这个GC永远可能也做不完了，所以重新标记需要STW，但是这个时间消耗不会太夸张。如果实在重新标记阶段耗时过长，那么可以尝试在重新标记之前做一次Minor GC，这个在CMS垃圾收集器中有介绍，这里就不赘述了。
3、 原始快照(SATB)；
原始快照是站在减少引用的对象（也就是例子中的B对象）的角度来解决问题。所谓原始快照，简单的讲，就是在赋值操作（这里是置空）执行之前添加一个写屏障，在写屏障中记录被置空的对象引用。比如，用户线程要执行：B.f=null；那么在写屏障中，首先会把B.f记录下来，然后再进行置空操作。记录下来的这个对象就可以称为原始快照。
那么记录下来之后呢？很简单，之后直接把它变为黑色。意思就是默认认为它不是垃圾，不需要将其清理。当然，这样处理有两种情况，一种情况是，F的确不是垃圾，直到清理的那一刻，都仍然有至少一个引用链能访问到它，这没有什么问题；另一种情况就是F又变成了垃圾。在上述的例子中，就是A到F的引用链也断了，或者直接A都成垃圾了，那F对象就成了浮动垃圾。对于浮动垃圾，前面不止一次就提到了，直接不用理会，如果到下一次GC时它仍然是垃圾，自然会被清理掉。
4、 方案抉择；
从增量更新和原始快照的实现（理论上）就可以发现，原始快照相比于增量更新来说效率会更高，因为不用在重新标记阶段再去做枚举遍历，但是也就可能会导致有更多的浮动垃圾。G1使用的就是原始快照，CMS使用的是增量更新。
既然原始快照可能会有更严重的浮动垃圾问题，那么为什么不使用增量更新呢？原因可能很简单，就是因为简单。想象一下，G1虽然也是基于年轻代和老年代的分代收集算法，但是年轻代和老年代被弱化为了逻辑上，其所管理的内存被划分为了很多region，对象跨代引用带来的问题在G1中要比传统的分代收集器更加突出，虽然有Remember Set方案缓解，但是相对来说在重新标记阶段进行再次遍历枚举的代价会大很多。最重要的是，重新标记（最终标记）阶段是会STW的，如果这个阶段花费太多的时间去做可达性分析，那么就违背了G1低延时的理念。当然这个是博主的猜测，如果读者朋友有更好的想法，欢迎提出。

1.4.3 小结

这里有一个需要注意的点，重新标记阶段会STW，以此保证标记结果的正确性（主要是漏标）。到现在你可能理解了，垃圾收集器中所描述的：并发清理阶段产生的垃圾会被当做浮动垃圾，只能留待下一次GC被清理。那么实际上是怎么回事呢？其实就很简单了，只要在并发清理阶段产生的对象，直接就认为是黑色对象，全部都不是垃圾。如果一个对象最终成了垃圾，那它就是浮动垃圾，如果没成垃圾，那么标记为黑色也没有什么问题。因为到了清理阶段，标记工作已经完成，没有办法再找到合适的方式去处理这个问题，不然一次GC可能永远也结束不了。
话说回来，对于上面漏标的情况，你可能还有一个疑问：在并发标记过程中，除了引用关系发生变更的情况，如果用户线程直接创建了一个新对象，这个对象默认是白色，又直接和黑色对象关联，那又该当如何呢？也就是白色对象可能是从其他对象的引用链上”转移“过来的，也可能就是一个新对象。其实可以想象的到，对于新对象加入到黑色节点，我们无法使用原始快照，但是可以使用增量更新，或者直接简单处理，和并发清理阶段一样：在这期间创建的新对象都认为不是垃圾（比如标记为黑色），如果成了垃圾，那就是浮动垃圾，还是留待下一次GC处理。总之，标记的总体原则就是，“另可放过，不可杀错”。
关于黑白灰三个颜色，是一个抽象的概念，虽然使用可达性分析的垃圾收集器基本都采取三色标记的思想，但在实现上可能也各不相同，像如何标识颜色、灰色队列如何实现等等。比如不止Java，在go的GC中也实现了三色标记算法。个人认为作为普通开发人员，理解思想就够了，如果要看具体的实现，就需要具体到实际的实现源码中去探寻。

2.对象的finalization机制

Java语言提供了对象终止（finalization）机制来允许开发人员提供对象被销毁之前的自定义处理逻辑。
当垃圾回收器发现没有引用指向一个对象，即：垃圾回收此对象之前，总会先调用这个对象的finalize()方法。
finalize()方法允许在子类中被重写，用于在对象被回收时进行资源释放。通常在这个方法中进行一些资源释放和清理的工作，比如关闭文件、套接字和数据库连接等。
永远不要主动调用某个对象的finalize()方法，应该交给垃圾回收机制调用。理由包括下面三点：
在finalize()时可能会导致对象复活。
finalize()方法的执行时间是没有保障的，它完全由Gc线程决定，极端情况下，若不发生GC，则finalize() 方法将没有执行机会。
一个糟糕的finalize()会严重影响GC的性能。
从功能上来说，finalize()方法与C++ 中的析构函数比较相似，但是Java采用的是基于垃圾回收器的自动内存管理机制，所以finalize()方法在本质，上不同于C++ 中的析构函数。
由于finalize ()方法的存在，虚拟机中的对象一般处于三种可能的状态：可触及的，可复活的，不可触及的

2.1 对象的三种状态：

如果从所有的根节点都无法访问到某个对象，说明对象己经不再使用了。一般来说，此对象需要被回收。但事实上，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段。一个无法触及的对象有可能在某一个条件下“复活”自己，如果这样，那么对它的回收就是不合理的，为此，定义虚拟机中的对象可能的三种状态。如下：
可触及的：从根节点开始，可以到达这个对象。
可复活的：对象的所有引用都被释放，但是对象有可能在finalize()中复活。
不可触及的：对象的finalize()被调用，并且没有复活，那么就会进入不可触及状态。不可触及的对象不可能被复活，因为finalize()只会被调用一一次。
以上3种状态中，是由于finalize()方法的存在，进行的区分。只有在对象不可触及时才可以被回收。

2.2 判定是否可以回收具体过程

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

2.3 代码测试可复活对象：

/**
 * 测试Object类中finalize()方法，即对象的finalization机制。
 */
public class CanReliveObj {

    public static CanReliveObj obj;//类变量，属于 GC Root

    //此方法只能被调用一次
    @Override
    protected void finalize() throws Throwable {

        super.finalize();
        System.out.println("调用当前类重写的finalize()方法");
        obj = this;//当前待回收的对象在finalize()方法中与引用链上的一个对象obj建立了联系
    }

    public static void main(String[] args) {

        try {

            obj = new CanReliveObj();
            // 对象第一次成功拯救自己
            obj = null;
            System.gc();//调用垃圾回收器
            System.out.println("第1次 gc");
            // 因为Finalizer线程优先级很低，暂停2秒，以等待它
            Thread.sleep(2000);
            if (obj == null) {

                System.out.println("obj is dead");
            } else {

                System.out.println("obj is still alive");
            }
            System.out.println("第2次 gc");
            // 下面这段代码与上面的完全相同，但是这次自救却失败了
            obj = null;
            System.gc();
            // 因为Finalizer线程优先级很低，暂停2秒，以等待它
            Thread.sleep(2000);
            if (obj == null) {

                System.out.println("obj is dead");
            } else {

                System.out.println("obj is still alive");
            }
        } catch (InterruptedException e) {

            e.printStackTrace();
        }
    }
}

jdk8测试结果：

第1次 gc
调用当前类重写的finalize()方法
obj is still alive
第2次 gc
obj is dead

jdk13测试结果：

第1次 gc
调用当前类重写的finalize()方法
obj is dead
第2次 gc
obj is dead

2.3.1 jdk13中的finalize()方法：

可以看到jdk9之后finalize方法被设置为过时的

@Deprecated(since="9")
protected void finalize() throws Throwable {

      }

原因：
finalize会拖慢垃圾收集，导致对象堆积，容易导致OOM，而且使用finalize释放资源是不合理的，资源应该是用完立即释放的，或者采用资源池来解决这个问题，而不是依靠被动垃圾回收时触发finalize方法
替代方法：

public class Cleaner
    extends PhantomReference<Object>
{

3. MAT与JProfiler的GC Roots溯源

3.1 获取dump文件

3.1.1 方式1: 命令行使用jmap

jps
jmap -dump:format=b,live,file=test1.bin {

     进程id}

3.1.2 方式2：使用JVisualVM导出

捕获的heap dump文件是一个临时文件，关闭JVisualVM后自动删除，若要保留，需要将其另存为文件。
可通过以下方法捕获heap dump：
在左侧“Application”（应用程序）子窗口中右击相应的应用程序，选择Heap Dump（堆Dump)。
在Monitor （监视）子标签页中点击Heap Dump （堆Dump）按钮。
本地应用程序的Heap dumps作为应用程序标签页的一个子标签页打开。同时，heap dump在左侧的Application （应用程序）栏中对应一个含有时间戳的节点。右击这个节点选择save as （另存为）即可将heap dump保存到本地。

3.2 MAT查看GC Roots

MAT是Memory Analyzer的简称，它是一款功能强大的Java堆内存分析器。用于查找内存泄漏以及查看内存消耗情况。

MAT是基于Eclipse开发的，是一款免费的性能分析工具。

可通过mat下载下载mat。

3.2.1 代码测试

1、代码：；

public class GCRootsTest {

    public static void main(String[] args) {

        List<Object> numList = new ArrayList<>();
        Date birth = new Date();

        for (int i = 0; i < 100; i++) {

            numList.add(String.valueOf(i));
            try {

                Thread.sleep(10);
            } catch (InterruptedException e) {

                e.printStackTrace();
            }
        }

        System.out.println("数据添加完毕，请操作：");
        // 此时先导出一个dump
        new Scanner(System.in).next();
        numList = null;
        birth = null;

        System.out.println("numList、birth已置空，请操作：");
        new Scanner(System.in).next();

        System.out.println("结束");
    }
}

1、执行代码，在第一个输入输入前导出一个dump：；

数据添加完毕，请操作：

1、输入内容回车，并再次导出一个dump文件；

数据添加完毕，请操作：
继续执行
numList、birth已置空，请操作：

1、将2个dump文件保存到本地；
2、使用mat打开第一个dump文件；

3、点击设置的下拉框，点击javabasics，打开gcroots；

4、相同步骤打开第二dump，对比他们的Thread->java.lang.Thread->main方法中的对象：可以看到第二次的比第一次的少了2个对象；

3.3 使用jProfiler进行GC溯源

看视频。。。

3.4 JProfiler监控OOM

1、代码：；

/**
 * vm参数：
 * -Xms32m -Xmx32m -XX:+HeapDumpOnOutOfMemoryError（生成堆空间dump文件）
 *
 */
public class HeapOOMTest {

    byte[] buffer = new byte[1 * 1024 * 1024];//1MB

    public static void main(String[] args) {

        ArrayList<HeapOOMTest> list = new ArrayList<>();

        int count = 0;
        try{

            while(true){

                list.add(new HeapOOMTest());
                count++;
            }
        }catch (Throwable e){

            System.out.println("count = " + count);
            e.printStackTrace();
        }
    }
}

1、结果：；

java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid10148.hprof ...
Heap dump file created [20481352 bytes in 0.051 secs]
count = 12
java.lang.OutOfMemoryError: Java heap space
    at com.yhx.toali.JVMStudy.GCTest.HeapOOMTest.<init>(HeapOOMTest.java:15)
    at com.yhx.toali.JVMStudy.GCTest.HeapOOMTest.main(HeapOOMTest.java:23)

1、 jprofiler查看：打开生成dump文件（我的默认地址是项目目录）：java_pid10148.hprof；
2、可以看到是因为有arrayList的大对象导致内存溢出；

3、还可以看到是因为什么线程的哪一段代码导致：；

4.清除阶段算法：标记-清除算法、标记-复制算法、标记-压缩算法

4.1 垃圾清除阶段：

当成功区分出内存中存活对象和死亡对象后，GC接下来的任务就是执行垃圾回收，释放掉无用对象所占用的内存空间，以便有足够的可用内存空间为新对象分配内存.

目前在JVM中比较常见的三种垃圾收集算法是标记一清除算法（ Mark一Sweep）、复制算法（Copying）、标记一压缩算法（Mark一Compact）

4.2 标记-清除算法：

4.2.1 背景

标记一清除算法（Mark一Sweep）是一种非常基础和常见的垃圾收集算法，该算法被J . McCarthy等人在1960年提出并并应用于Lisp语言。

4.2.2 执行过程

当堆中的有效内存空间（available memory）被耗尽的时候，就会停止整个程序（也被称为stop the world），然后进行两项工作，第一项则是标记，第二项则是清除。

标记： Collector从引用根节点开始遍历，标记所有被引用的对象。一般是在对象的Header中记录为可达对象。
清除： Collector对堆内存从头到尾进行线性的遍历（即在内存中从头到尾遍历），如果发现某个对象在其Header中没有标记为可达对象，则将其回收。

4.2.3 注意：

标记的是可达对象，也就是不需要清除的对象，这里的标记用的就是可达性分析算法。
何为清除？：这里所谓的清除并不是真的置空，而是把需要清除的对象的地址保存在空闲的地址列表里。下次有新对象需要加载时，判断垃圾的位置空间是否够，如果够，就存放。（即新数据覆盖原有数据）

4.2.4 缺点：

效率不算高（标记时需要递归标记可达对象，清除阶段要遍历全部堆空间）
在进行GC的时候，需要停止整个应用程序，导致用户体验差
这种方式清理出来的空闲内存是不连续的，产生内存碎片。需要维护一个空闲列表。（空闲列表也需要占用内存空间）

4.3 标记-复制算法（复制算法）

4.3.1 背景：

为了解决标记一清除算法在垃圾收集效率方面的缺陷，M.L.Minsky于1963年发表了著名的论文，“ 使用双存储区的Li sp语言垃圾收集器CALISP Garbage Collector Algorithm Using SerialSecondary Storage ）”。M.L. Minsky在该论文中描述的算法被人们称为复制（Copying）算法，它也被M. L.Minsky本人成功地引入到了Lisp语言的一个实现版本中。

4.3.2 核心思想：

将活着的内存空间分为两块，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后清除正在使用的内存块中的所有对象，交换两个内存的角色，最后完成垃圾回收。

使用可达分析算法，将可达的对象复制（复制数据）到B区（至于有没有标记的过程，不能够确定，深入理解Java虚拟机中也没有给出明确的说明）；接下来整个A区就可以都被回收了。幸存者0区和幸存者1区的复制算法就是用的此复制算法。

4.3.3 优缺点：

优点：
没有标记和清除过程，实现简单，运行高效
复制过去以后保证空间的连续性，不会出现“碎片”问题
缺点：
此算法缺点也是明显的，就是需要2倍的内存空间
对于G1这种分拆称为大量region的GC，复制而不是移动，意味着GC需要维护region之间对象引用关系，不管是内存占用或者时间开销也不小。（复制的时候，对象的地址改变了，栈中对此对象的地址以用也会随之改变）

4.3.4 特别的：

如果系统中的存活对象很多，复制算法就不会很理想，因为需要复制的对象很多。复制算法需要复制的存活对象数量并不会太大，或者说非常低才比较高效。

4.3.5 应用场景：新生代区

4.4 标记-压缩（整理）Mark- Compact算法

4.4.1 背景：

复制算法的高效性是建立在存活对象少、垃圾对象多的前提下的。这种情况在新生代经常发生，但是在老年代，更常见的情况是大部分对象都是存活对象。如果依然使用复制算法，由于存活对象较多，复制的成本也将很高。因此，基于老年代垃圾回收的特性，需要使用其他的算法。

标记一清除算法的确可以应用在老年代中，但是该算法不仅执行效率低下，而且在执行完内存回收后还会产生内存碎片，所以JVM的设计者需要在此基础之上进行改进。标记一压缩（Mark一Compact）算法由此诞生。

1970年前后，G. L. Steele 、C. J. Chene和D.S. Wise 等研究者发布标记一压缩算法。在许多现代的垃圾收集器中，人们都使用了标记一压缩算法或其改进版本。

4.4.2 执行过程

1、第一阶段和标记-清除算法一样，从根节点开始标记所有被引用对象；
2、第二阶段将所有存活对象压缩到内存的一端，按顺序排放；
3、最后，清理边界外所有的空间；

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

二者的本质差异在于标记一清除算法是一种非移动式的回收算法，标记一压.缩是移动式的。是否移动回收后的存活对象是一项优缺点并存的风险决策。

可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。

4.4.3 优缺点

优点：
消除了标记-清除算法中，内存区域分散的缺点，我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可（指针碰撞）
消除了复制算法中，内存减半的高额代价
缺点
从效率上来说，标记-整理算法要低于标记-清除算法
移动对象的同时，如果对象被其他对象引用，则还需要调整引用的地址
移动的过程中，需要全程暂停用户应用程序。即：STW

5.小结

6.分代收集算法

按新生代，老年代使用不同的收集算法。

前面所有这些算法中，并没有一种算法可以完全替代其他算法，它们都具有自己独特的优势和特点。分代收集算法应运而生。
分代收集算法，是基于这样一个事实：不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点使用不同的回收算法，以提高垃圾回收的效率。
在Java程序运行的过程中，会产生大量的对象，其中有些对象是与业务信息相关，比如Http请求中的Session对象、线程、Socket连接，这类对象跟业务直接挂钩，因此生命周期比较长。但是还有一些对象，主要是程序运行过程中生成的临时变量，这些对象生命周期会比较短，比如： String对象，由于其不变类的特性，系统会产生大量的这些对象，有些对象甚至只用一次即可回收。

6.1 HotSpot的选择：

新生代：复制算法；
老年代：标记-整理算法；

目前几乎所有的GC都是采用分代收集（Generational Collecting）算法执行垃圾回收的。

在HotSpot中，基于分代的概念，GC所使用的内存回收算法必须结合年轻代和老年代各自的特点。

年轻代（Young Gen）
年轻代特点：区域相对老年代较小，对象生命周期短、存活率低，回收频繁。
这种情况复制算法的回收整理，速度是最快的。复制算法的效率只和当前存活对象大小有关，因此很适用于年轻代的回收。而复制算法内存利用率不高的问题，通过hotspot中的两个survivor的设计得到缓解。（也就是设计2个survivor可以提高复制算法的效率）
老年代（Tenured Gen）：
老年代特点：区域较大，对象生命周期长、存活率高，回收不及年轻代频繁。
这种情况存在大量存活率高的对象，复制算法明显变得不合适。一般是由标记一清除或者是标记一清除与标记一整理的混合实现。
Mark阶段的开销与存活对象的数量成正比。
Sweep阶段的开销与所管理区域的大小成正相关。
Compact阶段的开销与存活对象的数据成正比。

以HotSpot中的CMS回收器为例，CMS是基于Mark一 Sweep实现的，对于对象的回收效率很高。而对于碎片问题，CMS采用基于Mark一Compact算法的Serial 0ld回收器作为补偿措施：当内存回收不佳（碎片导致的Concurrent Mode Failure时），将采用serial old执行Full GC以达到对老年代内存的整理。

分代的思想被现有的虚拟机广泛使用。几乎所有的垃圾回收器都区分新生代和老年代。

7.增量收集算法、分区算法

7.1 增量收集算法

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

7.1.1 基本思想

如果一次性将所有的垃圾进行处理，需要造成系统长时间的停顿，那么就可以让垃圾收集线程和应用程序线程交替执行。每次，垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程。依次反复，直到垃圾收集完成。

总的来说，增量收集算法的基础仍是传统的标记一清除和复制算法。增量收集算法通过对线程间冲突的妥善处理，允许垃圾收集线程以分阶段的方式完成标记、清理或复制工作。

7.1.2 缺点：

使用这种方式，由于在垃圾回收过程中，间断性地还执行了应用程序代码，所以能减少系统的停顿时间。但是，因为线程切换和上下文转换的消耗，会使得垃圾回收的总体成本上升，造成系统吞吐量的下降。

7.2 分区算法

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

分代算法将按照对象的生命周期长短划分成两个部分，分区算法将整个堆空间划分成连续的不同小区间。

每一个小区间都独立使用，独立回收。这种算法的好处是可以控
制一次回收多少个小区间。

13、JVM实战 - 内存与垃圾回收(六) -- 垃圾回收(二) -- 垃圾回收算法