深入理解 JVM -- 垃圾收集器与内存分配策略

程序计数器、虚拟机栈、本地方法栈 3个区域随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的（尽管在运行期会由JIT编译器进行一些优化，但在本章基于概念模型的讨论中，大体上可以认为是编译期可知的），因此这几个区域的内存分配和回收都具备确定性，在这几个区域内就不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。

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

如何判定对象已死

1、引用计数法

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

实现简单，判定效率也很高，在大部分情况下它都是一个不错的算法，也有一些比较著名的应用案例，例如

微软公司的COM（Component Object Model）技术、使用ActionScript 3的FlashPlayer、Python语言和在游戏脚本领域被广泛应用的Squirrel中都使用了引用计数算法进行内存管理。

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

举例：赋值令objA.instance=objB及objB.instance=objA，除此之外，这两个对象再无任何引用，实际上这两个对象已经不可能再被访问，但是它们因为互相引用着对方，导致它们的引用计数都不为0，于是引用计数算法无法通知GC收集器回收它们。

/**

*testGC（）方法执行后，objA和objB会不会被GC呢？

*@author zzm

*/

public class ReferenceCountingGC{

public Object instance=null；

private static final int_1MB=1024*1024；

/**

*这个成员属性的唯一意义就是占点内存，以便能在GC日志中看清楚是否被回收过

*/

private byte[]bigSize=new byte[2*_1MB]；

public static void testGC（）{

ReferenceCountingGC objA=new ReferenceCountingGC（）；

ReferenceCountingGC objB=new ReferenceCountingGC（）；

objA.instance=objB；

objB.instance=objA；

objA=null；

objB=null；

//假设在这行发生GC,objA和objB是否能被回收？
System.gc（）；

}

}

从运行结果中可以清楚看到，GC日志中包含“4603K-＞210K”（缩小了，被回收了），意味着虚拟机并没有因为这两个对象互相引用就不回收它们，这也从侧面说明虚拟机并不是通过引用计数算法来判断对象是否存活的。

2、可达性分析

111

111