垃圾回收器与内存分配机制

GC(Garbage Collection)需要完成的三件事：

• 哪些内存需要回收？
• 什么时候回收？
• 如何回收？

编译期可知的回收

程序计数器、虚拟机栈和本地方法栈3个区域随线程而生，随线程而灭，栈中的栈帧（方法执行的基础数据结构，第八章内容）随着方法的进入和推出而进行着出栈和进栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来就已知的，因此这几个区域的内存分配和回收都具有确定性，在方法结束或线程结束时，内存就跟随着回收了。而Java堆和方法区则不一样，一个接口的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，只有在程序处于运行期间才知道创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器关注的就是这部分内存。

对象是否已死？

引用计数算法

给对象添加一个引用计数器，每当有一个地方引用它时，计数器值就加一；引用失效时，计数器值就减一；任何时刻计数器为0的对象就是不可能再被使用的。其实现简单，判定效率高，但是，主流的Java虚拟机里面并没有选用计数算法(Reference Counting)来管理内存，主要的原因是它很难解决对象之间相互循环引用的问题。

可达性分析

在主流的商用程序语言(Java、C#)的主流实现中，都通过可达性分析(Reachability Analysis)来判定对象是否存活。

其基本思想：通过一系列称为”GC Roots”的对象作为起始点，从这些节点向下搜索，搜索所走过的路径称为引用链(Reference Chain)，当一个对象到GC Roots没有任何引用链相连（不可达）时，证明此对象是不可用的。

在Java中，可作为GC Roots的对象包括：

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

生存还是死亡

在可达性算法不可达时，对象并不一定已经死亡了，这时候暂时处于“缓刑”状态，要宣告一个对象死亡，最少要经历两次标记。如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，会进行第一次标记并且进行筛选，看其是否有必要执行finalize()方法，如果没有必要执行（对象没有覆盖finalize()方法或finalize()方法已经被虚拟机调用过），否则将对象移至F-Queue队列中，如果在finalize()方法中拯救了自己——只要重新与引用链上的任何一个对象建立连接即可。否则进行第二次标记，等待回收。

方法区（永久代）的回收

Java虚拟机规范中说过可以不要求在方法区实现垃圾收集，而且其“性价比”比较低，在Java堆中，尤其是新生代中，常规应用进行一次垃圾收集一般可以回收70-95%的空间，而永久代的垃圾收集效率远低于此。

永久代垃圾收集主要回收两部分内容：废弃常量和无用的类。

收集废弃常量的过程与Java堆中的对象类似，假如没有任何对象引用常量池中的常量，这时发生内存回收，常量池中的其他类（接口）、方法、字段的符号引用也与此类似。

判断一个类是否无用则苛刻许多，需要同时满足以下三个条件：

• 该类所有的实例已经被回收，也就是说Java堆中不存在该类的任何实例。
• 加载该类的ClassLoder(第七章内容)已经被回收。
• 该类对应的java.lang.Class对象没有任何地方被引用，无法在任何地方通过反射访问该类的方法。