深入理解 Java 虚拟机之学习笔记(3)

垃圾回收（Garbage Collection,GC ），GC的历史其实比Java久远，1960年诞生与MIT的Lisp是第一门真正使用内存动态分配和垃圾收集技术的语言。当Lisp还在胚胎时期时，人们就在思考GC需要完成的3件事情：

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

　　问：经过半个多世纪的发展，目前内存的动态分配与内存回收技术已经相当成熟，一切看起来都进入了“自动化”时代，为何我们还要去了解GC和内存分配呢？

　　答：当需要排查各种内存溢出、内存泄露问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就需要对这些“自动化”的技术实施必要的监控和调节。

　　确定GC回收的区域：

　　（1）程序计数器、虚拟机栈、本地方法栈这3个区域随线程而生，随线程而灭。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的，因此这几个区域的内存分配和回收都具备确定性，在这几个区域内就不需要过多考虑回收的问题，因为方法结束或线程结束时，内存自然就跟着回收了。

　　（2）Java堆（Heap）和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器所关注的是这部分内存。

1.判断对象是否存活的算法之一：引用计数算法。

　　算法思想以及应用分析：

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

　　（2）客观地说，引用计数算法的实现简单，判定效率也很高，在大部分情况下都是一个不错的算法，也有一些著名的应用案例，例如微软公司的COM（Component Object Model）技术、使用ActionScript 3的Flashplayer、Python语言和在游戏脚本领域被广泛应用的Squirrel中都使用了引用计数算法进行内存管理。

　　（3）但是主流的Java虚拟机里面没有选用引用计数算法来管理内存，其中最主要的原因是它很难解决对象之间相互循环引用的问题。

2.针对对象之间相互循环引用的问题进行的实验如下图所示：

　　 从上面的运行结果可以得到，GC日志中包含的“8028K->512K”,意味着虚拟机并没有因为这两个对象互相引用就不回收它们，这也从侧面说明虚拟机并不是通过引用计数算法来判断对象是否存活的。

3.判断对象是否存活的算法之一： 可达性分析算法。

　　算法思想及应用：

　　（1）这个算法基本思想就是通过一系列的成为“GC Roots”的对象作为起始点，从这些节点开始向下搜素，搜素所做过的路径成为引用链(Reference Chain)。当一个对象到GC Roots没有任何引用链相连（图论中为从GC Root到这个对象不可达）时，则证明此对象是不可用的。如下图所示：

　　（2）在Java语言中，可作为GC Roots的对象包括下面：

　　　　a.虚拟机栈（栈帧中的本地变量表）中引用的对象。

　　　　b.方法区中类静态属性引用的对象。

　　　　c.方法区中常量引用的对象。

　　　　d.本地方法栈中JNI（Native 方法）引用的方法。

（3）在主流的商用程序语言（Java、C#，甚至包括前面提到的古老的Lisp）的主流实现中，都是称通过可达性分析（Reachability Analysis）来判定对象是否存活的。

4. 再谈引用

　 引用的定义：在JDK 1.2以前，Java中的引用定义很传统：如果reference类型的数据存储的数值代表的是另外一块内存的起始地址，就称这块内存代表着一个引用。

问题出现了：当描述这样的一类对象：当内存空间还足够时，则能保留在内存之中，如果内存空间在进行垃圾收集后还是非常紧张，则可以抛弃这些对象。此时的引用就显得过于狭隘。因此在JDK 1.2之后，Java堆引用的概念进行了扩充。