Java5.0垃圾回收性能调优-1、简介，2、Ergonomics工效学[Vange译]

      Introduction 简介

The JavaTM 2 Platform Standard Edition (J2SETM platform) is used for a wide variety of applications from small applets on desktops to web services on large servers. In the J2SE platform version 1.4.2 there were four garbage collectors from which to choose but without an explicit choice by the user the serial garbage collector was always chosen. In version 5.0 the choice of the collector is based on the class of the machine on which the application is started.

自J2SE发布以来应用在了许多方面，小到applet，大到提供各种各样的Web服务大型服务器上。在J2SE1.4.2版本上有四种垃圾回收机制（garbage collector）可以被选择，但这些对使用者并没有提供一个明确的选择说明。默认情况下会选择串行回收。在5.0版本中，对垃圾回收机制的选择是基于应用所在机器的类型。

This “smarter choice” of the garbage collector is generally better but is not always the best. For the user who wants to make their own choice of garbage collectors, this document will provide information on which to base that choice. This will first include the general features of the garbage collections and tuning options to take the best advantage of those features. The examples are given in the context of the serial, stop-the-world collector. Then specific features of the other collectors will be discussed along with factors that should considered when choosing one of the other collectors.

这种“智能选择“机制虽然不是最好的选择，但对于大多数使用都来说是相对比较合适的。对于一些想自行选择回收机制的使用者，这篇文章将提供如何选择的相关知识。这里首先会介绍垃圾回收的一般特性和优化性能的一些选项。而例子也会提供一些关于串行回收机制（serial），停止运行回收机制（stop-the-world）的细节。一些其他回收机制的特性将和选择其他回收机制的影响因素一起介绍。

When does the choice of a garbage collector matter to the user? For many applications it doesn't. That is, the application can perform within its specifications in the presence of garbage collection with pauses of modest frequency and duration. An example where this is not the case (when the serial collector is used) would be a large application that scales well to large number of threads, processors, sockets, and a large amount of memory.

那什么时候垃圾回收机制的选择对于使用者来说很重要呢？事实上，在许多应用上这样做是没有必要的。程序在默认的回收机制下就可以拥有很好的性能，而且默认的回收机制对回收频率和回收时间是非常谨慎的。在大型应用中，对于大量的线程，多处理器，sockets，大型内存的管理性能要求比较严格，这种情况下可以选择串行回收机制，当然这个不是常见的情况。

Amdahl observed that most workloads cannot be perfectly parallelized; some portion is always sequential and does not benefit from parallelism. This is also true for the J2SE platform. In particular, virtual machines for the JavaTM platform up to and including version 1.3.1 do not have parallel garbage collection, so the impact of garbage collection on a multiprocessor system grows relative to an otherwise parallel application.

Amdahl定律（有些问题使用越多的资源就能越快地解决——越多的工人参与收割庄稼，那么就能越快地完成收获。另一些任务根本就是串行化的——增加更多的工人根本不可能提高收割速度。链接 http://blog.csdn.net/Vange/archive/2010/04/22/5517705.aspx ）表明大部分工作量不能很好地并行执行，一些只能串行执行的工作并不能因为并行计算而且提高效率，J2SE平台也面临这样的情况。JVM版本在1.3.1以上已经没有并行回收机制，因为在一些运行在多处理器上的个别并行计算程序里面，并行的垃圾回收机制冲突不断出现。
----------------------------------------------

灰色
的声明:

author:Vange

url:http://blog.csdn.net/Vange

----------------------------------------------

The graph below models an ideal system that is perfectly scalable with the exception of garbage collection. The red line is an application spending only 1% of the time in garbage collection on a uniprocessor system. This translates to more than a 20% loss in throughput on 32 processor systems. At 10% of the time in garbage collection (not considered an outrageous amount of time in garbage collection in uniprocessor applications) more than 75% of throughput is lost when scaling up to 32 processors.

下面的图例是建立在一个理想状态（系统可以自由扩展除了回收机制不变的情况）。红色的线表示JVM调用1％时间来回收垃圾，当处理器达到32个时，将有20％的性（吞吐量）能被损失。紫色的线表示JVM调用10％的时间来执行垃圾回收（不考虑在单处理器情况下占用大量执行时间），当处理器达到32个时，将会有75％的性能（吞吐量）被损失！！



This shows that negligible speed issues when developing on small systems may become principal bottlenecks when scaling up to large systems. However, small improvements in reducing such a bottleneck can produce large gains in performance. For a sufficiently large system it becomes well worthwhile to choose the right garbage collector and to tune it if necessary.

这些数据表明一个在小型系统不引起重视的小性能，当系统变到足够大时，它可能就是瓶颈的所在。所以一个小小的优化有时就可以解决系统的瓶颈并使系统得到更好的性能。对于一个大型系统来说，优化并正确选择一种垃圾回收机制是相当有必要的。

The serial collector will be adequate for the majority of applications. Each of the other collectors have some added overhead and/or complexity which is the price for specialized behavior. If the application doesn't need the specialized behavior of an alternate collector, use the serial collector. An example of a situation where the serial collector is not expected to be the best choice is a large application that is heavily threaded and run on hardware with a large amount of memory and a large number of processors. For such applications, we now make the choice of the throughput collector (see the discussion of ergonomics in section 2).

串行回收机制对于大部分应用来说已经足够，但其他的各种回收机制也有各自独到之处，不过相应的代值是需要处理复杂的大量的和/或操作。如果应用程序不需要专门的垃圾回收机制，建议还是用串行垃圾回收机制。如果当一个大型程序要管理大量的线程，运行在多处理器和大内存的环境下，串行回收机制并不是很好的选择。理解了这些，我们才可以进一步进行选择我们需要的垃圾回收机制（参看Ergonomics（工效学、人机工程学）的第二节）。

This document was written using the J2SE Platform version 1.5, on the SolarisTM Operating System (SPARC(R) Platform Edition) as the base platform, because it provides the most scalable hardware and software for the J2SE platform. However, the descriptive text applies to other supported platforms, including Linux, Microsoft Windows, and the Solaris Operating System (x86 Platform Edition), to the extent that scalable hardware is available. Although command line options are consistent across platforms, some platforms may have defaults different than those described here.

此文章所描述的情况是建立Solaris (SPARC(R) Platform Edition) 操作系统的J2SE1.5上。因为该操作系统可以自由扩展硬件及软件来测试J2SE平台。当然，文章所描述的情况也适应其他的可扩展硬件的操作系统，包括Linux、Windows、Solaris（X86架构）。而且对于命令行所使用的选项在跨平台方面保持一致，尽管一些系统的默认选择会有些不一样。

Ergonomics

Ergonomics 性能优化（工效学、人机工程学：参照其他文章的译法，下面译文保持原文单词。什么意思靠个人理解，防止误导）

New in the J2SE Platform version 1.5 is a feature referred to here as ergonomics. The goal of ergonomics is to provide good performance from the JVM with a minimum of command line tuning. Ergonomics attempts to match the best selection of

在J2SE1.5里面有一个特性是ergonomics。ergonomics的加入是为了借助少量的命令行来调优JVM更好的性能，主要包括以下方面：

    *

      Garbage collector 垃圾回收器

    *

      Heap size 堆内存

    *

      Runtime compiler  动态编译器（类似JSP的动态编译呢？其他的呢？）

for an application. This selection assumes that the class of the machine on which the application is run is a hint as to the characteristics of the application (i.e., large applications run on large machines). In addition to these selections is a simplified way of tuning garbage collection. With the throughput collector the user can specify goals for a maximum pause time and a desired throughput for an application. This is in contrast to specifying the size of the heap that is needed for good performance. This is intended to particularly improve the performance of large applications that use large heaps. The more general ergonomics is described in the document entitled “Ergonomics in the 1.5 Java Virtual Machine”. It is recommended that the ergonomics as presented in this latter document be tried before using the more detailed controls explained in this document.

对于一般的程序，性能优化ergonomics会自动识别所运行的机器类型，并以此来作为性能调优的默认选项（原因：大型机器跑的一般是大型程序。呵呵），性能自动调优包括以下方面：一、垃圾回收机制会根据机器特性来设置。二、借助吞吐量回收器（throughput collector），用户可以指定程序在一定的中止时间（垃圾回收机制中止程序）以及保证一定的吞吐量。三、指定程序的堆内存大小（对于大程序来说，增加堆内存大小是简单有效的优化方案）。除了上面所说，还有更多的性能优化方法可以参看文章“Ergonomics in the 1.5 Java Virtual Machine”。 本文章除了参看文章所提及的会在这里一一说明，还会介绍更多优化的细节。

 

==========================================

时间方面,翻译还没有完成,待续.