j当面试扯到jvm这一部分的时候，面试官大概率会问你jvm怎么判断哪些对象应该回收呢?
你会脱口而出引用计数算法和可达性分析算法。
引用计数法：在对象中添加一个引用计数器，每当一个地方引用它时，计数器就加一；当引用失效时，计数器值就减一；任何时刻计数器为零的对象就是不可能再被使用的。
但是这样的算法有一个问题？
就是不能解决循环依赖的问题。
Object 1和Object 2其实都可以被回收，但是它们之间还有相互引用，所以它们各自的计数器为1，则还是不会被回收。
所以，Java虚拟机没有采用引用计数法。它采用的是可达性分析算法。
可达性分析算法的思路就是通过一系列的“GC Roots”，也就是根对象作为起始节点，从根节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为引用链，如果某个对象到GC Roots间没有任何引用链相连。就是说从GC Roots到这个对象不可达时，则证明此对象是不可能再被使用的，是可以被回收的对象。
如图所示，黄色的就为依然存活的对象，白色的则是判断可以被回收的对象。
接下来面试官可能会问：
你刚刚谈到了根节点，那你知道哪些对象可以作为根对象吗？
你刚刚谈到了引用，那你知道java里面有哪几种引用吗？
你刚刚谈到了可达性分析算法，那如果在该算法中被判定不可达对象，是不是一定会被回收呢？
（这这些问题，文末会给出解答）
这些问题太常规了，本文要讲一些不那么常见的：并发标记，浮动垃圾。
CMS和G1都有一个并发标记的过程，并发标记要解决什么问题？带来了什么问题？怎么解决这些问题呢？
并发标记要解决什么问题
刚刚我们谈到的可达性分析算法是需要一个理论上的前提的:该算法的全过程都需要基于一个能保障一致性的快照才能够分析，这意味着必须全程冻结用户线程的运行。而为了不冻结用户线程的运行，那我们就需要让垃圾回收线程和用户线程同时运行。
那我们先假设不并发标记，即只有垃圾回收线程在运行的流程是怎样的：
第一步：找到根节点，也就是我们常说的根节点枚举。
在这个过程中，由于GC Roots是远远小与整个java堆中的全部对象，而且在OopMap此类优化技巧的加持下，它带来的停顿是非常短暂且固定的，可以理解为不会随着堆里的对象的增加而增加，如图：
接下来，我们需要从GC Roots往下继续遍历对象图，进行"标记"过程，这一步的停顿时间会随着java堆中的对象的增加而增加，如图：
这个逻辑不复杂：堆约大，存储的对象越多，对象图结构越复杂，要标记更多对象，所以产生的停顿时间也自然就长了。
“标记”阶段是所有使用可达性算法的垃圾回收期都有的阶段，所以如果能够削减“标记”过程这部分的停顿时间，那么收益将非常可观。
所以并发标记就是为了削减这一部分的停顿时间，让垃圾回收器和用户线程同时运行，并发工作，也就是并发标记的阶段。
并发标记带来了什么问题？
首先我们要搞清楚一个问题：为什么遍历对象图的时候必须在一个能保证一致性的快照中？
为了说明这个问题，我们引入“三色标记”方法。
什么是“三色标记”？
在遍历对象图的过程中，把访问的对象按照"是否访问过"这个条件标记成以下三种颜色：
白色：表示对象未被垃圾回收器访问过。
显然可达性分析刚开始的时候，所有的对象都是白色，若在结束的时候，仍是白色的对象，即代表不可达。
黑色：表示已经被垃圾回收器访问过，且这个对象的所有引用都已经扫描过
黑色的对象代表已经扫描过，它是安全存活的，如果有其它的对象引用指向了黑色对象，无须重新扫描一遍。黑色对象不可能直接（不经过灰色对象）指向某个白色对象。
灰色：表示已经被垃圾回收器扫描过，但这个对象至少存在一个引用还没有被扫描。
如下图所示：
可以看到，灰色对象是黑色对象与白色对象之间的中间态。当标记过程结束后，只会有黑色和白色的对象，而白色的对象就是需要被回收的对象。
在可达性分析的扫描过程中，如果只有垃圾回收线程在工作，那肯定不会有任何问题。但是垃圾回收器和用户线程同时运行呢？
垃圾回收器在对象图上面标记颜色，而同时用户线程在修改引用关系，引用关系修改了，那么对象图就变化了，这样就有可能出现两种后果：
- 一种是把原本消亡的对象错误的标记为存活，这不是好事，但是其实是可以容忍的，只不过产生了一点逃过本次回收的浮动垃圾而已，下次清理就可以。
- 一种是把原本存活的对象错误的标记为已消亡，这就是非常严重的后果了，一个程序还需要使用的对象被回收了，那程序肯定会因此发生错误。
当面试官问你：为什么会产生浮动垃圾的时候，你就可以用上面的话来回答。
但是大概率情况下面试官应该更加关心第二种情况。
他可能会问：你刚刚说的第二种情况，"把原本存活的对象错误的标记为已消亡"能具体的说明一下吗？怎么消亡的？垃圾回收器是怎么解决这个问题的？
下面就详细讨论一下“对象”是怎么消失的？
正常标记
我们先看一下正常标记的过程：
首先是初始状态，很简单，只有GC Roots是黑色的。同时需要注意下面的图片的箭头方向，代表的是有向的，比如其中的一条引用链是：
跟节点->5->6->7->8->11->10
扫描结束后，如图所示：
当然中间会有一些灰色状态，就不一一展示了。
此时，黑色对象是存活的对象，白色对象是消亡的，可以回收的对象。
对象消失的情况
如果在标记的过程中，用户线程修改了引用关系，就会出现下面的情况：
这时，我们和之前分析的正常扫描结束的对象图对比，就能清楚的看到，扫描完成后，被对象5引用的对象9，由于是白色对象，所以根据三色标记原则，对象9会被当成垃圾回收。这样就出现了对象消失的情况。
所以回到最开始：并发标记带来什么问题？
经过上面的分析，和扫描完成后的最终对象图分析对比可知，并发标记会产生浮动垃圾，还会出现“对象消失”的问题。
怎么解决“对象消失”问题？
有一个大佬叫Wilson，他在1994年在理论上证明了，只有同时满足以下两个条件时，会产生“对象消失”的问题，原来应该是黑色的对象被标记成了白色。
- 条件一：赋值器插入了一条或者多条从黑色对象到白色对象的新引用。
- 条件二：赋值器删除了全部从灰色对象到该白色对象的直接或间接引用。
两个条件之间是当且仅当的关系，所以我们要解决并发标记时对象消失的问题，只需要破坏两个条件中的任意一个就行。
于是产生了两种解决方案：增量更新（Incremental Update）和原始快照（Snapshot At The Beginning，SATB）。
在HotSpot虚拟机中，CMS是基于增量更新来做并发标记的，G1则采用的是原始快照的方式。
什么是增量更新？
增量更新要破坏的是第一个条件（赋值器插入了一条或者多条从黑色对象到白色对象的新引用），当黑色对象插入新的指向白色对象的引用关系时，就将这个新插入的引用记录下来，等并发扫描结束之后，再以这些记录过的引用关系中的黑色对象为根，重新扫描一次。
可以简化的理解为：黑色对象一旦插入了指向白色对象的引用之后，它就变回了灰色对象。
下面的图就是一次并发扫描结束之后，记录了黑色对象5新指向了白色对象9：
这样对象9又被扫描成为了黑色。也就不会被回收，所以不会出现对象消失的情况。
什么是原始快照？
原始快照要破坏的是第二个条件（赋值器删除了全部从灰色对象到该白色对象的直接或间接引用），当灰色对象要删除指向白色对象的引用关系时，就将这个要删除的引用记录下来，在并发扫描结束之后，再以这些记录过的引用关系中的灰色对象为根，重新扫描一次。
可以简化理解为：无论引用关系删除与否，都会按照刚刚开始扫描那一刻的对象图快照开进行搜索。
需要注意的是，上面的介绍中无论是对引用关系记录的插入还是删除，虚拟机的记录操作都是通过写屏障实现的。
1、这里的写屏障和我们通常所说的为了解决并发乱序问题的“内存屏障”不是一码事。
2、写屏障可以看作虚拟机层面对"引用类型字段赋值"这个动作的AOP切面，在引用对象赋值时会产生一个环形通知，供程序执行额外的动作，也就是说赋值的前后都在写屏障的覆盖范畴内。在赋值前的部分的写屏障叫做写前屏障(Pre-Write Barrier)，在赋值后的则叫作写后屏障(Post-Write Barrier)。
**增量更新用的是写后屏障(Post-Write Barrier)，记录了所有新增的引用关系。
原始快照用的是写前屏障(Pre-Write Barrier)，将所有即将被删除的引用关系的旧引用记录下来。
**
(转自why技术)
接下来回答一下，上面遗留的几个问题：
你知道哪些对象可以作为根对象？
GC管理的主要区域是Java堆，一般情况下只针对堆进行垃圾回收。方法区、栈和本地方法区不被GC所管理，因而选择这些区域内的对象作为GC Roots，被GC Roots引用的对象不被GC回收。
Class - 由系统类加载器(system class loader)加载的对象，这些类是不能够被回收的，他们可以以静态字段的方式保存持有其它对象。
Thread - 活着的线程
Stack Local - Java方法的local变量或者参数
JNI Local、JNI Global
Monitor Used - 用于同步的监控对象
在Java语言里，可以作为GC Roots对象的包括如下几种：
- 虚拟机栈（栈帧中的本地变量表）中引用的对象：对象会在堆上开辟一块空间，同时会将这块空间的地址作为引用保存到虚拟机栈中，如果对象生命周期结束了，那么引用就会从虚拟机栈中出栈，因此如果在虚拟机栈中还存在引用，就说明这个对象还是有用的，这种情况是最常见的。
- 方法区中的类静态属性引用的对象：类中定义了全局的静态的对象，也就是使用了static关键字，由于虚拟机栈是线程私有的，所以这种对象的引用会保存在共有的方法区中，显然将方法区中的静态引用作为GC Roots是必须的。
- 方法区中的常量引用的对象，就是使用了static final关键字。由于这种引用初始化之后不会修改，所以方法区常量池里的引用的对象也应该作为GC Roots。
- 本地方法栈中JNI（一般叫Native方法）引用的对象。
你知道java里面有哪几种引用吗？
强引用（StrongReference）：
强引用是使用最普遍的引用。如果一个对象具有强引用，那垃圾回收器绝不会回收它。当内存空间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足的问题。如：A a = new A（）软引用
如果一个对象只具有软引用，则内存空间足够，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。
软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收器回收，Java虚拟机就会把这个软引用加入到与之关联的引用队列中。弱引用
弱引用与软引用的区别在于：弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。
弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中。虚引用
“虚引用”顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列 （ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之关联的引用队列中。
在可达性分析算法判定为不可达的对象，是不是一定会被回收呢？
即使在可达性算法中不可达的对象也不一定是非死不可的，这时候它们暂时处于“缓刑”阶段，要真正宣告它的死亡还需要经历两次的标记阶段。
第一次标记
在对象可达性算法不可达时，进行第一次标记，并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize方法或者该方法被虚拟机调用过，虚拟机将这两种情况视为“没有必要去执行”，回收。
如果该对象被判定为有必要执行finalize()方法，那么这个对象会被放置到一个叫做F-Queue的队列中，并在稍后由一个虚拟机自动建立的、低优先级的Finalize线程去执行它。这里所谓的执行就是去触发该方法，但是并不会承诺等待它执行结束，这样做的原因是，如果对象在finalize()方法中执行缓慢，或者发生死循环，将会导致整个队列中的对象处于等待之中。
第二次标记
finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中拯救自己——只要重新与引用链上的一个对象重新建立关联即可，比如将自己（this关键字）赋值给某个类变量或者成员变量，那么在第二次标记的时候就会被移除“即将回收”的集合；如果对象这时候还没有逃脱，那么就会被真的回收了。
public class FinalizeEscapeGC {
public static FinalizeEscapeGC SAVE_HOOK = null;
public void isAlive(){
System.out.println("yes, i am still alive!");
}
@Override
public void finalize() throws Throwable {
super.finalize();
System.out.println("finalize method executed!");
FinalizeEscapeGC.SAVE_HOOK = this;
}
public static void main(String[] args) throws InterruptedException {
SAVE_HOOK = new FinalizeEscapeGC();
//对象第一次拯救自己
SAVE_HOOK = null;
System.gc();
//因为finalize方法优先级很低所以暂停0.5秒等待
Thread.sleep(500);
if(SAVE_HOOK != null){
SAVE_HOOK.isAlive();
}else{
System.out.println("no, i am dead!");
}
//对象第二次拯救自己，但是自救失败了
SAVE_HOOK = null;
System.gc();
//因为finalize方法优先级很低所以暂停0.5秒等待
Thread.sleep(500);
if(SAVE_HOOK != null){
SAVE_HOOK.isAlive();
}else{
System.out.println("no, i am dead!");
}
}
}
注意：第二次自救失败是因为任何一个对象的finalize()方法只能执行一次，如果第二次回收，就不会执行finalize方法了！
(未完待续)