jvm虚拟机系列之（一）：jvm如何判断哪些对象可以回收的？

Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的“高墙”，墙外的人想进去，墙里边的人想出来。

---

为什么要去了解GC和内存分配呢？

• 需要排查内存溢出、内存泄露问题时，当垃圾收集称为系统达到更高并发量的瓶颈时，我们需要对jvm实施必要的监控和调节。

---

垃圾回收哪些区域不需要关注，哪些区域需要关注？

• 程序计数器、虚拟机栈、本地方法栈3个区域随线程而生，随线程而死，栈中的栈帧，随着方法的进入和退出进行出栈和入栈操作。几个区域的内存分配和回收都具备确定性，不需要过多考虑回收的问题；
• 但Java堆和方法区不一样，一个接口的实现类，一个方法中的多个分支需要的内存可能不一样，只有在程序运行时才知道创建哪些对象，垃圾回收器关注的正是这一部分内存；

---

引用计数法

• 一些语言是使用这样的算法判断对象是否存活的：给对象添加一个引用计数器，每当引用时，加1，引用失效时，减1，为0的对象就是不再使用的。
  比如当前非常火热的人工智能使用的Python语言,没人要的ios使用的Objective-C等都是使用的引用计数法.
• 主流jVM虚拟机都没使用引用计数算法。最重要原因是：很难解决对象之间的相互循环引用问题。
  举个栗子：objA和objB都有字段instance，objA.instance=objB;objB.instance=objA;然后再无任何引用，实际上两个对象不再访问了，但互相引用着，计数器不为0，无法释放。

---

可达性分析算法

• java、C#等都是通过可达性分析来判断对象是否存活的；
• 基本思想：通过一些列“GC Roots”的对象作为起始点，从这些节点往下搜索，搜索走过的路径称为引用链，当一个对象到GC Roots没有任何引用链时，则证明此对象不可用；

可作为GC Roots的对象，共4类：

• 虚拟机栈（栈帧中的本地变量表）中应用的对象；
• 方法区中类静态属性引用的对象；
• 方法区中常量引用的对象；
• 本地方法栈中JNI（即Native方法）引用的对象；

---

生存还是死亡

在可达性分析算法中不可达的对象，也不是非死不可的，宣告一个对象死亡，至少经历两次标记过程:对象进行可达性分析发现没有与GC Roots相连接的引用链，讲过进行一次标记，并进行筛选，筛选的条件是此对象需不需要执行ifinalize()方法，当没有覆盖finalize()方法或已经被虚拟机执行过，视为“没有必要执行”；
有必要执行finalize()方法则放在F-Queue队列中，稍后由一个虚拟机建立、低优先级的线程执行，不一定会等到方法执行结束，finalize()是对象存活的最后机会，稍后GC将F-Queue中的对象进行第二次标记，如果对象想在finalize()方法中拯救自己，把自己赋值给某个类变量或对象的成员变量，第二次标记时，就会被移除“即将回收”的集合；如果对象这个时候没有逃脱，基本上就被回收了。

• 任何对象的finalize()方法只会执行一次。大家避免使用此方法，使用try-finally或其他方式可以做的更好；

---

回收方法

在方法区进行垃圾回收一般“性价比”比较低，在堆中，尤其新生代，一次能回收70%-95%的空间，永久代的垃圾收集效率远低于此。
永久代主要收集两类内容：废弃常量和无用的类

1. 回收废弃常量与回收对象类似，以常量池中字面量为例，如果没有其他地方引用这个字面量，若此时发生回收，这个常量就会被清理出常量池，常量池中其他类（接口）、方法、字段的符号引用与此类似。
2. 判断一个类是“无用的类”则苛刻的多，需满足下面3个条件

• 该类所有实例都被回收；
• 加载该类的ClassLoader已经被回收；
• 该类对应的java.lang.Class 对象没有在任何地方被引用，无法通过反射访问该类的方法。

虚拟机可以对满足上述3个条件的无用类进行回收，但不一定。是否对类进行回收，
虚拟机提供了 -Xnoclassgc 进行控制，号可以使用 -verbose:class以及-XX:+TraceClassLoading、-XX:+TraceClassUnLoading查看类加载和卸载信息；

• -verbose:class以及-XX:+TraceClassLoading需要在Product版的虚拟机；
• -XX:+TraceClassUnLoading需要在FastDebug版的虚拟机支持；

• 大量使用反射、动态代理、CGLib等ByteCode框架、动态生成JSP以及OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。