【JVM】对象已死吗？

jvm运行时数据区

在jvm运行时数据区，分为两部分。
一个部分是线程共享区，主要包括堆和方法区。
另一部是线程私有区分包括本地方法栈，虚拟机栈和程序计数器。
在线程私有部分的三个区域是随着线程生和灭的。栈中的栈帧随着方法的进入和退出而执行着出栈和入栈操作。每一个栈帧所用内存大小在类结构确定下来时就已知了。因此这线程私有区的内存分配和回收都具备确定性，简单概括的说：这部分内存在类加载时分配，在线程结束时回收。

而线程共享区（堆和方法区）则不一样，一个方法中的多个分支需要的内存可能不一样，只有在程序处于运行期间时才能知道会创建哪些对象，这部分的内存的分配和回收都是动态的，垃圾收集器（GC）所关注的也是这部分内存，今天要介绍的内容也是围绕着这部分内存来说的。

对象已死吗？

Java世界中几乎所有的对象实例都存放在堆里，垃圾回收器在对堆内存进行回收前，要先确定这些对象中哪些还存活，哪些已死去（死去：不可能再被任何途径使用的对象）；

那么如何判断堆内存中的对象是活着还是已经死去了呢？

下面介绍一下主流的两种判断对象是否已经死去算法。

引用计数算法

引用计数算法的思想是：给对象添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减一；任何时刻计数器为0的对象就是不可能再被使用的。

这种算法的特点是实现简单，判定效率也很高，但是Java虚拟机中却没有使用这种算法，主要原因是这种算法很难解决对象之间相互循环引用的问题。

可达性分析算法

这个算法的基本思路是通过一组称为“GC Roots”的活跃引用作为起始点，从这些活跃的引用开始向下搜索，搜索走过的路径称为引用链（Reference Chain）,当一个对象到GC Roots没有任何引用链相连时，则证明此对象是不可用的，可以被回收了难解决对象之间相互循环引用的问题。

上图中object5、object6、object7、虽然互相有关联，但是它们到GC roots是不可达的所以他们会被判定为可回收的对象。

哪些对象可以做为GCRoot?

在Java语言中，可作为GC Roots的对象包括下面几种：

1、虚拟机栈（栈帧中的本地变量表）中引用的对象。
2、方法区中类静态属性引用的对象。
3、方法区中常量引用的对象。
4、本地方法栈JNI（即一般说的Native方法）引用的对象

针对上面4种情况，说下对应的理解：
1.先说一个常识：当new 一个对象时，对象的引用存储在栈里，对象存储在堆里。但JVM有个优化–逃逸分析，java中的逃逸分析：

方法逃逸：在一个方法中创建一个对象，如果该对象可以被其他方法或者方法外的地方引用到，则该方法就发生了逃逸；相反，则说该对象未发生方法逃逸。

线程逃逸：线程逃逸相似，一个线程创建的对象可以被另一个线程所引用，则说该对象发生了线程逃逸。

如果一个对象在方法中未发生逃逸，对象和对象的引用都会存储在栈里面。因为栈相对于堆，存取速度快，线程结束内存立即释放，且一个程序中存在最多的还是用完即丢掉的对象，所以JVM做了一个逃逸分析的优化。

对于这种不发生逃逸的局部变量的引用不作为GC root。

当局部变量发生方法逃逸时，如果它的引用被其他对象或方法引用到，并且这些引用链能够形成可达性链的一部分，那么它的引用有可能成为GC root。换句话说，只有当逃逸的局部变量的引用能够通过其他对象或方法访问到，形成可达性链时，它的引用才能成为GC root。

而如果逃逸的局部变量引用没有被其他对象或方法引用到，它就不会成为GC root，因为它不会对其他对象的可达性产生影响。在这种情况下，这个局部变量的引用将会随着方法的执行完毕被销毁，它所引用的对象可能成为垃圾，最终会被垃圾回收器回收。

再谈引用

JDK1.2之后，Java对引用的概念进行了扩充，将引用分为强引用（Strong Reference）、软引用(Soft Reference)、弱引用(Weak Reference)、虚引用(Phantom Reference)，引用强度依次减弱。

1、强引用：在程序中普遍存在，类似“Object object = new Object()”；只有强引用存在，对象就不会被回收；
2、软引用：有用，但不是必需的。在发生内存溢出异常之前，会把这些对象进行二次回收，如果回收了这部分还是内存不够，那就会发生内存溢出。（JDK1.2后引入）
3、弱引用：也是非必需引用，比软引用更弱一点，弱引用关联的对象只能活到下一次收集之前，只要收集器一工作，无论内存够不够，都会被回收。（JDK1.2后引入）
4、虚引用：也称为幽灵引用或者幻影引用，为一个对象设置弱引用的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。（JDK1.2后引入）

生存还是死亡

在JVM中，即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，它们还有一次自救的机会，这时候它们暂处于缓刑阶段，一个对象真正死亡，至少要经历两次标记过程；

第一次标记：如果在进行可达性分析以后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法以及被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。

如果有必要执行，这个对象会被放在一个F_Queue的队列中，并在稍后由一个虚拟机自动建立的、低优先级的Finalizer线程去执行finalize()方法，但不承诺会等它执行结束。

稍后进行第二次标记：如果这时候这个对象重新与引用链上的任何一个对象建立关联就会被移除“即将回收的”的集合，如果这个时候还没有逃脱那基本上就被回收了。

需要注意的是：任何一个对象的finalize()方法都只会被系统自动调用一次。

回收方法区

java虚拟机规范中不要求虚拟机在方法区实现垃圾收集，而且在方法区回收效率很低。

方法区注意回收两部分内容：废弃常量和无用的类

判定一个常量比较简单（一个常量任何地方都没有被引用了，就可以认为是废弃常量了），而判定一个类是否是无用类，就相对比较苛刻，需要满足以下三个条件，才能被认定为是一个无用的类。

该类所有的实例都已经被回收。
加载该类的ClassLoader已经被回收。
该类对应的java.lang.Class对象没有在任何地方被引用，无法再任何地方通过反射访问该类的方法。
在大量使用反射、动态代理、Cglib等ByteCode框架、动态生成JSP以及OSGi这类频繁自定义ClassLoader的场景，都是需要进行无用类回收的。