JVM（六）垃圾回收器

Java 堆内存被划分为新生代和年老代两部分，新生代主要使用复制垃圾回收算法 ；年老代主要使用标记-整理、标记-清除垃圾回收算法，因此 java 虚拟中针对新生代和年老代分别提供了多种不同的垃圾收集器，JDK1.6 中 Sun HotSpot 虚拟机的垃圾收集器如下：

一、新生代的垃圾回收器（都使用复制算法）

1、Serial 垃圾收集器 （单线程、 复制算法 ）

Serial（英文连续）是最基本垃圾收集器，使用复制算法，曾经是JDK1.3.1之前新生代唯一的垃圾收集器。Serial 是一个单线程的收集器，它不但只会使用一个 CPU 或一条线程去完成垃圾收集工作，并且在进行垃圾收集的同时，必须暂停其他所有的工作线程，直到垃圾收集结束。

 

Serial 垃圾收集器虽然在收集垃圾过程中需要暂停所有其他的工作线程，但是它简单高效，对于限定单个 CPU 环境来说，没有线程交互的开销，可以获得最高的单线程垃圾收集效率，因此 Serial垃圾收集器依然是 java 虚拟机运行在 Client 模式下默认的新生代垃圾收集器。

 

 

2、ParNew 垃圾收集器 （Serial+ 多线程，复制算法）

ParNew 垃圾收集器其实是 Serial 收集器的多线程版本，也使用复制算法，除了使用多线程进行垃圾收集之外，其余的行为和 Serial 收集器完全一样，ParNew 垃圾收集器在垃圾收集过程中同样也要暂停所有其他的工作线程。

 

ParNew 收集器默认开启和 CPU 数目相同的线程数，可以通过-XX:ParallelGCThreads 参数来限制垃圾收集器的线程数。【Parallel：平行的】

 

ParNew虽然是除了多线程外和Serial收集器几乎完全一样，但是ParNew垃圾收集器是很多java虚拟机运行在 Server 模式下新生代的默认垃圾收集器，而Serial垃圾收集器依然是 java 虚拟机运行在 Client 模式下默认的新生代垃圾收集器。

 

 

3、Parallel Scavenge 收集器（多线程复制算法、高效）

Parallel Scavenge 收集器也是一个新生代垃圾收集器，同样使用复制算法，也是一个多线程的垃圾收集器，它重点关注的是程序达到一个可控制的吞吐量（Thoughput，CPU 用于运行用户代码的时间/CPU 总消耗时间，即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)），高吞吐量可以最高效率地利用 CPU 时间，尽快地完成程序的运算任务，主要适用于在后台运算而不需要太多交互的任务。自适应调节策略也是 ParallelScavenge 收集器与 ParNew 收集器的一个重要区别。

 

三、老年代垃圾回收器（标记整理、标记清除）

1、Serial Old 收集器 （单线程标记整理算法 ）

这个和Serial差不多的；

 

2、Parallel Old 收集器（多线程标记整理算法）

Parallel Old收集器是Parallel Scavenge的年老代版本，使用多线程的标记-整理算法，在JDK1.6才开始提供。

 

在 JDK1.6 之前，新生代使用 ParallelScavenge 收集器只能搭配年老代的 Serial Old 收集器，只能保证新生代的吞吐量优先，无法保证整体的吞吐量，Parallel Old 正是为了在年老代同样提供吞吐量优先的垃圾收集器，如果系统对吞吐量要求比较高，可以优先考虑新生代 Parallel Scavenge和年老代 Parallel Old 收集器的搭配策略。

 

3、CMS 收集器 （多线程标记清除算法）

Concurrent mark sweep(CMS)收集器是一种年老代垃圾收集器，其最主要目标是获取最短垃圾回收停顿时间，和其他年老代使用标记-整理算法不同，它使用多线程的标记-清除算法。最短的垃圾收集停顿时间可以为交互比较高的程序提高用户体验。CMS 工作机制相比其他的垃圾收集器来说更复杂，整个过程分为以下 4 个阶段：

 

1. 初始标记：只是标记一下 GC Roots 能直接关联的对象，速度很快，仍然需要暂停所有的工作线程。
2. 并发标记：进行 GC Roots 跟踪的过程，和用户线程一起工作，不需要暂停工作线程。
3. 重新标记：为了修正在并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，仍然需要暂停所有的工作线程。
4. 并发清除：清除 GC Roots 不可达对象，和用户线程一起工作，不需要暂停工作线程。由于耗时最长的并发标记和并发清除过程中，垃圾收集线程可以和用户现在一起并发工作，所以总体上来看CMS 收集器的内存回收和用户线程是一起并发地执行。

优点：

• 吞吐量提高了很多，高并发；
• 低停顿；

 

缺点：

• 占用了大量的CPU资源；
• 无法处理浮动垃圾（这样并行执行的时候就像边打扫边扔垃圾一样，对于打扫过的地方，后面再扔的垃圾那就得等下一次打扫了）；
• 出现Concurrent Mode Failure错误，这是因为清理垃圾的线程和工作线程并行执行，那么对于这些工作线程创建的新的对象我们得预留一块空间，这块空间留大了浪费资源，留小了不够用就会发生这个错误；
• 产生空间碎片，标记—清除算法导致的；

 

 

 

三、G1垃圾回收器（标记整理）

G1垃圾回收器既可以用于新生代也可以用于老年代的垃圾回收；

 

相比较于CMS垃圾回收器，G1垃圾回收器最大的改进是：

• 基于标记-整理算法，不产生内存碎片；
• 可以非常精确控制停顿时间，在不牺牲吞吐量前提下，实现低停顿垃圾回收。

 

G1 收集器避免全区域垃圾收集，它把堆内存划分为大小固定的几个独立区域，并且跟踪这些区域的垃圾收集进度，同时在后台维护一个优先级列表，每次根据所允许的收集时间，优先回收垃圾最多的区域。区域划分和优先级区域回收机制，确保 G1 收集器可以在有限时间获得最高的垃圾收集效率。

 

优点：

• 并行和并发；
• 分代收集；
• 空间整合（标记—整理算法实现的）；
• 可预测的停顿（能指定停顿不超过某一时间）；

四、总结

垃圾回收器	采用的回收算法	线程数	回收的区域	备注
Serial	复制算法	单线程	新生代	回收的时候会暂停工作线程
ParNew	复制算法	多线程	新生代	Serial的多线程版
Parallel Scavenge	复制算法	多线程	新生代	追求吞吐量
Serial Old	标记—整理算法	单线程	老年代	Serial收集器的老年代版本
Parallel Old	标记—整理算法	多线程	老年代	Parallel Scavenge的老年代版本
CMS	标记—清除算法	多线程	老年代	最求最短GC停顿时间
G1	标记—整理算法	多线程	整个堆	高效，可预测的停顿时间，并发、并行

 

 

五、方法区的回收

方法区的内存回收目标主要是针对 常量池的回收 和 对类型的卸载。回收废弃常量与回收Java堆中的对象非常类似。以常量池中字面量的回收为例，假如一个字符串“abc”已经进入了常量池中，但是当前系统没有任何一个String对象是叫做“abc”的，换句话说是没有任何String对象引用常量池中的“abc”常量，也没有其他地方引用了这个字面量，如果在这时候发生内存回收，而且必要的话，这个“abc”常量就会被系统“请”出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似。

 

判定一个常量是否是“废弃常量”比较简单，而要判定一个类是否是“无用的类”的条件则相对苛刻许多。类需要同时满足下面3个条件才能算是“无用的类”：

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

 

虚拟机可以对满足上述3个条件的无用类进行回收(卸载)，这里说的仅仅是“可以”，而不是和对象一样，不使用了就必然会回收。特别地，在大量使用反射、动态代理、CGLib等bytecode框架的场景，以及动态生成JSP和OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出。