从台式机上的小applet到大型服务器上的web服务，各种各样的应用程序都使用Java Platform, Standard Edition (Java SE)。为了支持这种多样化的部署，Java HotSpot虚拟机提供了多个垃圾收集器，每个垃圾收集器都是为了满足不同的需求而设计的。Java SE根据运行应用程序的计算机的类别选择最合适的垃圾收集器。然而，这种选择对每个应用并不是都是最佳的。针对具有严格性能目标要求或其他要求的用户、开发人员和管理员可能需要显式选择垃圾收集器，并调整某些参数以达到所需的性能水平。本文档提供了帮助完成这些任务的信息。
首先，垃圾收集器的一般特性和基本调优选项将在串行“Stop-the-world”系列收集器上下文中进行描述。然后给出了其他收集器的具体特性以及选择收集器时要考虑的因素。
目录
一.什么是垃圾收集器？
垃圾收集器(GC)自动管理应用程序的动态内存分配请求。
垃圾收集器通过以下操作执行自动动态内存管理：
1.从操作系统分配内存并将内存返回给操作系统。
2.当应用程序请求内存时，将内存分发给它。
3.确定应用程序仍在使用内存的哪些部分。
4. 回收未使用的内存供应用程序重用。
Java HotSpot垃圾收集器使用各种技术来提高这些操作的效率：
1.使用分代清除和老化结合使用，将精力集中在堆中最有可能包含大量可回收内存区域的区域上。
2.使用多线程积极地使操作并行，或在应用程序后台并发执行一些长时间运行的操作。
3.尝试通过压缩活动对象来恢复更大的连续空闲内存。
二.为什么垃圾收集器的选择至关重要？
垃圾收集器的目的是使应用程序开发人员免于手动动态内存管理。 开发人员无需将分配与解除分配相匹配，并且可以密切关注分配的动态内存的生命周期。 这完全消除了与内存管理相关的一些类错误，但代价是一些额外的运行时的开销。 Java HotSpot VM提供了一系列垃圾收集算法供您选择。
什么时候垃圾收集器的选择至关重要?对于某些应用程序，答案是永远不会。也就是说，应用程序可以在存在垃圾收集的情况下正常运行，暂停的频率和持续时间都不高。但是，对于大型应用程序，尤其是具有大量数据(多个gb)、许多线程和高事务率的应用程序，情况就不一样了。
Amdahl定律(给定问题的并行加速受问题的顺序部分的限制)意味着大多数工作负载不能完全并行化;有些部分总是顺序运行的，不能从并行性中获益。在Java平台中，目前支持四种垃圾收集的替代方案，除了串行GC之外，所有的这些方案都是并行化工作以提高性能。保持尽可能低的垃圾收集开销是非常重要的。这可以在下面的例子中看到。
下图模拟了一个理想的系统，除了垃圾收集之外，该系统是完全可伸缩的。红线是一个应用程序在单处理器系统上只花费1%的时间进行垃圾收集。这意味着32个处理器的系统的吞吐量损失超过20%。洋红色的行显示，对于垃圾收集时间占10%的应用程序(在单处理器应用程序中垃圾收集的时间不算多)，当扩展到32个处理器时，超过75%的吞吐量会丢失。
这个图显示，在小系统上开发时，可以忽略的吞吐量问题可能成为扩展到大系统时的主要瓶颈。然而，在减少这种瓶颈方面的小的改进可以在性能上产生很大的提高。对于足够大的系统，选择正确的垃圾收集器，并在必要时对其进行调优是值得的。
串行收集器通常适用于大多数小型应用程序，特别是那些在现代处理器上需要高达约100兆字节堆的应用程序。 其他收器具有额外的开销或复杂性，这是"专门行为"的代价。 如果应用程序不需要备用收集器的特殊行为，请使用串行收集器。 串行收集器不是最佳选择的一种情况是,运行在具有大量内存和两个或更多处理器的机器上的大型多线程应用程序。当应用程序在这样的服务器级计算机上运行时，默认情况下会选择Garbage-First (G1)收集器。