JVM—垃圾收集器与内存分配策略

尽管现在内存的动态分配与内存回收技术已经相当成熟,一切看起来都进入了"自动化"时代,但我们之所以要学习GC和内存分配,就是当需要排查各种内存溢出,内存泄露问题时,当垃圾收集称为系统达到更高并发量的瓶颈时,我们就需要对这些"自动化"的技术实施必要的监控和调节.

我们之前说过java内存运行时区域的各个部分:程序计数器,虚拟机栈,本地方法栈三个区域随线程而生,随线程而灭;栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作,每一个栈帧分配多少内存基本上在类结构确定下来就已知了,因此这几个区域的内存分配和回收都具有确定性,不需要过多考虑回收的问题,因为方法结束或者线程结束时,内存也就跟着回收了.
而java堆和方法区不一样,一个接口中的多个实现类需要的内存可能不一样,一个方法中的多个分支需要的内存也不一样,我么只有在程序运行期间才能知道会创建哪些对象,这部分内存的分配和回收都是动态的.

1.判断对象"已死"

在垃圾收集器进行回收前,第一件事情就是要确定这些对象之中哪些还存活,哪些已经死去.

1).引用计数算法: 给对象中添加一个引用计数器,每当有一个地方引用它时,计数器值就加1;当引用失效时,计数器就减1;
客观的说,引用计数算法(Reference Counting)的实现简单,判定效率也很高,但java虚拟机里并没有选择这个算法来管理内存,最主要的原因就是它很难解决对象之间相互循环引用的问题

2).可达性分析算法(Reachability Analysis):
这个算法的基本思路就是通过一系列的称为"GC Roots"的对象作为起始点,从这些节点开始向下搜索,搜索走过的路径称为"引用链"(Reference Chain),当一个对象到GC Roots没有任何引用链相连(也就是从GC Roots到这个对象不可达),则证明这个对象是不可用的

在Java中,可作为GC Roots的对象包括下面几种:

虚拟机栈中引用的对象
方法区中类静态属性引用的对象
方法区中常量引用的对象
本地方法栈中JNI(本地方法)引用的对象

3).引用相关:
无论用上述哪个算法,判断对象是否存活都与"引用"有关. 在JDK1.2前,Java引用的定义为:如果reference类型的数据中存储的数值代表的是另一块内存的起始地址,就称这块内存代表着一个引用. 后来我们才对引用的概念进行了补充,将引用分为:强引用(Strong Reference),软引用(Soft Reference),弱引用(Weak Reference),虚引用(Phantom Reference)

强引用:强引用就是指在程序代码中普遍存在的,类似"Object obj = new Object()"这类的引用,只要强引用还在,垃圾收集器永远不会回收掉被引用的对象.
软引用:描述一些还有用但非必须的对象,在系统将要发生内存溢出异常时,将会把这些对象列为回收范围之中进行第二次回收
弱引用:比软引用的强度更弱一些,被弱引用关联的对象只能生存到下一次垃圾收集发生之前. 当垃圾收集工作时,无论当前内存是否足够,都会回收掉只被软引用关联的对象.
虚引用:一个对象是否有虚引用的存在,完全不会对其生存时间构成影响,也无法通过虚引用来取得一个对象实例.为一个对象设置虚引用关联的唯一目的就是能在这个对象被垃圾收集器回收时收到一个系统通知.

4).对象被宣判死亡
即使是在可达性分析算法中不可达的对象,也并不是一定会被回收的. 这个时候他暂时会被标记一次,并进行筛选:如果对象没有覆盖finalize()方法或这finalize()方法已经被虚拟机调用过,那么这个对象就将被回收. 如果这个对象被判定为有必要执行finalize()方法,那么这个对象会放置在一个叫做F-Queue队列之中,并在稍后一个由虚拟机自动建立的,低优先级的Finalizer线程中去执行(并不承诺会等finalize()运行结束,因为如果一个对象在finalize()中执行缓慢,会导致整个F-Queue队列中其他对象一直等待,导致内存崩溃).
所以finalize()方法是对象逃脱死亡命运的最后一次机会,稍后GC将对F-Queue中的对象进行第二次标记,如果在finalize()方法中该对象能让自己与某个类变量或对象的成员变量建立关系,它就会被移除出"即将回收"的集合.如果没有的话,这个对象将被回收.

注意:任何对象的finalize()方法只会被系统自动调用一次,并且并不推荐自己去对对象使用这个方法

5).回收方法区
之前说过,在方法区是需要存在垃圾收集的,只不过收集效果与Java堆比起来并不理想.
方法区垃圾回收主要是回收 废弃常量 和 无用的类两部分.回收废弃常量与回收Java堆对象非常类似,例如一个字符串常量"abc"在常量池中,但是当前没有任何String对象引用该常量池中的"abc"常量,如果发生内存回收,这个"abc"就会被系统清理出常量池

但要判断一个类是否是"无用的类",条件则比较苛刻,需要满足以下条件:

该类所有的实例都已经被回收,也就是Java堆中不存在该类的任何实例
加载该类的ClassLoader都已经被回收
该类对应的java.lang.Class对象没有在任何地方被引用,无法在任何地方通过反射访问该类的方法.

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

2.垃圾收集算法

1).标记-清除
“标记-清除”（Mark-Sweep）算法，如它的名字一样，算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象。之所以说它是最基础的收集算法，是因为后续的收集算法都是基于这种思路并对其缺点进行改进而得到的。

它的主要缺点有两个：一个是效率问题，标记和清除过程的效率都不高；另外一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致，当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
在这里插入图片描述

2).复制算法
“复制”（Copying）的收集算法，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

这样使得每次都是对其中的一块进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为原来的一半，持续复制长生存期的对象则导致效率降低。
在这里插入图片描述
3).标记-整理
复制收集算法在对象存活率较高时就要执行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。

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

4).分代收集算法
GC分代的基本假设：绝大部分对象的生命周期都非常短暂，存活时间短。

“分代收集”（Generational Collection）算法，把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或“标记-整理”算法来进行回收。