上次的帖子讲到引用类型和基本类型由于内存分配上的差异导致的性能问题。那么今天就来聊一下和内存释放（主要是 GC）有关的话题。
事先声明一下：虽说 SUN 公司已经被 Oracle 吞并了，但是出于习惯，同时也为了偷懒节省打字，以下仍然称之为 SUN 公司。
在 Java 虚拟机规范中（具体章节请看“这里”），提及了如下几种类型的内存空间：
其实 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 干完活，其它线程再继续运行。所以，早期 JDK 的 GC 一旦开始工作，整个程序就会陷入假死状态，失去各种响应。
经过这些年的技术改进（包括采用分代技术），从 JDK 1.4 开始，GC 已经比较精明了。在它干活期间，只是偶尔暂停一下其它线程的运行（从长时间假死变为暂时性休克）。
试想如果JVM中的对象很多，那遍历完所有可达对象肯定是比较费劲的工作，这个开销可不小。
遍历完对象引用之后，对垃圾的清理和回收也有较大的开销。这部分开销可能包括复制内存块、更新对象引用等等。
因为今天聊的是性能的话题，必然会提到衡量 GC 性能的两个重要指标：吞吐量（Throughput）和停顿时间（Pause Time）。吞吐量这个词不是很直观，解释一下：就是 JVM【不用于】GC 的时间占总时间的比率。“吞吐量”是越大越好，“停顿时间”是越小越好。
不同的应用程序对这两个指标的关注点不一样（后面具体会说），也就是所谓的“众口难调”。很多 JVM 厂商为了迎合“众口”，不得不提供多种几种垃圾收集器供使用者选择。不同的收集器，采用的收集策略是不一样的，下面具体介绍。
使用命令行选项“-XX:+UseSerialGC”指定。
这种收集器是最传统的收集器。它使用单线程进行垃圾回收，对于“单 CPU 机器”比较合适。另外，小型应用或者对上述两个指标没有特殊要求的，可以使用串行收集器。
顾名思义，这种收集器使用多个线程进行垃圾回收以达到高吞吐量。垃圾回收线程的数量通过命令行选项“-XX:ParallelGCThreads=n”指定。可以设置该数值以便充分利用“多CPU 或 多核”。
当使用命令行选项“-XX:+UseParallelGC”时：它会针对年轻代使用多个垃圾回收线程，对年老代依然使用单个线程的串行方式。此选项最早在JDK 1.5引入。
当使用命令行选项“-XX:+UseParallelOldGC”时：它针对年轻代和年老代都使用多个垃圾回收线程的方式。不过此选项从 JDK 1.6 才开始引入。
使用命令行选项“-XX:+UseConcMarkSweepGC”指定。
这种收集器优先保证程序的响应。它会尽量让垃圾回收线程和应用自身的线程同时运行，从而降低停顿时间。此选项从JDK 1.4.1开始支持。
自从 JDK 1.4.2 以来，SUN 官方就停止维护该收集器了。所以俺就节省点口水，不多说了。
由于 GC 是针对存储在堆内存的对象进行的。咱们如果在程序中减少引用对象的分配（也就相应降低堆内存分配），那对于提高 GC 的性能是很有帮助滴。上次“字符串过滤实战”的帖子给出了一个例子，示范了如何通过降低堆内存的分配次数来提升性能。
JVM 的堆内存是有讲究的，不能太大也不能太小。如果堆内存太小，JVM 老是感觉内存不够用，可能会导致频繁进行垃圾回收，影响了性能；如果堆内存太大，以至于操作系统的大部分物理内存都被 JVM 自个儿霸占了，那可能会影响其它应用程序甚至操作系统本身的性能。
另外，年轻代的大小（或者说“年轻代”与“年老代”的比值）对于 GC 的性能也有明显影响。如果年轻代太小，可能导致次要收集很频繁；如果年轻代太大，导致次要收集的停顿很明显。
JVM 提供了若干和堆内存大小相关的命令行选项，具体如下：
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
-Xms 设置初始堆内存
-Xmx 设置最大堆内存
-Xmn 设置年轻代的大小
-XX:NewRatio=n 设置年轻代与年老代的比例为“n”
-XX:NewSize=n 设置年轻代大小为“n”
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
一般情况下，JVM 的默认参数值已经够用。所以没事儿别轻易动用上述选项。如果你非调整不可，一定要做深入的性能对比测试，保证调整后的性能确实优于默认参数值。
前面提到了不同应用的众口难调。常见的口味有两种：(1)看重吞吐量，对停顿时间无所谓；(2)侧重于停顿时间。
对于某些在后台的、单纯运算密集型的应用，属于第一种。比如某些科学计算的应用。这时候建议使用并行收集器。
对于涉及用户 UI 交互的、实时性要求比较高、程序需要快速响应的，属于第二种。比如某些桌面游戏、某些电信交换系统。这时候建议使用并发收集器。
SUN 官方提供了若干关于 JVM 垃圾回收调优的说明文档：
JDK 1.4.2 请看“这里”；
JDK 1.5请看“这里”；
JDK 1.6请看“这里”。
这是 SUN 公司内的某个有心人整理的各种命令行参数大全，在“这里”。包括有每个参数所适用的 JDK 版本。
“这里”是 SUN 官方提供的 JVM 规范。
下一个帖子，咱们来聊一下和 finalize 函数有关的性能问题。
回到本系列的目录
事先声明一下：虽说 SUN 公司已经被 Oracle 吞并了，但是出于习惯，同时也为了偷懒节省打字，以下仍然称之为 SUN 公司。
★JVM 的内存空间
在 Java 虚拟机规范中（具体章节请看“这里”），提及了如下几种类型的内存空间：
◇栈内存（Stack）：每个线程私有的。关于栈内存（Stack）和堆内存（Heap），已经在上次的帖子中扫盲过了，大伙儿应该有点印象。由于今天咱们要讨论的“垃圾回收”话题，主要是和堆内存（Heap）有关。其它的几个玩意儿不是今天讨论的重点。等以后有空了，或许可以单独聊一下。
◇堆内存（Heap）：所有线程公用的。
◇方法区（Method Area）：有点像以前常说的“进程代码段”，这里面存放了每个加载类的反射信息、类函数的代码、编译时常量等信息。
◇原生方法栈（Native Method Stack）：主要用于 JNI 中的原生代码，平时很少涉及。
★垃圾回收机制简介
其实 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 交互的、实时性要求比较高、程序需要快速响应的，属于第二种。比如某些桌面游戏、某些电信交换系统。这时候建议使用并发收集器。
★相关的参考资料
◇GC调优资料
SUN 官方提供了若干关于 JVM 垃圾回收调优的说明文档：
JDK 1.4.2 请看“这里”；
JDK 1.5请看“这里”；
JDK 1.6请看“这里”。
◇JVM命令行选项说明
这是 SUN 公司内的某个有心人整理的各种命令行参数大全，在“这里”。包括有每个参数所适用的 JDK 版本。
◇虚拟机规范
“这里”是 SUN 官方提供的 JVM 规范。
下一个帖子，咱们来聊一下和 finalize 函数有关的性能问题。
回到本系列的目录
版权声明
本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者编程随想和本文原始地址：
https://program-think.blogspot.com/2009/04/java-performance-tuning-3-gc.html
本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者编程随想和本文原始地址：
https://program-think.blogspot.com/2009/04/java-performance-tuning-3-gc.html
