JVM内存模型及垃圾回收机制

本文分两部分：

1.JVM内存结构（看图理解，不多讲）

2.垃圾回收机制

关于JVM的内存模型，本人整理了一张图仅供参考，有什么问题欢迎指正：

 

关于内存结构模型中的各个部分的具体功能在此就先不讲了（后期加补），各位可以先结合别的文章进行理解学习。

下面说下JVM垃圾回收机制：

1.哪些内存需要回收？

答：根据上图可知，JAVA内存运行时区域的各个部分，其中虚拟机栈、本地方法栈、程序计数器3个区域随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出而有条不紊地执行着入栈和出栈的操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的（局部变量表存放了编译器可知的各种基本数据类型和对象引用），大体上可以认为是编译器可知的。因此这几个区域的内存分配和回收都具备确定性，在这几个区域内就不需要过多的考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟着回收了。而Java堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存可能也不一样，我们只有在程序运行期间时才知道会创建哪些对象，这部分内存的分配和回收都是动态的，因此垃圾收集器所关注的主要是这部分内存。

2.什么时候回收？

答：在堆里面存放着Java中的几乎所有对象实例，垃圾收集器在对堆进行回收前，首先要确定这些对象之中哪些还“存活”，哪些已经“死去”（即不可能再被任何途径使用的对象）。

判断对象存活的算法包括两个：

2.1引用计数算法（Java虚拟机里没有选用）

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

特点：引用计数算法（Reference Counting）的实现简单，判定效率也很高，在大部分情况下它都是一个不错的算法，也有一些比较著名的应用案例，例如微软的COM(Component Object Model)技术。但是，至少主流的Java虚拟机里面没有选用引用计数算法来管理内存，其中最主要原因是它很难解决对象之间相互循环引用的问题。例如：对象ObjA和对象ObjB都有字段instance，赋值令objA.instance=objB及objB.instance=objA,除此之外这两个对象再无任何饮用，实际上这两个对象已经不可能再被引用了，但是他们因为相互引用者对方，导致他们的引用计数都不为0，于是引用计数算法无法通知GC收集器回收他们。

 

2.2可达性分析算法(Java虚拟机选用)：

在主流的商用程序语言（Java、C#）的主流实现中，都是称通过可达性分析（Reachability Analysis）来判定对象是否存活的。这个算法的基本原理就是通过一系列的称为“GC Roots”的对象做为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Root没有任何引用链相连（用图论的话来说，就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。如图所示，对象object5、object6、object7虽然互相有关联，但是他们呢到达GC Roots是不可达的，所以他们将会被判定为是可回收的对象。

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

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

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

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

本地方法栈中JNI（即一般说的Native方法）引用的对象。

 

2.3回收方法区

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

       永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。以常量池中字面量的回收为例，加入一个字符串“abc”已经进入了常量池，但是当前系统中没有任何一个String对象是叫做“abc”的，换句话说就是没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量，如果这时发生了内存回收，而且必要的话，这个“abc”常量就会被系统清理出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。

       判断一个类是否是无用的类需要同时满足下面3个条件才能算是“无用的类”：

       1）该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。

       2）加载该类的ClassLoader已经被回收。

       3）该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

 

 

3.如何进行回收？

3.1标记--清除算法

标记--清除（Mark-Sweep）算法是最基础的收集算法，算法氛围“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。之所以说它是最基础的收集算法，是因为后续的收集算法都是基于这种思路并对其不足进行改进而得到的。它的两个主要不足之处：一个是效率问题，标记和清除两个过程效率都不高；另一个是空间问题，标记和清除之后会产生大量不连续的内存碎片，空间碎片太多可能导致以后再程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

 
 3.2复制算法 （用来回收新生代）：   

         复制算法（Copying）是为了解决效率问题而出现的，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为了原来的一般，未免太高了一点。

        现在的商业虚拟机都采用这种收集算法来回收新生代，IBM公司的专门研究表明，新生代中的对象98%是“朝生夕死”的，所以实际上并不需要按照1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor。当回收时，将Eden和Survivor中还存活着对象一次性地复制到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1:1，也就是每次新生代中可用内存空间为整个新生代容量的90%（80%+10%），只有10%的内存会被“浪费”。当然，98%的对象可回收只是一般情况下的数据，我们没办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion），也就是说如果另外一块Survivor空间没有足够空间存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老年代。

 

3.3标记--整理算法

      复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以老年代一般不能直接选用这种算法。

      根据老年代的特点，有人提出了“标记--整理”（Mark--Compact）算法，标记过程仍然与“标记--清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

 

 

4.总结

       新生代中每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高，没有额外的空间对其进行分配担保，就必须使用“标记--清除”或者“标记--整理”算法来进行回收。

        补充一下内存分配与回收策略的相关知识：在大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC即小GC。大对象直接进入老年代，这样做的目的是避免在Eden区和两个Survivor区之间发生大量的内存复制。另外长期存活的对象将进入老年代，虚拟机给每个对象定义了一个对象年龄（Age）计数器。如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1。对象在Survivor区中每“熬过”一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁），就将会被晋升到老年代中。对象年龄的阀值可以通过参数-XX:MaxTenuringThreshold=15来设置。然而，虚拟机并不是永远地要求对象的年龄必须达到了MaxTenuringThreshold才能晋升老年代，如果在Sruvivor空间中相同年龄的所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无需等大最大阀值中要求的年龄。