并发编程网 - ifeve.com

翻译原文

垃圾回收调优简介

从小的桌面应用到大型服务器上的web应用，各种各样的应用程序都使用标准版Java平台（Java SE）。为了支持这一系列不同的部署，Java HotSpot VM提供了多个垃圾收集器，每个垃圾收集器都是为满足不同的需求而设计的。Java SE基于应用程序在计算机上运行的类选择最合适的垃圾收集器。然而，对于每个应用程序，此选择可能不是最优的。具备严格的性能目标或者其他需求的用户，开发人员和管理员可能需要显式地选择垃圾收集器并优化某些参数已达到渴望的性能级别。本文档提供了帮助显式完成优化任务的信息。
首先，垃圾收集器的一般特性和基础的调优选项将被描述通过串行垃圾收集器，然后介绍其他垃圾收集器的具体特性以及选择垃圾收集器时要考虑的因素。

话题

• 什么是垃圾收集器？
• 为什么垃圾收集器的选择重要？
• 文档中支持的操作系统

什么是垃圾收集器

垃圾收集器自动管理应用程序的动态内存分配请求。
垃圾收集器通过以下操作执行自动的动态内存管理：

• 从操作系统分配内存并将内存返回给操作系统。
• 在应用程序请求时将内存分发给他
• 确定应用程序仍在使用该内存的哪些部分
• 回收未使用的内存供应用程序重用

Java HotSpot垃圾收集器采用各种技术来提高这些操作的效率：

• 在老化的同时使用分代清理，将精力集中在最有可能可能包含大量可回收内存区域的堆上。
• 使用多线程积极地使操作并行，或者在后台与应用程序并发地执行一些长时间运行的操作。
• 通过压缩活动对象来恢复更大的连续可用内存

为什么垃圾收集器的选择重要

垃圾收集器的目的是将应用程序开发人员从手动动态内存管理中解放出来。开发人员不再需要将分配和释放内存匹配，并且密切关注已分配动态内存的生命周期。这完全消除了一些与内存管理相关的类错误，但代价是一些额外的运行时开销。Java HotSpot虚拟机提供一系列垃圾收集算法以供选择。
垃圾收集器的选择什么时候重要？对于某些应用程序，答案是永远不。也就是说，应用程序可以在当前存在的垃圾收集器下以合适的暂停频率和时间运行良好。然而，对于一大类应用程序来说，情况并非如此，特别是那些具有大量数据（千兆字节），多线程和高事务速率的应用程序。
阿姆达尔定律Amdahl’s law（给定问题的并行加速受问题顺序部分的限制）说明大多数工作负载并不能完全并行化。有些部分总是连续顺序的，并且不受益于并行性。在Java平台中，目前有四个受支持的垃圾收集器可选择方案，除了串行垃圾收集器，其他垃圾收集器收集器都以并行化的工作方式提升性能。尽可能降低垃圾收集的开销是非常重要的。这点可以在接下来的示例中看到。
图1-1中的图表模拟了一个理想的系统，除了垃圾收集之外，这个系统是完全可伸缩的。红线是应用程序在单核处理器上只花费1%的时间进行垃圾收集。这意味着在32核处理器的系统上，吞吐量损失超过20%。洋红线显示，对于垃圾收集时间占10%的应用程序（不考虑在单个核上进行令人无法容忍的超长时间的垃圾收集），当他的处理器个数扩展到32个的时候，超过75%的吞吐量全丢失。

此图显示，在小型系统上开发时可以忽略的吞吐量问题可能会成为向大型系统扩展时的主要瓶颈。然而，在减少这种瓶颈方面的小改进可以在性能上产生很大的提高。对于一个足够大的系统，选择正确的垃圾收集器并且在必要的时候对他进行调优是值得的。
串行垃圾收集器通常适用于大多数小型应用程序，尤其是那些需要在现代处理器上达到大约100兆堆大小的串行垃圾收集器。其他的垃圾收集器拥有额外的开销和复杂性，这是专业行为的代价。如果应用程序不需要专业行为的垃圾收集器，使用串行垃圾收集器就可以。在一台具有大量内存和多处理的机器上，运行着大量重型线程的应用程序，串行垃圾收集器不被认为是最佳选择。当应用程序运行在这种服务器类级别的机器上时，G1垃圾收集器默认是最好的选择。参见 人机工程学

文档中支持的操作系统

本文档以及其建议适用于所有JDK 13支持的系统配置，受特定配置中某些垃圾收集器的实际可用性限制。参阅 [Oracle JDK认证的系统配置]

批注

垃圾回收时间占比，吞吐量和核数的关系

文中的图，一直有一个问题，可以显示地看出当垃圾收集器占用的时间固定的时候，随着核数的增多，吞吐量会出现下降。可是在计算的时候，吞吐量占比+垃圾收集时间占比=1，是不是除了应用程序运行时间和垃圾回收时间，还有其他的开销。如果没有为什么吞吐占比和垃圾回收时间占比相加不为一？