内存回收策略

本文主要内容

• 对象已死
• 引用
• 垃圾收集算法
• 垃圾收集器

本文主要从概念上介绍内存回收及垃圾收集器相关内容，不涉及具体性能调优。

内存回收是程序员永恒的主题，虽然Java虚拟机自动回收内存，但仍存在内存漏泄的可能，需要理解内存回收机制，有助于程序员规避、排查内存泄漏问题。

GC机制，最重要的是三个问题：

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

对象已死

对象是否已经死亡，可被回收，经常能听到下面这种说法：

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

不过，它存在一个致命缺陷，很难解决循环引用问题，比如对象AB,A引用B，B也引用A，但它们再没有被其它人所引用，AB理应是被回收对象，但它们的引用计数器仍然不为0，导致无法回收。

Java虚拟机不使用此算法来判定对象是否死亡，不过它依然有很多优点，简单。Android 中的智能指针即是使用这种方法，不过添加了智能指针强弱引用来解决循环引用问题

可达性分析算法，这个算法的基本思路就是通过一系列的名为“GC Roots"的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到“GC Roots"没有任何引用链相连，则此对象不可用，将被回收

在Java中，可作为“GC Roots"的对象包括以下几种：

• 虚拟机栈（栈桢中的本地变量表）中引用的对象
• 方法区中的类静态属性引用的对象
• 方法区中的常量引用的对象
• 本地方法栈中JNI（即一般说的native方法）的引用的对象

引用

在JDK1.2以前，引用的概念为：

如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称这块内存代表着一个引用

JDK1.2之后，引用概念进行了扩充，将引用分为强引用、软引用、弱引用、虚引用四种，四种引用强度依次减弱。

• 强引用，就是指代码中普遍存在的，类似”Object ojb = new Object()“这类引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象

• 软引用，用来描述一些还有用，但并非必要的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中并进行第二次回收，如果这次回收还是没有足够内存，才会抛出内存溢出异常，JDK中提供SoftReference类来实现软引用

• 弱引用，也是用于描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前，当垃圾收集器工作时，无论当前内存是否足够，都会回收掉被弱引用关联的对象，JDK中提供WeakReference来实现弱引用

• 虚引用，它是最弱的一种引用关系，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用取得一个对象实例，为一个对象设置虚引用关联的唯一目的就是希望能在这个对象被回收时收到一个系统通知。JDK使用PhantomReference来实现虚引用

垃圾收集算法

本章将介绍三种垃圾收集算法。

标记清除算法，算法分成“标记”和“清除”两个阶段，首先标记出需要回收的对象，在标记完成后统一回收掉所有被标记的对象

它主要有两个问题，一是效率不高，标记和清除过程的效率都不高，另一个是空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多，当程序在运行中需要分配较大对象，因为碎片过多，可能无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作

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

现在的商业虚拟机都采用这种算法来回收新生代，新生代中的对象98%是朝生夕死的，所以并不需要按照1：1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden空间和其中的一块Survivor空间，当回收时，将Eden和Survivor看还存活的对象一次性拷贝到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor空间。

虚拟机默认Eden和Survivor的大小比例是8比1，所以只有10%的空间会被浪费。

如果存活的对象较多而Survivor空间不够用时，需要依赖其它内存（老年代）进行分配担保，如果另外一块Survivor空间没有足够的空间来存放上一次新生代的存活对象，这些对象将直接通过分配担保机制进入老年代

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

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

分代收集算法

当前商业虚拟机的垃圾收集都采用分代收集算法。它根据对象存活周期的不同将内存划分为几块。

一般是把Java堆分成新生代和老年代，新生代又分成一块较大的Eden和两块Survivor。根据各个年代的特点采用最适当的收集算法。

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

垃圾收集器

Serial收集器

Serial收集器是最基本、历史最悠久的收集器。顾名思义，这个收集器是一个单线程收集器。单线程的意义并不仅仅说明它只会使用一个CPU或者一条线程去完成垃圾收集工作，更重要的是它在垃圾收集时，必须暂停其他所有的工作线程（Sun将这件事情称之为“Stop the world”），直到它结束

“Stop the world”，非常影响用户体验，虚拟机在后台自动发起和完成的，在用户不可见的情况下把用户的正常工作的线程全部停掉。

Serial收集器运行示意图

虽然Serial收集器出现时间较长，但它依然是Client模式下的默认新生代收集器

ParNew收集器

ParNew收集器其实就是Serial收集器的多线程控制版本，除了使用多条线程进行垃圾收集之外，其它和Serial收集器完全一样。

ParNew收集器运行示意图

ParNew收集器是Server模式下虚拟机中的首选的新生代收集器。而且在单CPU环境下，ParNew绝对不会比Serial更高效，甚至由于存在线程交互的开销，在两个CPU的环境中都不一定比Serial更好

Parallel Scavenge收集器

Parallel Scavenge收集器也是一个新生代收集器，它也是使用复制算法，又是并行的多线程收集器，看上去和ParNew一样，但它非常的有特点。

吞吐量，CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量 = 运行用户代码时间 / （运行用户代码时间 + 垃圾收集时间）

Parallel Scavenge收集器关注点即是吞吐量，CMS等收集器的关注点是尽量缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge的目的则是达到一个可控制的吞吐量。

Parallel Scavenge提供两个参数用于精准控制吞吐量

Serial old收集器

Serial old收集器是Serial收集器的老年代版本，同样是一个单线程收集器，使用标记整理算法，它的主要意义也是被Client模式下的虚拟机使用

Parallel old收集器

Parallel old是Parallel Scavenge收集器的老年代版本，使用多线程和标记整理算法。

Parallel old/Parallel Scavenge运行示意图

CMS收集器

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器，它很适合互联网站或者B/S系统的服务端上。

从Mark Sweep名字可知，CMS用的是标记清除算法，它的动作过程较之前的复杂一些，整个过程分为4个步骤：

• 初始标记
• 并发标记
• 重新标记
• 并发清除

其中初始标记、重新标记这两个步骤仍然需要 “Stop the world”。初始标记只是标记一下GC Roots能直接关联到的对象，速度很快，并发阶段就是进行GC Root Tracing的过程，而重新标记则是为了修正并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，重新标记时间略比初始标记长，但远比并发标记时间短。

整个过程最耗时的是并发标记和并发清除，但用户线程和收集器线程一起工作，所以总体上说，CMS收集器的内存回收过程是与用户线程一起并发地执行。

CMS运行示意图