Java SE 6 Hotspot.docxVIP

Java SE 6 Hotspot [TM] 虚拟机垃圾回收调优1. 概述Java 平台标准版（Java SE?）被广泛应用于各种应用，从桌面上的小小的 applet 到大型服务器上的 Web Service 无处不在。为了支持各种不同的部署场景，Java HotSpot? 虚拟机提供了多种垃圾回收器，每种都为满足不同的需求而设定。这是也为了满足大大小小不同应用需求的一部分。不过，那些需要高性能应用的用户、开发者和管理员们也被选择适合他们应用的恰当的垃圾回收器的繁琐困扰着。取消这些额外操作的重要一步是在 J2SE? 5.0 中作出的：垃圾回收器会根据应用运行的计算机类型而作出选择。 这个垃圾回收器的“更好的选择”总的说是一种进步，不过，这并不意味着对所有的应用这都是最好的选择。对于有极端的性能或其他需求的用户，仍需要显式地指定垃圾回收器，并调优某些参数，以达到满意的性能。本文就为这些需求提供了一些相关信息。首先，本文会基于串行的 stop-the-world 垃圾回收器来介绍垃圾回收器的一般性特征和基本调优开关。接下来会介绍其他垃圾回收器的特点和如何选择一个垃圾回收器。何时选择垃圾回收器？对于一些应用，这个答案可能是“永远不”。也就是说，在有低频率、短时的垃圾收集器造成的停顿的情况下，大部分程序都运行良好。不过，这并不适用于很多程序，特别是那些处理大量数据（若干GB）、很多线程和需要处理很多事务的情况。Amdahl 观察到，大部分工作负载并不能被很好的并行化；有部分情况下总是会被顺序执行，无法从并行化中获益。这对 Java? 平台也是如此。特别的，在 J2SE 1.4 以前，Sun Java 平台的虚拟机并不支持并行垃圾回收，这样，在多处理器系统中，垃圾回收会对并行应用产生严重影响。下图显示了一个除了垃圾回收以外均为完美可伸缩的理想系统的性能曲线。红色曲线是一个在但处理器系统中会花费 1% 的时间在垃圾回收上的程序。它在 32 处理器的系统中，将损失 20% 的吞吐量。而一个花费 10% 时间在垃圾回收上的应用（不考虑单处理器系统中额外的垃圾回收时间）在系统扩张到 32 处理器系统中时，会损失超过 75% 的吞吐量 。这意味着在小型开发系统中微不足道的速度问题当扩张到大规模系统中就可能成为严重的性能瓶颈。从另一个角度看，减少这样的性能瓶颈的小改动就可以获得很大的性能收益。对足够大规模的系统，选择合适的垃圾收集器并进行必要调优是绝对值得的。对于大多数“小”应用（在现代处理器上大约需要100MB堆内存的应用）来说通常是足够的。其他垃圾收集器会带来额外的负载或复杂性，这回让系统的某些行为付出一定的代价。如果一个应用不需要一个垃圾收集器的某个功能。那么就使用串行的垃圾收集器好了。一个不应该使用串行垃圾收集器场景是一个超多线程的大程序运行在一个大型的、有大量内存和两个或多个处理器的系统中。当应用运行在这些服务器级的计算机上的时候，并行垃圾收集器会被缺省选择（参见下面的功效学 ）。本文以 Solaris? 操作系统（SPARC(R) 平台版本）中的 Java SE 6 作为参考。不过，文中所述的概念和建议适用于所有支持的平台，包括 Linux, Microsoft Windows 和 Solaris 操作系统（x86 平台版本）。此外，文中的命令行参数也对所有平台有效，虽然它们的缺省值在各个平台可能有所不同。 2. 功效学（Ergonomics）“功效学”是一个 J2SE 5.0 引入的概念。引入功效学概念是为了通过不设置或设置很少的几个命令行参数的情况下提供更好的性能，这些参数包括：垃圾收集器，堆尺寸， 和运行时编译器这里的参数选择假定应用所运行的主机类型和应用的类型一致（也就是说，大型应用运行在大型的机器上）。这些选项简化了垃圾回收的调优。选择并行垃圾回收器，用户可以指定应用的最大中断时间和希望的吞吐量。这和指定堆大小来调优性能是相对应的。最常用的功效学相关的内容在可以参考 “Ergonomics in the 5.0 Java Virtual Machine” 这篇文章。建议在尝试本文提到的细节配置之前尝试该文章中介绍的功效学手段。本文中的功效学特性被作为并行垃圾回收器的自适应尺寸策略的一部分。这包括指定垃圾回收性能的目标和性能调优的一些附加选项。3.代J2SE 平台的优势之一是它将内存分配、垃圾回收这些繁复的细节屏蔽了起来。然而，一旦垃圾回收成为主要的瓶颈，那么理解一下这些隐藏在背后的细节就变得有必要了。垃圾回收器对应用程序对对象的使用方式进行判断，这个判断会反映在可调优参数中，他们可以被调整，以提高性能而不牺牲掉抽象性。 当一个对象不再可能被从其他任何地方访问到的时候就会被认为是垃圾了。最直接的垃圾回收算法就是简单地迭代所有可找