HotSpot 虚拟机垃圾收集器调优指南一

HotSpot 虚拟机垃圾收集器调优指南

前言

Java平台标准的HotSpot虚拟机垃圾收集器调优指南描述了Java HotSpot虚拟机中包含的垃圾收集方法，并帮助您确定哪一种方法最适合您的需求。

读者

本文档适用于希望提高对Java HotSpot VM 垃圾收集器理解的Java HotSpot VM 用户、应用程序开发人员和系统管理员。

1 垃圾收集调优介绍

	在这里插入代码片从桌面上的小程序到大型服务器上的web服务，各种各样的应用程序都使用Java SE。为了支持这种多样化的部署，
Java HotSpot VM 提供了多种垃圾收集器，每个垃圾收集器设计用于满足不同的需求。Java SE根据运行应用程序的计算机类别选择合适的垃圾收集器。
但是，这种选择可能并不适合每个应用程序。具有严格性能目标或者其它要求的用户，开发人员和管理员可能需要显示的选择垃圾收集器并调优某些参数，
以实现所需的性能水平。

首先，在serial,stop-the-world收集器的篇幅中描述垃圾收集器的一般特性和基本调优参数。然后介绍其它收集器的具体特点以及在选择收集器的时候需要考虑的因素。

主题

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

垃圾回收器是什么？
垃圾回收器（GC）自动管理应用程序的动态内存分配请求。
垃圾收集器通过以下操作实现自动动态内存管理：

• 从操作系统中分配内存并将其返回给操作系统
• 当应用程序请求内存时，将内存分发给它
• 确定应用程序仍在使用该内存的哪些部分
• 回收未使用的内存以供应用程序重用
  Java HotSpot 垃圾回收器使用各种技术来提高这些操作的效率：
• 将分代清除与老化结合使用，以集中精力处理堆中最有可能包含大量回收内存区域的区域。
• 使用多线程并行操作或者在与应用程序并发的后台执行一些长时间运行的操作
• 尝试通过压缩存活对象来恢复更大的连续空闲内存

为什么垃圾回收器选择很重要？
垃圾回收器的目的是将应用程序开发人员从手动动态内存管理中解放出来。开发人员不再需要匹配分配和释放，并密切关注已分配内存的生命周期。这完全消除了与内存管理相关的一些类错误，但代价是额外的运行时开销。Java HotSpot VM 提供了可供选择的垃圾收集算法。
什么情况需要选择垃圾回收器？对于某些应用程序，答案是永远不会。也就是说，在当前垃圾回收器暂停的频率和持续的时间适中，应用程序就可以很好的执行，就不用再次选择垃圾回收器了。但是，对于大量的应用程序，尤其是具有大量数据、许多线程和高事务率的应用程序，情况就不是这样了。
Amdahl定律暗示着大多数工作负载不能完全并行。有些部分总是顺序的，不能从并行中受益。在Java平台，目前有四种受支持的垃圾收集备选方案，除了串行GC之外，其余的垃圾收集都可以并行化工作以提高性能。尽可能的降低垃圾收集的开销是非常重要的。这可以在下面的例子中看到。
图1-1中建模了一个理想的系统，除了垃圾收集之外，它是完全可以伸缩的。红线表示在单处理器系统上只花费1%的时间进行垃圾收集的应用程序。这意味着在拥有32个处理器的系统上，吞吐量损失超过20%。洋红色的线显示，对于垃圾收集时间为10%的应用程序（在单处理器应用程序中，这种垃圾回收时间不算是惊人的），当扩展到32个处理器时，会损失75%以上的吞吐量。

这个图表明，在小系统上开发时微不足道的吞吐量问题可能在扩展到大系统时成为主要瓶颈。然而，减少这种瓶颈的小改进可以产生很大的性能提升。对于足够大的系统，有不要选择正确的垃圾收集器并在必要时对其进行调优。串行收集器通常适用于大多数小型应用程序，特别是那些需要在现代处理器上堆积高达约100兆字节的应用程序。其他收集器有额外的开销或复杂性，这是特定功能的代价。如果应用程序不需要使用备选收集器的特定功能，则使用串行收集器。**串行收集器不是最佳选择的一种情况是运行在具有大量内存和两个或更多处理器的机器上的大型、多线程应用程序。**当应用程序在这样的服务器类机器上运行时，默认选择Garbage-First（G1）收集器。