简介
从web服务到各种桌面app，各种各样的程序都使用到了Java。根据程序的不同部署范围，Java提供了多个垃圾收集器，每个垃圾收集器都为不同的需求进行设计，通常情况下，Java平台会根据程序运行的计算机类型选择最合适的垃圾收集器。但是，这种选择并不适用于每个应用程序，如果用户对于程序性能有较为严格的要求，则需要开发人员显示地选择垃圾收集器并调优某些参数，以达到所需的性能水平。
垃圾收集器（GC）是什么？
垃圾收集器(gc)自动管理应用程序的动态内存分配需求，垃圾收集器通过以下操作执行自动动态内存管理:
1.从操作系统申请以及释放内存
2.根据应用程序的内存请求进行内存分配
3.确定应用程序仍然在使用内存的哪些部分
4.回收未使用的内存以供应用程序重用
Java HostSpot垃圾收集器使用多种技术来提高上述操作的效率：
1.分代：新生代与老年代结合，将精力集中在堆上最有可能包含许多可回收内存的区域上
2.并发：使用多线程主动地使操作并行，或者在后台执行一些与应用程序并发的长时间运行的操作。
3.整理：尝试通过压缩活动对象来恢复更大的连续空闲内存。
为何垃圾收集器（GC）的选择很重要？
垃圾收集器的目的是将应用程序开发人员从手动动态内存管理中解放出来。开发人员不再需要匹配分配与释放，也不需要密切关注已分配动态内存的生存期。这完全消除了与内存管理相关的一些类型的错误，但代价是增加一些运行时开销。Java HotSpot VM提供了可供选择的垃圾收集算法。
虽然某些应用程序（大多数情况下此类应用程序规模较小）在适当频率和持续时间的垃圾收集中拥有良好的性能。但是，对于大型应用程序，特别是那些具有大量数据(多个gb)、多个线程和高事务率的应用程序，情况并非如此。
根据Amdahl定理，大多数工作并不能完全并行化，顺序执行的部分并不能从并行中获益，目前Java平台中，除了Serial GC，其他方案都支持并行化以提高性能，保持垃圾收集的开销尽可能低是非常重要的。
假设有一个可以进行完美扩展的Java程序，在单处理器情况下，需要花费1%的时间进行垃圾回收（假设使用Serial GC），如果将这个程序扩展到32个处理器，那么，根据Amdahl定理（S=1/(1-a+a/n)，a为并行计算部分所占比例，n为并行处理结点个数）计算可得到S=24.42，1-(24.42/32)>23%，即程序会损失超过23%的吞吐量，当垃圾回收时间占比越高，则吞吐量的损失越明显，当单处理器下花费10%的时间进行垃圾回收，扩展到32处理器下，程序损失吞吐量超过75%。因此，在小型系统中可以忽略的吞吐量问题，扩展到大型系统时，反而成为了主要的性能瓶颈，我们在这样的瓶颈方面进行一些小的改进，能够在程序性能上取得较大的提升，因此，在足够大型系统中，要保证程序性能，进行GC的调优非常重要。
Serial GC通常适用于大多数小型应用程序，特别是占堆内存100mb左右的应用程序。其他垃圾收集器由于一些专门化行为，因此会带来额外的开销或复杂性。如果应用程序不需要收集器的专门行为，则使用串行收集器。但是，在运行大量内存和两个或更多处理器的机器上的大型、线程密集的应用程序的情况下，串行收集器可能不是最佳选择。当应用程序在这样的服务器上运行时，默认选择垃圾优先(G1)收集器。