哪些对象可以被回收 彻底失去引用的对象 GC roots 可达性分析算法 可以判断 没有引用链的就可以被回收。这算第一次标记。第二次标记成功后会被回收。
马龙ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为成都创新互联的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：18982081108（备注：SSL证书合作）期待与您的合作！
对象在内存中的状态：
可达状态：
可恢复状态：
不可达状态：
判断对象是否存活都与引用有关，下面介绍一下引用的分类：
引用分类：
强引用；Object obj = new Object()
软引用；notmust
弱引用；
虚引用；
数组、对象
类似：Object obj = new Object()
只要存在强引用，垃圾收集器永远不会回收掉被引用的对象
描述一些还有用但并非必须的对象。在系统将要发生内存溢出异常之前，将会把这些对象列入回收范围之中进行第二次回收。如果这次回收之后还没有足够的内存——抛出内存异常
内存充足，不会回收
内存不足，回收
非必需对象
垃圾回收机制运行时，不管内存充足与否，都会回收
不能单独存在，必须和引用队列联合使用。
无法通过虚引用来去的一个对象实例。
对象存活判定算法：
引用计数算法：
思路：
给对象添加一个引用计数器，每当一个地方引用它时，计数器加1；
当引用失效时，计数器值就减1；
任何时刻计数器为0的对象就是不能再被使用的。
缺点：
很难解决对象之间相互循环引用的问题。导致他们的引用计数都不为0，于是引用计数算法无法通知GC收集器回收他们。
思路：
通过一系列的成为“GC Roots”的对象作为起始点，
从这些节点开始向下搜索，搜索所走过的路径成为引用链（Reference Chain），
当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的。
应用：
现在主流的商用程序语言（java，C#）都是通过可达性分析来判断对象是否存活的。
Java中，可作为GC Roots的对象包括：
虚拟机栈（栈帧中的本地变量表）中引用的对象；
方法区中类静态属性引用的对象；
方法区中常量引用的对象；
本地方法栈中JNI（即Native方法）引用的对象；
对象死亡（被回收）前的最后一次挣扎
即使在可达性分析算法中不可达的对象，也并非是“非死不可”，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程。
第一次标记：如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记；
第二次标记：第一次标记后接着会进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。在finalize()方法中没有重新与引用链建立关联关系的，将被进行第二次标记。
第二次标记成功的对象将真的会被回收，如果对象在finalize()方法中重新与引用链建立了关联关系，那么将会逃离本次回收，继续存活。
收集器
浅谈CMS垃圾收集器与G1收集器
Java之美[从菜鸟到高手演变]之JVM内存管理及垃圾回收
jdk8:垃圾回收算法
1. 引用计数器算法
解释
系统给每个对象添加一个引用计数器,每当有一个地方引用这个对象的时候,计数器就加1,当引用失效的时候,计数器就减1,在任何一个时刻计数器为0的对象就是不可能被使用的对象,因为没有任何地方持有这个引用,这时这个对象就被视为内存垃圾,等待被虚拟机回收
优点
客观的说,引用计数器算法,他的实现很简单,判定的效率很高,在大部分情况下这都是相当不错的算法
其实,很多案例中都使用了这种算法,比如 IOS 的Object-C , 微软的COM技术(用于给window开发驱动,.net里面的技术几乎都是建立在COM上的),Python语言等.
缺陷
无法解决循环引用的问题.
这就好像是悬崖边的人采集草药的人, 想要活下去就必须要有一根绳子绑在悬崖上. 如果有两个人, 甲的手拉着悬崖, 乙的手拉着甲, 那么这两个人都能活, 但是, 如果甲的手拉着乙, 乙的手也拉着甲, 虽然这两个人都认为自己被别人拉着, 但是一样会掉下悬崖.
比如说 A对象的一个属性引用B,B对象的一个属性同时引用A A.b = B() B.a = A(); 这个A,B对象的计数器都是1,可是,如果没有其他任何地方引用A,B对象的时候,A,B对象其实在系统中是无法发挥任何作用的,既然无法发挥作用,那就应该被视作内存垃圾予以清理掉,可是因为此时A,B的计数器的值都是1,虚拟机就无法回收A,B对象,这样就会造成内存浪费,这在计算机系统中是不可容忍的.
解决办法
在语言层面处理, 例如Object-C 就使用强弱引用类型来解决问题.强引用计数器加1 ,弱引用不增加
Java中也有强弱引用
2. 可达性分析算法
解释
这种算法通过一系列成为 "GC Roots " 的对象作为起始点,从这些节点开始向下搜索所有走过的路径成为引用链(Reference Chain) , 当一个对象GC Roots没有任何引用链相连(用图论的话来说就是从GC Roots到这个对象不可达),则证明此对象是不可用的
优点
这个算法可以轻松的解决循环引用的问题
大部分的主流java虚拟机使用的都是这种算法
3. Java语言中的GC Roots
在虚拟机栈(其实是栈帧中的本地变量表)中引用的对象
在方法区中的类静态属性引用对象
在方法区中的常量引用的对象
在本地方法栈中JNI(即一般说的Native方法)的引用对象
相对于引用计数算法而言，可达性分析算法不仅同样具备实现简单和执行高效等特点，更重要的是该算法可以有效解决引用计数算法中循环引用的问题，防止内存泄漏的发生
java选择的就是可达性分析算法，这种类型的垃圾收集通常也叫做追踪性垃圾收集
所谓GC ROOTS 根集合就是一组必须活跃的引用
基本思路:
1.可达性分析算法是以根对象集合(GC Roots)为起始点，按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达
2.使用可达性分析算法后，内存中的存活对象都会被根对象集合直接或间接连接着，搜索所走过的路径称为引用链
3.如果目标对象没有任何引用链项链，则是不可达的，就意味着该对象已经死亡，可以标记为垃圾对象
4.在可达性分析算法中，只有能够被根对象集合直接或者间接连接的对象才是存活对象
j当面试扯到jvm这一部分的时候，面试官大概率会问你 jvm怎么判断哪些对象应该回收呢 ?
你会脱口而出 引用计数算法 和 可达性分析算法 。
引用计数法： 在对象中添加一个引用计数器，每当一个地方引用它时，计数器就加一；当引用失效时，计数器值就减一；任何时刻计数器为零的对象就是不可能再被使用的。
但是这样的算法有一个问题？
就是不能解决循环依赖的问题。
可达性分析算法的思路 就是通过一系列的“GC Roots”，也就是根对象作为起始节点，从根节点开始，根据引用关系向下搜索，搜索过程所走过的路径称为引用链，如果某个对象到GC Roots间没有任何引用链相连。就是说从GC Roots到这个对象不可达时，则证明此对象是不可能再被使用的，是可以被回收的对象。
接下来面试官可能会问：
你刚刚谈到了根节点，那你知道哪些对象可以作为根对象吗？
你刚刚谈到了引用，那你知道java里面有哪几种引用吗？
你刚刚谈到了可达性分析算法，那如果在该算法中被判定不可达对象，是不是一定会被回收呢？
（这这些问题，文末会给出解答）
这些问题太常规了，本文要讲一些不那么常见的： 并发标记 ， 浮动垃圾 。
CMS和G1都有一个并发标记的过程，并发标记要解决什么问题？带来了什么问题？怎么解决这些问题呢？
刚刚我们谈到的可达性分析算法是需要一个理论上的前提的: 该算法的全过程都需要基于一个能保障一致性的快照才能够分析，这意味着必须全程冻结用户线程的运行。 而为了不冻结用户线程的运行，那我们就需要让垃圾回收线程和用户线程同时运行。
那我们先假设不并发标记，即只有垃圾回收线程在运行的流程是怎样的：
第一步：找到根节点，也就是我们常说的 根节点枚举 。
在这个过程中，由于GC Roots是远远小与整个java堆中的全部对象，而且在OopMap此类优化技巧的加持下，它带来的停顿是非常短暂且固定的， 可以理解为不会随着堆里的对象的增加而增加 ，如图：
首先我们要搞清楚一个问题： 为什么遍历对象图的时候必须在一个能保证一致性的快照中？
为了说明这个问题，我们引入 “三色标记” 方法。
什么是“三色标记”？
在遍历对象图的过程中，把访问的对象按照"是否访问过"这个条件标记成以下三种颜色：
白色：表示对象未被垃圾回收器访问过 。
显然可达性分析刚开始的时候，所有的对象都是白色，若在结束的时候，仍是白色的对象，即代表不可达。
黑色：表示已经被垃圾回收器访问过，且这个对象的所有引用都已经扫描过
黑色的对象代表已经扫描过，它是安全存活的，如果有其它的对象引用指向了黑色对象，无须重新扫描一遍。黑色对象不可能直接（不经过灰色对象）指向某个白色对象。
灰色：表示已经被垃圾回收器扫描过，但这个对象至少存在一个引用还没有被扫描 。
如下图所示：
我们先看一下正常标记的过程：
首先是初始状态，很简单，只有GC Roots是黑色的。同时需要注意下面的图片的箭头方向，代表的是有向的，比如其中的一条引用链是：
跟节点-5-6-7-8-11-10
如果在标记的过程中，用户线程修改了引用关系，就会出现下面的情况：
有一个大佬叫Wilson，他在1994年在理论上证明了， 只有同时满足以下两个条件时 ，会产生“对象消失”的问题，原来应该是黑色的对象被标记成了白色。
增量更新要破坏的是第一个条件（赋值器插入了一条或者多条从黑色对象到白色对象的新引用），当黑色对象插入新的指向白色对象的引用关系时，就将这个新插入的引用 记录下来 ，等并发扫描结束之后，再以这些记录过的引用关系中的黑色对象为根， 重新扫描一次 。
可以简化的理解为： 黑色对象一旦插入了指向白色对象的引用之后，它就变回了灰色对象 。
下面的图就是一次并发扫描结束之后，记录了黑色对象5新指向了白色对象9：
原始快照要破坏的是第二个条件（赋值器删除了全部从灰色对象到该白色对象的直接或间接引用），当灰色对象要删除指向白色对象的引用关系时，就将这个要删除的引用记录下来，在并发扫描结束之后，再以这些记录过的引用关系中的灰色对象为根，重新扫描一次。
可以简化理解为：无论引用关系删除与否，都会按照刚刚开始扫描那一刻的对象图快照开进行搜索。
接下来回答一下，上面遗留的几个问题：
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对象的包括如下几种：
你知道java里面有哪几种引用吗？
在可达性分析算法判定为不可达的对象，是不是一定会被回收呢？
即使在可达性算法中不可达的对象也不一定是非死不可的，这时候它们暂时处于“缓刑”阶段，要真正宣告它的死亡还需要经历两次的标记阶段。
第一次标记
在对象可达性算法不可达时，进行第一次标记，并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize方法或者该方法被虚拟机调用过，虚拟机将这两种情况视为“没有必要去执行”，回收。
如果该对象被判定为有必要执行finalize()方法，那么这个对象会被放置到一个叫做F-Queue的队列中，并在稍后由一个虚拟机自动建立的、低优先级的Finalize线程去执行它。这里所谓的执行就是去触发该方法，但是并不会承诺等待它执行结束，这样做的原因是，如果对象在finalize()方法中执行缓慢，或者发生死循环，将会导致整个队列中的对象处于等待之中。
第二次标记
finalize()方法是对象逃脱死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象要在finalize()中拯救自己——只要重新与引用链上的一个对象重新建立关联即可，比如将自己（this关键字）赋值给某个类变量或者成员变量，那么在第二次标记的时候就会被移除“即将回收”的集合；如果对象这时候还没有逃脱，那么就会被真的回收了。
注意：第二次自救失败是因为任何一个对象的finalize()方法只能执行一次，如果第二次回收，就不会执行finalize方法了！
(未完待续)
GC Root在对象图之外，是特别定义的“起点”，不可能被对象图内的对象所引用。
一个常见的误解是以为GC Root是一组对象。
实际情况是GC Root通常是一组特别管理的指针，这些指针是tracing GC的trace的起点。它们不是对象图里的对象，对象也不可能引用到这些“外部”的指针，所以题主想像的情况无法成立。
另外，tracing GC能正确处理循环引用，保证每个活对象只会被访问一次就能确定其存活性。对象图里是否存在循环引用，tracing GC都能正确判断对象的存活与否。
重庆分公司
重庆分公司
