Java性能优化3：垃圾回收（GC）

## 前言

> 本文搬运自编程随想09年的文章，较为古老，但涉及到性能优化，想必还是有一些用的。

点击【阅读全文】查看正文。

<div class="article-ads"></div>

<!-- more -->

## 垃圾回收（GC）

[上次的帖子](https://oldmoon.top/post/87)讲到引用类型和基本类型由于内存分配上的差异导致的性能问题。那么今天就来聊一下和内存释放（主要是 GC）有关的话题。

事先声明一下：虽说 SUN 公司已经被 Oracle 吞并了，但是出于习惯，同时也为了偷懒节省打字，以下仍然称之为 SUN 公司。

### ★JVM 的内存空间

在 Java 虚拟机规范中（具体章节请看“这里”），提及了如下几种类型的内存空间：

- ◇栈内存（Stack）：每个线程私有的。
- ◇堆内存（Heap）：所有线程公用的。
- ◇方法区（Method Area）：有点像以前常说的“进程代码段”，这里面存放了每个加载类的反射信息、类函数的代码、编译时常量等信息。
- ◇原生方法栈（Native Method Stack）：主要用于 JNI 中的原生代码，平时很少涉及。

关于栈内存（Stack）和堆内存（Heap），已经在上次的帖子中扫盲过了，大伙儿应该有点印象。由于今天咱们要讨论的“垃圾回收”话题，主要是和堆内存（Heap）有关。其它的几个玩意儿不是今天讨论的重点。等以后有空了，或许可以单独聊一下。


### ★垃圾回收机制简介

　　其实 Java 虚拟机规范中并未规定垃圾回收的相关细节。垃圾回收具体该怎么搞，完全取决于各个 JVM 的设计者。所以，不同的 JVM 之间，GC 的行为可能会有一定的差异。下面咱拿 SUN 官方的 JVM 来简单介绍一下 GC 的机制。

- ◇啥时候进行垃圾回收？

一般情况下，当 JVM 发现堆内存比较紧张、不太够用时，它就会着手进行垃圾回收工作。但是大伙儿要认清这样一个残酷的事实：JVM 进行 GC 的时间点是无法准确预知的。因为 GC 启动的时刻会受到各种运行环境因素的影响，随机性太大。

虽说咱们无法准确预知，但如果你想知道每次垃圾回收执行的情况，还是蛮方便的。可以通过 JVM 的命令行参数“-XX:+PrintGC”把相关信息打印出来。

另外，调用 System.gc() 只是建议 JVM 进行 GC。至于 JVM 到底会不会真的去做，只有天晓得。所以，通常不建议自己手动调用 System.gc()，还是让 JVM 自行决定比较好。另外，使用 JVM 命令行参数“-XX:+DisableExplicitGC”可以让 System.gc() 不起作用。

- ◇谁来负责垃圾回收？

一般情况下，JVM 会有一个或多个专门的垃圾回收线程，由它们负责清理回收垃圾内存。

- ◇如何发现垃圾对象？

垃圾回收线程会从“根集（Root Set）”开始进行对象引用的遍历。所谓的“根集”，就是正在运行的线程中，可以访问的【引用变量】的集合（比如所有线程当前函数的参数和局部变量、当前类的成员变量等等）。垃圾回收线程先找出被根集直接引用的所有对象（不妨叫集合1），然后再找出被集合1直接引用的所有对象（不妨叫集合2），然后再找出被集合2直接引用的所有对象......如此循环往复，直到把能遍历到的对象都遍历完。

凡是从“根集”通过上述遍历可以到达的对象，都称为可达对象或有效对象；反之，则是不可达对象或失效对象（也就是垃圾）。

- ◇如何清理/回收垃圾？

通过上述阶段，就把垃圾对象都找出来。然后垃圾回收线程会进行相应的清理和回收工作，包括：把垃圾内存重新变为可用内存、进行内存的整理以消除内存碎片、等等。这个过程会涉及到若干算法，有兴趣的同学可以参见“这里”。限于篇幅，咱就不深入聊了。

- ◇分代

早期的 JVM 是不采用分代技术的，所有被 GC 管理的对象都存放在同一个堆里面。这么做的缺点比较明显：每次进行GC都要遍历所有对象，开销很大。其实大部分的对象生命周期都很短（短命对象），只有少数对象比较长寿；在这些短命对象中，又只有少数对象占用的内存空间大；其它大量的短命对象都属于小对象（很符合二八原理）。

有鉴于此，从 JDK 1.2 之后，JVM 开始使用分代的垃圾回收（Generational Garbage Collection）。JVM 把 GC 相关的内存分为“年老代”（Tenured）和“年轻代”（Nursery）、“持久代”（Permanent，对应于 JVM 规范的“方法区”）。【大部分】对象在刚创建时，都位于“年轻代”。如果某对象经历了几轮 GC 还活着（大龄对象），就把它移到“年老代”。另外，如果某个对象在创建时比较大，可能就直接被丢到年老代。经过这种策略，使得年轻代总是保存那些短命的小对象。在空间尺寸上，“年轻代”相对较小，而“年老代”相对较大。

因为有了分代技术，JVM 的 GC 也相应分为两种——主要收集（Major Collection）和次要收集（Minor Collection）。“主要收集”同时清理年老代和年轻代，因此开销很大，不常进行；“次要收集”仅仅清理年轻代，开销很小，经常进行。


### ★GC对性能会有啥影响？

刚才介绍了GC的大致原理，那GC对性能会造成哪些影响捏？主要有如下几个方面：

- ◇造成当前运行线程的停顿

早期的 GC 比较弱智。在它工作期间，所有其它的线程都被暂停（以免影响垃圾回收工作）。等到 GC 干完活，其它线程再继续运行。所以，早期 JDK 的 GC 一旦开始工作，整个程序就会陷入假死状态，失去各种响应。

经过这些年的技术改进（包括采用分代技术），从 JDK 1.4 开始，GC 已经比较精明了。在它干活期间，只是偶尔暂停一下其它线程的运行（从长时间假死变为暂时性休克）。

- ◇遍历对象引用的开销

试想如果JVM中的对象很多，那遍历完所有可达对象肯定是比较费劲的工作，这个开销可不小。

- ◇清理和回收垃圾的开销

遍历完对象引用之后，对垃圾的清理和回收也有较大的开销。这部分开销可能包括复制内存块、更新对象引用等等。

### ★几种收集器

- ◇两个性能指标

因为今天聊的是性能的话题，必然会提到衡量 GC 性能的两个重要指标：吞吐量（Throughput）和停顿时间（Pause Time）。吞吐量这个词不是很直观，解释一下：就是 JVM【不用于】GC 的时间占总时间的比率。“吞吐量”是越大越好，“停顿时间”是越小越好。

不同的应用程序对这两个指标的关注点不一样（后面具体会说），也就是所谓的“众口难调”。很多 JVM 厂商为了迎合“众口”，不得不提供多种几种垃圾收集器供使用者选择。不同的收集器，采用的收集策略是不一样的，下面具体介绍。

- ◇串行收集器（Serial Collector）

使用命令行选项`-XX:+UseSerialGC`指定。

这种收集器是最传统的收集器。它使用单线程进行垃圾回收，对于“单 CPU 机器”比较合适。另外，小型应用或者对上述两个指标没有特殊要求的，可以使用串行收集器。

- ◇并行收集器（Parallel Throughput Collector）

顾名思义，这种收集器使用多个线程进行垃圾回收以达到高吞吐量。垃圾回收线程的数量通过命令行选项`-XX:ParallelGCThreads=n`指定。可以设置该数值以便充分利用“多CPU 或 多核”。

当使用命令行选项`-XX:+UseParallelGC`时：它会针对年轻代使用多个垃圾回收线程，对年老代依然使用单个线程的串行方式。此选项最早在JDK 1.5引入。

当使用命令行选项`-XX:+UseParallelOldGC`时：它针对年轻代和年老代都使用多个垃圾回收线程的方式。不过此选项从 JDK 1.6 才开始引入。

- ◇并发收集器（Concurrent Low Pause Collector）

使用命令行选项`-XX:+UseConcMarkSweepGC`指定。

这种收集器优先保证程序的响应。它会尽量让垃圾回收线程和应用自身的线程同时运行，从而降低停顿时间。此选项从JDK 1.4.1开始支持。

- ◇增量收集器（Incremental Collector）

自从 JDK 1.4.2 以来，SUN 官方就停止维护该收集器了。所以俺就节省点口水，不多说了。


### ★如何降低GC的影响？

- ◇尽量减少堆内存的使用

　　由于 GC 是针对存储在堆内存的对象进行的。咱们如果在程序中减少引用对象的分配（也就相应降低堆内存分配），那对于提高 GC 的性能是很有帮助滴。上次“字符串过滤实战”的帖子给出了一个例子，示范了如何通过降低堆内存的分配次数来提升性能。

- ◇设置合适的堆内存大小

JVM 的堆内存是有讲究的，不能太大也不能太小。如果堆内存太小，JVM 老是感觉内存不够用，可能会导致频繁进行垃圾回收，影响了性能；如果堆内存太大，以至于操作系统的大部分物理内存都被 JVM 自个儿霸占了，那可能会影响其它应用程序甚至操作系统本身的性能。

另外，年轻代的大小（或者说“年轻代”与“年老代”的比值）对于 GC 的性能也有明显影响。如果年轻代太小，可能导致次要收集很频繁；如果年轻代太大，导致次要收集的停顿很明显。

JVM 提供了若干和堆内存大小相关的命令行选项，具体如下：
```
-Xms　　设置初始堆内存
-Xmx　　设置最大堆内存
-Xmn　　设置年轻代的大小
-XX:NewRatio=n　　设置年轻代与年老代的比例为“n”
-XX:NewSize=n　　设置年轻代大小为“n”
```

一般情况下，JVM 的默认参数值已经够用。所以没事儿别轻易动用上述选项。如果你非调整不可，一定要做深入的性能对比测试，保证调整后的性能确实优于默认参数值。

- ◇吞吐量和停顿的取舍

前面提到了不同应用的众口难调。常见的口味有两种：(1)看重吞吐量，对停顿时间无所谓；(2)侧重于停顿时间。

对于某些在后台的、单纯运算密集型的应用，属于第一种。比如某些科学计算的应用。这时候建议使用并行收集器。

对于涉及用户 UI 交互的、实时性要求比较高、程序需要快速响应的，属于第二种。比如某些桌面游戏、某些电信交换系统。这时候建议使用并发收集器。


### ★相关的参考资料

- ◇JVM命令行选项说明

这是 SUN 公司内的某个有心人整理的各种命令行参数大全，在“这里”（已失效）。包括有每个参数所适用的 JDK 版本。

- ◇虚拟机规范

`https://docs.oracle.com/javase/specs/`是 SUN 官方提供的 JVM 规范。

[下一个帖子](https://oldmoon.top/post/89)，咱们来聊一下和 finalize 函数有关的性能问题。

<div class="article-ads"></div>