Document options Print this page E-mail this page Document options requiring JavaScript are not displayed New site feature Plan and design IT solutions with our new Architecture area Rate this page Help us improve this content

Level: Intermediate

Amit Mathur (amitmat@us.ibm.com), Senior Technical Consultant and Solutions Enablement Manager, IBM
Sumit Chawla (sumitc@us.ibm.com), IBM Certified IT Architect and Technical Lead, Java Enablement, IBM

17 May 2004

This is the conclusion of the 5-part series providing tips and techniques that are commonly used for tuning Java™ applications for optimum performance on AIX®. We touch upon other interesting areas of Java performance tuning for AIX, look at a few case studies, and then end the series with a list of useful references.

Introduction

This is the conclusion of the 5-part series on Java Performance.The first article in the series laid the foundation for performance tuning, and parts 2, 3 and 4 looked at various bottlenecks that can affect a system's scalability and throughput. This article covers two important topics that were not covered previously, along with providing case studies and references.

A frequently asked question (FAQ) is about translating Sun-specific command-line switches to IBM-specific switches. Also, any serious performance tuning exercise, like benchmarks, cannot ignore system-wide tuning. We touch upon these topics briefly in the next section.

This is followed by a few case studies that attempt to illustrate how the tools and tips described in the series are applied to solve problems in the field. The emphasis is on understanding and learning how to use the tools and techniques mentioned in the series.

The article, and the series, concludes with a recap of useful references.

Back to top

Other Important Considerations

This section talks about translating Sun Java configuration to IBM Java configuration, and System-wide tuning for AIX applications. The scope of both of these topics is quite vast, so we only touch them briefly.

Translating Sun Java Switches

If you have an application that has been tuned for Sun Java, and you are attempting to migrate your application to AIX (or, for that matter, any platform running IBM Java), you may already have done the hard work. Understanding the application characteristics is half the battle. You can use the characteristics-based tuning tips explained in Part 2 and Part 3 based on the understanding obtained by the tuning exercise with Sun Java.

However, we frequently receive queries about how to translate specific Sun Java command-line switches to equivalent IBM Java command-line switches. These switches almost always correspond to Garbage Collection, as a well-tuned GC is essential to any Java-based application's performance. A mapping between Sun and IBM switches is difficult because of the difference in JVM architecture. The IBM Java does not contain a Generational Garbage Collector, and does not understand any command-line switches that start with -XX. IBM Java "Sovereign" architecture is not based on Sun HotSpot architecture as well. The easiest, and in most cases the quickest, way is to throw away all Sun-specific settings when running your application on IBM Platforms, and carrying out the fine-tuning as needed. But if you are curious about how some Sun switches map to IBM switches, read on.

The table below attempts to translate Sun Java GC command-line switches to equivalent IBM switches. This mapping is based on the functionality of Sun switches as described in the Sun-specific article "Tuning Garbage Collection with the 1.4.2 Java Virtual Machine". You should attempt to use this table only for the very specific purpose of locating an equivalent (or close) switch for IBM Java. This is not meant to replace the tuning exercise, as even heap size requirements can be quite different. For general GC tuning tips with IBM Java, as well as for information on these and other GC switches for IBM Java, please refer to Fine-tuning Java garbage collection performance. The creation of this table did not involve any performance-related testing, but was based entirely on the documented use of the Sun switches in the reference quoted above.

As the above table demonstrates, translating the switches in most cases will involve simply discarding the Sun switches for IBM platforms. This makes the GC tuning exercise for IBM Java quite painless, while still providing superior performance.

System-wide tuning

Using AIX tools like schedo and vmo has a system-wide effect, so a thorough coverage of these tools is beyond the scope of the current series. See the Resources section for more information on these tools.

But for most multi-tiered applications and especially benchmarks, system-wide tuning is unavoidable. There are several excellent resources available for AIX performance tuning that you can consider. To get an idea of the kind of tuning normally required, you can look at actual published benchmarks. If you look at a recent SpecJBB 2000 result for IBM Java on AIX, say http://www.spec.org/osg/jbb2000/results/res2003q3/jbb2000-20030624-00194.html, the OS tunings are mentioned below:

Operating system tunings SPINLOOPTIME=2000 vmo -r -o lgpg_regions=256 -o lgpg_size=16777216 setsched -S rr -P 40 -p $$ schedtune -t 400 -F 1 vmtune -S 1

Warning: These settings must not be applied without carefully understanding the consequences, as an improper use of these settings can actually worsen the system performance.

So what do the above settings do? Referring to AIX documentation, you can quickly get a better understanding of what each of these settings is doing. Let us examine each of these in turn.

The SPINLOOPTIME controls the number of times the system will retry a busy lock before yielding to another process. Since the default is 40, a higher value tells the system that it should try a little bit longer for the lock to be freed up. On multiprocessor systems, it results in better performance since a busy lock retry is cheaper than a process context switch.

The vmo line sets up the size and number of large pages. If you look at the Java command-line switches, you will see that -Xlp is being used. This enables Large page support in Java, which is described in more detail here. If you have a memory intensive application, you can experiment with large pages to see if it helps. More information on this topic is available in the SDK Guide accompanying Java.

The setsched line is actually a script, not an AIX command. It calls the thread_setsched kernel service to select fixed-priority round-robin scheduling, with a fixed priority of 40 for the Java process.

The schedtune command is also a script from AIX 5.2 onwards, that maps the passed parameters to the new schedo command. The above line is changing the time slice for fixed-priority threads to 400 ticks. It is also forcing the fixed priority threads to reside in the global run queue.

Finally, the vmtune command translates the call to an equivalent vmo call, and the above line enables pinning of shared memory segments.

So you can see that the system was switched to large pages and a fixed priority scheduler, to get record numbers with SpecJBB 2000 benchmark. Can you use these same settings in your application? Probably not, but you are now in a position to examine these commands and the scheduling policies, and experiment to suit your application characteristics. This is the next step in Performance tuning.

Back to top

Case Studies

In this section we look at a few examples, taken from actual issues handled by Java service team. These examples should give you a good idea of how to approach performance tuning, and how to use various tools to gather information that can be used for tuning exercise. Note that the cases for this section were not chosen based on how frequently the problem is encountered in the field. The emphasis is on understanding how to use the various tools and techniques discussed in the series to locate and correct performance issues.

Case 1: Bad application response time

The reported issue was that the Java-based application's response time was unacceptable. Using topas, and then with vmstat, it was seen that Java was the application consuming most CPU. Using tprof, the functions that showed up had GC-related terms in them (e.g. localMark, which is used in Mark phase), so this indicated a possible issue with Java heap sizing.

Looking at GC logs confirmed that the heap was expanding very often. This, combined with multiple allocation failures in quick succession and a very full heap, resulted in the Java application spending a lot of time just trying to locate a free chunk, not finding it, expanding the heap, and then satisfying only the current allocation request.

This was fixed by specifying a larger value for -Xmine, forcing the heap to grow faster (seeTip MEM003 in Part 3). The result was that a single expansion avoided multiple potential allocation failures.

The first step, using AIX tools, confirmed this to be a Java-related issue. The second step, guided by the fact that AIX tools indicated this to be a problem related with GC, could concentrate on GC logs directly. The third step used the available tuning parameters to break the unusual cycle that the application was getting into, allowing the excessive CPU time to be recovered.

Case 2: JVMPI to the rescue

Another interesting scenario was raised as a performance issue, with CPU being busy most of the time. Looking at verbosegc, we could see that a GC cycle was being called a bit too frequently, resulting in the application spending most of its time doing just GC.

The verbosegc traces showed that most of the GC activity was being caused due to multiple allocations of very large objects, roughly 10 MB or more in size. These were fragmenting the heap, making the GC cycles longer and thus affecting the performance. But looking at the verbosegc cycle, the customer could not say what these objects were.

The easiest way to locate the culprit would have been to analyze the heapdump using HeapRoots tool. But there was another twist to the situation: the large objects were not surviving the GC cycle. So the heapdump did not show any objects of such size.

This is a classic example of how profiling can be a very useful ally for locating and correcting problems in application sources. The Java Virtual Machine Profile Interface makes this problem trivial. For this particular example, we used a variation of the method described at Using JVMPI to Identify Large Memory Allocations, and were able to quickly identify the code that was doing this allocation.

Case 3: Unbounded growth

As the final case study for this article, we discuss a scenario that showed up looking like a simple sizing problem. An attempt was being made to scale the application to a 1000 users, and the application would run out of Java heap. Calculating the heap requirements based on the number of users, the heap size was increased from 1 GB to 1.5 GB.

But this triggered OOM errors not coming because of Java heap. The Java heap would show enough free space, but the application logs would show that an OOM occurred. Using svmon, it was seen that only around 4 segments, or 1 GB, were being used for native heap, and the fourth segment seemed to be almost empty (see "Balancing Memory" in "Getting more memory in AIX for your Java applications").

To dig further, the command-line switch -verbose:jni was added. The extra messages being printed as a result of this switch revealed that the global JNI reference pool was getting exhausted, which is a very rare thing to happen. The global JNI reference pool is large enough to ensure that most normal applications never run even close to exhausting it.

For some time we tried to work around the problem by increasing the number of JNI references (if you specify a higher -Xoss value, it increases the limit in a proportional manner). But this only delayed the inevitable, and the severe Java heap fragmentation caused by the large number of pinned JNI references did not help either.

A closer look at the application design revealed the true cause: an unbounded number of threads being created by the application. As the tests proceeded, the threads would wait for finalizers, and since finalizers are not predictable, there would be a large number of these threads waiting to release their JNI references. The only feasible solution in this case was to change the application code to correct these two problems. Once the application replaced the unbounded threads with a thread pool, and replaced finalizers wherever possible, the sizing work completed with flying colors.

This case shows how you can sometimes end up trying to hit a moving target. An issue reported as Java heap exhaustion eventually turned out to be a design problem. Balancing the Java and Native heaps is usually a critical part of performance tuning, but in this case it was not sufficient. Having so many tools and techniques at your disposal gives you a much broader picture, allowing you to make informed decisions about what to tune.

Back to top

Conclusion

This article concludes the series. We hope you find this series a valuable guide in maximizing the performance of your Java applications on AIX.

The authors thank Ashok Ambati, Rajesh Jeyapaul, Sharad Ballal, Roger Leuckie and Mark Bluemel for their input and advice on these articles. A special note of thanks goes to John Tesch, whose collection of information on AIX Java performance was a major source of inspiration to the series.

Back to top

Resources

• The IBM developer kits for AIX, Java technology edition, at http://www-106.ibm.com/developerworks/java/jdk/aix/service.html, contains links to all available Java releases on AIX. The SDK Guide for each version contains information relevant to the release and should be reviewed before you use that particular version. Another useful link is "Fix Info" link that, among other things, gives you a list of APARs you will need to apply to update all the filesets to the latest level.
  
  
• The IBM developer kits - diagnosis documentation, at http://www-106.ibm.com/developerworks/java/jdk/diagnosis/, is a comprehensive document that provides thorough coverage of diagnostic capabilities of IBM Java. Best of all, it is platform-independent, so you can use it for all platforms that IBM Java runs on. A recent addition on this page is the "IBM Garbage Collection and Storage Allocation Techniques", a detailed look at how IBM Java implements Garbage Collection and is a must-read for anyone interested in finding out more about how IBM Java works.
  
  
• Implementing Java on AIX (developerworks, March 2004), at http://www-106.ibm.com/developerworks/eserver/library/es-JavaOnAix_install.html, contains information you need to start using Java on AIX.
  
  
• Since GC tuning is usually the most important part of performance tweaking, see Fine-tuning Java garbage collection performance (developerworks, January 2003), at http://www-106.ibm.com/developerworks/library/i-gctroub/, for a discussion of tweaking IBM Java heap characteristics. Note that this article is not AIX-specific. Parts 2 and 3 of the current series also look at some tips useful for GC tuning.
  
  
• Getting more memory in AIX for your Java applications (developerworks, September, 2003), at http://www-106.ibm.com/developerworks/eserver/articles/aix4java1.html, provides information for heaps larger than 1 GB.
  

• AIX 5L Performance Tools Handbook at http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/SG246039.html, covers each of the performance tools described in the current series (plus many more that are not). You will find practical advice on how to use a particular tool, examples of tool usage, and hints on how to interpret and use the information obtained using these tools.
  
  
• Understanding IBM eServer pSeries Performance and Sizing at http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/SG244810.html, gives an overview of how IBM AIX-based systems are designed. If you are planning to do a benchmark exercise, this book is invaluable.
  
  
• A series of three articles that talk about the changes to Performance tools in AIX 5.2 are Part 1 (developerworks, July 2003), Part 2 (developerworks, November 2003), and Part 3 (developerworks, January 2004. AIX 5.2 did a major overhaul of some of the familiar performance tools and this series covers the changes very well.
  
  
• The AIX Performance PMR Data Collection Tools, described in Part 1, can be downloaded from ftp://ftp.software.ibm.com/aix/tools/perftools/perfpmr/
  
  
• Checklist for isolating Java performance problems on AIX servers at http://www-106.ibm.com/developerworks/java/library/j-perf-checklist/
  

Back to top

About the authors

Amit Mathur works in the IBM Solutions Development group, working primarily with IBM ISVs in enablement/performance of their apps on IBM eServer platforms and providing self-sufficiency to ISVs and customers by providing education and articles on developer works. Amit has more than fourteen years' experience working in Leading software support and development in C/C++, Java and databases on UNIX and Linux platforms. He holds a Bachelor of Engineering degree in Electronics and Telecommunication from India. You can reach Amit at amitmat@us.ibm.com.

Sumit Chawla leads the Java Enablement initiative for IBM eServer (for AIX, Windows, and Linux platforms), assisting Independent Software Vendors for IBM Servers. Sumit has a Master of Science degree in Computer Science, with almost 10 years of experience in the IT industry, and is certified by IBM as an Application Architect. He is a frequent contributor to the developerWorks eServer zone. You can contact him at sumitc@us.ibm.com.

文档选项 将此页作为电子邮件发送 未显示需要 JavaScript 的文档选项 对此页的评价 帮助我们改进这些内容

级别: 初级

Brian Goetz, 首席顾问, Quiotix Corp

2003 年 12 月 01 日

在上月的 Java 理论与实践中，专栏作家 Brian Goetz 回顾了垃圾收集的基本算法。本月，他进一步探讨 JVM 1.4.1 是如何实际处理垃圾收集的，包括一些针对多处理器系统的新垃圾收集选项。请在本文对应的 讨论论坛上与作者及其他读者分享您对本文的心得（您也可以单击文章顶部或底部的 讨论来访问该论坛）。

上个月，我们分析了引用计数、复制、标记-清除和标记-整理这些经典的垃圾收集技术。其中每一种方法在特定条件下都有其优点和缺点。例如，当有很多对象成为垃圾时，复制可以做得很好，但是有许多长寿对象时它就变得很糟（要反复复制它们）。相反，标记-整理对于长寿对象可以做得很好（只复制一次），但是当有许多短寿对象时就没有那么好了。JVM 1.2 及以后版本使用的技术称为 分代垃圾收集（generational garbage collection）,它结合了这两种技术以结合二者的长处，结果就是对象分配开销非常小。

老对象和年轻对象

在任何一个应用程序堆中，一些对象在创建后很快就成为垃圾，另一些则在程序的整个运行期间一直保持生存。经验分析表明，对于大多数面向对象的语言，包括 Java 语言，绝大多数对象――可以多达 98%（这取决于您对年轻对象的衡量标准）是在年轻的时候死亡的。可以用时钟秒数、对象分配以后�h内存管理子系统分配的总字节或者对象分配后经历的垃圾收集的次数来计算对象的寿命。但是不管您如何计量，分析表明了同一件事――大多数对象是在年轻的时候死亡的。大多数对象在年轻时死亡这一事实对于收集器的选择很有意义。特别是，当大多数对象在年轻时死亡时，复制收集器可以执行得相当好，因为复制收集器完全不访问死亡的对象，它们只是将活的对象复制到另一个堆区域中，然后一次性收回所有的剩余空间。

那些经历过第一次垃圾收集后仍能生存的对象，很大部分会成为长寿的或者永久的对象。根据短寿对象和长寿对象的混合比例，不同垃圾收集策略的性能会有非常大的差别。当大多数对象在年轻时死亡时，复制收集器可以工作得很好，因为年轻时死亡的对象永远不需要复制。不过，复制收集器处理长寿对象却很糟糕，它要从一个半空间向另一个半空间反复来回复制这些对象。相反，标记-整理收集器对于长寿对象可以工作得很好，因为长寿对象趋向于沉在堆的底部，从而不用再复制。不过，标记-清除和标记-理整收集器要做很多额外的分析死亡对象的工作，因为在清除阶段它们必须分析堆中的每一个对象。

回页首

分代收集

分代收集器(generializational collector)将堆分为多个代。在年轻的代中创建对象，满足某些提升标准的对象，如经历了特定次数垃圾收集的对象，将被提升到下一更老的代。分代收集器对不同的代可以自由使用不同的收集策略，对各代分别进行垃圾收集。

小的收集

分代收集的一个优点是它不同时收集所有的代，因此可以使垃圾收集暂停更短。当分配器不能满足分配请求时，它首先触发一个 小的收集（minor collection），它只收集最年轻的代。因为年轻代中的许多对象已经死亡，复制收集器完全不用分析死亡的对象，所以小的收集的暂停可以相当短并通常可以回收大量的堆空间。如果小的收集释放了足够的堆空间，那么用户程序就可以立即恢复。如果它不能释放足够的堆空间，那么它就继续收集上一代，直到回收了足够的内存。（在垃圾收集器进行了全部收集以后仍不能回收足够的内存时，它将扩展堆或者抛出 OutOfMemoryError ）。

代间引用

跟踪垃圾收集器，如复制、标记-清除和标记-整理等垃圾收集器,都是从根集（root set）开始扫描，遍历对象间的引用，直到访问了所有活的对象。

分代跟踪收集器从根集开始，但是并不遍历指向更老一代中对象的引用，这减少了要跟踪的对象图的大小。但是这也带来一个问题――如果更老一代中的对象引用一个不能通过从根开始的所有其他引用链到达的更年轻的对象该怎么办？

为了解决这个问题，分代收集器必须显式地跟踪从老对象到年轻对象的引用并将这些老到年轻的引用加入到小的收集的根集中。有两种创建从老对象到年轻对象的引用的方法。要么是将老对象中包含的引用修改为指向年轻对象，要么是将引用其他年轻对象的年轻对象提升为更老的一代。

跟踪代间引用

不管一个老到年轻的引用是通过提升还是指针修改创建的，垃圾收集器在进行小的收集时需要有全部老到年轻的引用。做到这一点的一种方法是跟踪老的代，但是这显然有很大的开销。更好的一种方法是线性扫描老的代以查找对年轻对象的引用。这种方法比跟踪更快并有更好的区域性（locality），但是仍然有很大的工作量。

赋值函数（mutator）和垃圾收集器可以共同工作以在创建老到年轻的引用时维护它们的完整列表。当对象提升为更老一代时，垃圾收集器可以记录所有由于这种提升而创建的老到年轻的引用，这样就只需要跟踪由指针修改所创建的代间引用。

垃圾收集器可以有几种方法跟踪由于修改现有对象中的引用而产生的老到年轻的引用。它可以使用在引用计数收集器中维护引用计数的同样方法（编译器可以生成围绕指针赋值的附加指令）跟踪它们，也可以在老一代堆上使用虚拟内存保护以捕获向老对象的写入。另一种可能更有效的虚拟内存方法是在老一代堆中使用页修改脏位（page modification dirty bit），以确定为找到包含老到年轻指针的对象时要扫描的块。

用一点小技巧，就可以避免跟踪每一个指针修改并检查它是否跨越代边界的开销。例如，不需要跟踪针对本地或者静态变量的存储，因为它们已经是根集的一部分了。也可以避免跟踪存储在某些构造函数中的指针，这些构造函数只用于初始化新建对象的字段（即所谓 初始化存储（initializing stores）），因为（几乎）所有对象都是分配到年轻代中。不管是什么情况，运行库都必须维护一个老对象到年轻对象的引用集并在收集年轻代时将这些引用添加到根集中。

在图 1 中，箭头表示堆中对象间的引用。红色箭头表示必须添加到根集中供小的收集使用的老到年轻的引用。蓝色箭头表示从根集或者年轻代到老对象的引用，在只收集年轻代时不需要跟踪它们。

卡片标记

Sun JDK 使用一种称为 卡片标记（card marking）算法的改进算法以标识对老一代对象的字段中包含的指针的修改。在这种方法中，堆分为一组 卡片，每个卡片一般都小于一个内存页。JVM 维护着一个卡片映射，对应于堆中的每一个卡片都有一个位（在某些实现中是一个字节）。每次修改堆中对象中的指针字段时，就在卡片映射中设置对应那张卡片的相应位。在垃圾收集时，就对与老一代中卡片相关联的标记位进行检查，对脏的卡片扫描以寻找对年轻代有引用的对象。然后清除标记位。卡片标记有几项开销――卡片映射所需的额外空间、对每一个指针存储所做的额外工作，以及在垃圾收集时做的额外工作。对每一个非初始化堆指针存储，卡片标记算法可以只增加两到三个机器指令，并要求在小的收集时对所有脏卡片上的对象进行扫描。

回页首

JDK 1.4.1 默认收集器

在默认情况下，JDK 1.4.1 将堆分为两部分，一个年轻的代和一个老的代（实际上，还有第三部分――永久空间，它用于存储装载的类和方法对象）。借助于复制收集器，年轻的代又分为一个创建空间（通常称为 Eden）和两个生存半空间。

老的代使用标记-整理收集器。对象在经历了几次复制后提升到老的代。小的收集将活的对象从 Eden 和一个生存半空间复制到另一个生存半空间，并可能提升一些对象到老的代。大的收集（major collection）既会收集年轻的代，也会收集老的代。 System.gc() 方法总是触发一个大的收集，这就是应该尽量少用（如果不能完全不用的话） System.gc() 的原因之一，因为大的收集要比小的收集花费长得多的时间。没有办法以编程方式触发小的收集。

其他收集选项

除了默认情况下使用的复制收集器和标记-整理收集器，JDK 1.4.1 还包含其他四种垃圾收集算法，每一种适用于不同的目的。JDK 1.4.1 包含一个增量收集器（自 JDK 1.2 就已经出现了）和三种在多处理器系统中进行更有效收集的新收集器――并行复制收集器、并行清除（scavenging）收集器和并发标记-清除收集器。这些新收集器是为了解决在多处理器系统中垃圾收集器成为伸缩性瓶颈这一问题的。图 2 显示了在什么时候选择备用收集选项的指导。

增量收集

增量收集选项自 1.2 起就成为 JDK 的一部分。增量收集减少了垃圾收集暂停，以牺牲吞吐能力为代价，这使它只在更短的收集暂停非常重要时才值得考虑，如接近实时的系统。

Train算法是 JDK 用于增量收集的算法，它在堆中老的代和年轻的代之间创建一个新区域。这些堆区域划分为“火车（train）”，每个火车又分为一系列的“车厢（car）”。每个车厢可以分别收集。结果，每个火车车厢组成单独的一代，这意味着不但要跟踪老到年轻的引用，而且还要跟踪从老的火车到年轻的火车以及老的车厢到年轻的车厢的引用。这为赋值函数（mutator）和垃圾收集器带来了大量的额外工作，但是可以得到更短的收集暂停。

并行收集器和并发收集器

JDK 1.4.1 中新的收集器都是为解决多处理器系统中垃圾收集器的问题而设计的。因为大多数垃圾收集算法会在一段时间里使系统停止，单线程的收集器很快会成为伸缩性瓶颈，因为在垃圾收集器将用户程序线程挂起时，除了一个处理器之外，其他的处理器都是空闲的。新收集器中的两个――并行复制收集器和并发标记-清除收集器――设计为减少收集暂停时间。另一个是并行清除收集器，它是为在大堆上的更高吞吐能力而设计的。

并行复制收集器用 JVM 选项 -XX:+UseParNewGC 启用，是一个年轻代复制收集器，它将垃圾收集的工作分为与 CPU 数量一样多的线程。并发标记-清除收集器由 -XX:+UseConcMarkSweepGC 选项启用，它是一个老代标记-清除收集器，它在初始标记阶段（及在以后暂短重新标记阶段）暂短地停止整个系统，然后恢复用户程序，同时垃圾收集器线程与用户程序并发地执行。并行复制收集器和并发标记-清除收集器基本上是默认的复制收集器和标记-整理收集器的并发版本。由 -XX:+UseParallelGC 启用的并行清除收集器是年轻代收集器，针对多处理器系统上非常大(吉字节以及更大的)堆进行了优化。

选择一种算法

有六种算法可以选择，您可能不知道要使用哪一种。 图 2提供了一些指导，将收集器分为单线程和并发的，以及分为短暂停和高吞吐能力的。只要您掌握了应用程序和部署环境的信息，就足以选择合适的算法。对于许多应用程序，默认的收集器可以工作得很好――因此如果您没有性能问题，那么就没必要加入更多的复杂性。不过，如果您的应用程序是部署在多处理器系统上或者使用非常大的堆，那么改变收集器选项可能会有巨大的性能提升。

回页首

微调垃圾收集器

JDK 1.4.1 还包括大量的微调垃圾收集的选项。调整这些选项并衡量它们的效果可能会花费您大量时间，因此在试图微调垃圾收集器之前先对您的应用程序进行彻底的配置（profile）和优化，这样您的微调工作可能会得到更好的结果。

微调垃圾收集首先要做的是检查冗长的 GC 输出。这会使您得到垃圾收集操作的频率、定时和持续时间等信息。最简单的垃圾收集微调就是扩大最大堆的大小（ -Xmx ）。随着堆的增大，复制收集会变得更有效，所以在增大堆时，您就减少了每个对象的收集成本。除了增加最大堆的大小，还可以用选项 -XX:NewRatio 增加分配给年轻代的空间份额。也可以用 -Xmn 选项显式指定年轻代的大小。有关微调垃圾收集的更多细节请参阅 参考资料中的几篇文章。

回页首

结束语

随着 JVM 的发展，默认垃圾收集器变得越来越好了。JDK 1.2 及以后版本所使用的分代垃圾收集器提供了比早期 JDK 所使用的标记-清除-整理收集器好得多的分配和收集性能。JDK 1.4.1 通过增加新的针对多处理器系统和非常大的堆的多线程收集选项，进一步改进了垃圾收集的效率。

下个月，我们将讨论一些有关垃圾收集的性能神话（hints and myths），包括对象分配的真实成本、显式赋空的代价和好处以及结束（finalization）的代价，以此来完成我们对垃圾收集的探讨。

回页首

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 请在 讨论论坛上参与本文的讨论。（您也可以通过单击文章顶部或底部的 讨论来访问该论坛。）
  
  
  
• 阅读 Brian Goetz 的全部 Java 理论与实践 系列。
  
  
  
• Garbage Collection: Algorithms for Automatic Dynamic Memory Management （John Wiley & Sons， 1997 年）是对垃圾收集算法的全面评述，包括大量参考书目。作者 Richard Jones 在其 垃圾收集页上维护着一个接近 2000 页的不断更新的参考书目。
  
  
  
• 垃圾收集邮件列表上有一个 垃圾收集常见问题。
  
  
  
• 针对 Java 平台的 IBM 1.4 Developer Kits 使用了标记-清除-整理收集器，它支持 增量整理以减少暂停时间。
  
  
  
• 包括三篇文章的“ Sensible sanitation -- Understanding the IBM Java Garbage Collector”系列（ developerWorks，2002 年 8 月 - 9 月）描述了针对 Java 平台的 IBM 1.2 和 1.3 Developer Kits 使用的垃圾收集策略。
  
  
  
• “ Fine-tuning Java garbage collection performance”（ developerWorks，2003 年 1 月）描述了如何发现和排除垃圾收集问题。
  
  
  
• IBM Systems Journal的这篇文章描述了构建针对 Java 平台的 IBM 1.1.x Developer Kits 时得到的一些 经验，包括标记-清除和标记-清除-整理垃圾收集的细节。
  
  
  
• Sun 的这篇文档提供了 对垃圾收集性能微调过程的介绍。
  
  
  
• 引用对象，如 WeakReference 和 SoftReference ，加入了对确定对象是否可以被垃圾收集的额外考虑。
  
  
  
• GC Portal是一组跟踪您应用程序的垃圾收集性能的工具。
  
  
  
• Sun 的这篇文章描述了 Sun JVM 中的垃圾收集以及微调选项，并说明了如何解释 verbose GC 输出。
  
  
  
• 在其论文“ A fast write barrier for generational garbage collectors”中，Urs Hoeltze 讨论了经典的卡片-标记算法以及通过稍微增加收集时扫描脏卡片的成本而显著减少标记成本的一个改进。
  
  
  
• 文中 图 2所示的图是由 Folgmann IT-Consulting提供的。
  
  
  
• 这篇文章描述了 火车增量垃圾收集算法的细节。
  
  
  
• 在 developerWorksJava 技术专区 可找到数百篇有关 Java 技术的参考资料。
  
  

回页首

关于作者

	Brian Goetz 在过去 15 年间一直从事专业软件开发。他是 Quiotix的首席顾问，该公司是一家位于加利福尼亚州洛斯拉图斯（Los Altos）的软件开发和咨询公司，他也是几个 JCP 专家组的成员。请参阅流行的业界出版物中 Brian 已经 发表和即将发表的文章。您可以通过 brian@quiotix.com与 Brian 联系。

文档选项 将此页作为电子邮件发送 未显示需要 JavaScript 的文档选项 对此页的评价 帮助我们改进这些内容

级别: 初级

Sumit Chawla, 技术主管，eServer Java Enablement, IBM

2003 年 1 月 01 日

您的 Java 应用程序充分利用了所运行的 IBM eServer 硬件的能力了吗？在本文中，作者将介绍如何判断垃圾收集 —— Java 虚拟机执行的收回不再使用空间的后台任务 —— 是否调节到最佳状态。然后，他将提供一些解决垃圾收集问题的建议。

简介

垃圾收集实现是 IBM Java Virtual Machine（JVM）卓越性能的关键。其他多数 JVM 都需要大量调整才能提供最优性能，而 IBM JVM 利用其“开箱即用”的默认设置，在多数情况下都能工作得很好。但是在某些情况下，垃圾收集的性能会莫名其妙地迅速降低。结果可能导致服务器没有响应、屏幕静止不动或者完全失效，并常常伴有“堆空间严重不足”这类含糊的消息。幸运的是，多数情况下都很容易找到原因，通常也很容易纠正错误。

本文将介绍如何确定造成性能下降的潜在原因。因为垃圾收集是一个很大、很复杂的话题，所以本文是在已经发表的一组相关文章的基础上展开讨论（请参阅参考资料）。虽然本文讨论的多数建议都将 Java 程序看作是一个黑盒子，但仍然有一些观点可以在设计或编码时运用，以避免潜在的问题。

本文提供的信息适用于所有 IBM eServer 平台，除了可重新设置的 JVM 配置（请参阅参考资料）。除非特别说明，文中的例子都取自运行在四处理器 AIX 5.1 上的 Java 1.3.1 build ca131-20020706。

回页首

堆管理概述

JVM 在初始化的过程中分配堆。堆的大小取决于指定或者默认的最小和最大值以及堆的使用情况。分配堆可能对可视化堆有所帮助，如图 1 所示，其中显示了 heapbase、heaplimit 和 heaptop。

Heapbase 表示堆底，heaptop 则表示堆能够增长到的最大绝对值。差值（heaptop - heapbase）由命令行参数 -Xmx 决定。该参数和其他命令行参数都是在关于 verbosegc 和命令行参数的 developerWorks 文档中描述的。heaplimit 指针可以随着堆的扩展上升，随着堆的收缩下降。heaplimit 永远不能超过 heaptop，也不能低于使用 -Xms 指定的初始堆大小。任何时候堆的大小都是 heaplimit - heapbase。

如果整个堆的自由空间比例低于 -Xminf 指定的值（minf 是最小自由空间），堆就会扩展。如果整个堆的自由空间比例高于 -Xmaxf 指定的值（maxf 是最大自由空间），堆就会收缩。-Xminf 和 -Xmaxf 的默认值分别是 0.3 和 0.6，因此 JVM 总是尝试将堆的自由空间比例维持在 30% 到 60% 之间。参数 -Xmine（mine 是最小扩展大小）和 -Xmaxe（maxe 是最大扩展大小）控制扩展的增量。这 4 个参数对固定大小的堆不起作用（用相等的 -Xms 和 -Xmx 值启动 JVM，这意味着 HeapLimit = HeapTop），因为固定大小的堆不能扩展或收缩。

当 Java 线程请求存储时，如果 JVM 不能分配足够的存储块来满足这个请求，则可以说出现了分配失败（AF）。这时候就不可避免要进行垃圾收集。垃圾收集包括收集所有“不可达的（unreachable）”引用，以便重用它们所占用的空间。垃圾收集由请求分配的线程执行，是一种 Stop-The-World（STW）机制；执行垃圾收集算法时，Java 应用程序的其他所有线程（除了垃圾收集帮助器线程之外）都被挂起。

IBM 实现使用称为 mark-sweep-compact（MSC）的垃圾收集算法，它是根据三个不同的阶段命名的。

标记

表和所有“可达的”或者活动的对象。这个阶段从确定“根”开始，比如线程栈上的对象、Java Native Interface（JNI）局部引用和全局引用等，然后沿着每个引用进行递归，直到所有的引用都做上标记。

清理

清除所有已经分配但没有标记的对象，收回这些对象使用的空间。

压缩

将活动对象移动到一起，去掉堆中的空洞（hole）和碎片。

关于 MSC 算法的细节，请参阅参考资料。

并行和并发

虽然垃圾收集本身采用 STW 机制，但最新的 IBM JVM 版本都在多处理器机器上使用多个“帮助器”线程，以便减少每个阶段所花费的时间。因此，在默认情况下，JVM 1.3.0 在标记阶段采用并行模式。JVM 1.3.1 在标记和清理阶段都采用并行模式，在标记阶段还支持一种可选的并发模式，可以使用命令行开关 -Xgcpolicy:optavgpause 切换。撰写本文时，最新版本的 JVM 1.4.0 中有一种递增压缩模式，它并行化了（parallelize）压缩阶段。讨论这些模式时，重要的是要理解并行和并发的区别。

在拥有 N 个 CPU 的多处理器系统中，支持并行模式的 JVM 在初始化的时候会启动 N-1 个垃圾收集帮助器线程。运行应用程序代码的时候，这些线程一直处于空闲状态，只有当启动垃圾收集时才调用它们。在某一特定的阶段，会将一些工作分配给驱动垃圾收集的线程和帮助器线程，因此一共有 N 线程并行地运行在 N-CPU 机器上。如果要禁止并行模式，惟一的方法是使用 -Xgcthreads 参数改变启动的垃圾收集帮助器线程个数。

采用并发模式时，JVM 会启动一个后台线程（不利于垃圾收集帮助器线程），在执行应用程序线程的同时，部分工作是在后台完成的。后台线程会试着与应用程序并发执行，以完成垃圾收集的所有操作，因此在执行垃圾收集时，可以减少 STW 造成的暂停。但在某些情况下，并发处理可能对性能造成负面影响，特别是对于 CPU 敏感的应用程序。

下表按照 JVM 版本列出了垃圾收集各个阶段的处理类型。

其中：

X

单线程操作。

P

并行操作（垃圾收集期间所有帮助器线程都在工作）。

C

并发操作（后台线程和应用程序线程并发操作）。

回页首

分析 verbosegc 输出

虽然也有分析程序和其他第三方工具，但本文仅讨论对 verbosegc 日志的分析。这些日志由 JVM 在指定 -verbosegc 命令行参数时生成，是一种非常可靠的独立于平台的调试工具。要获得完整的 verbosegc 语法，请参阅“verbosegc and command-line parameters”。

启用 verbosegc 可能对应用程序的性能有一定影响。如果这种影响是无法接受的，则应该使用测试系统来收集 verbosegc 日志。服务器应用程序通常一直使 verbosegc 处于激活状态。这是监控整个 JVM 是否运转良好的一种好办法，在出现 OutOfMemory 错误的情况下，这种方法具有无可估计的价值。

为了有效地分析 verbosegc 记录，必须把精力集中在相关信息上，并过滤掉“噪音”。通过编写脚本从很长的 verbosegc 追踪记录中提取信息并不难，但是这些记录的格式可能（而且通常确实如此）随不同的 JVM 版本而异。下面的例子用粗体或蓝色字体表示重要的信息。即使记录的格式看起来相差很大，也很容易在 verbosegc 日志中找到这些信息。

您刷新的了吗？

在尝试本文中的建议之前，强烈建议您升级到最新的 JVM 服务刷新（SR）。每次进行新的服务刷新都会有很多修正和改进，应用新的服务刷新可以提高 JVM 的性能和稳定性。迁移到最新的版本（比如 JVM 1.4.0 或 1.3.1，根据使用的平台）提供了增强的性能特性。一定要为 JVM 安装所有必需的 OS 补丁（比如 AIX 上的维护级别）。这些信息记录在随 SDK/JRE 提供的 readme 文件中。

正确设置堆的大小

计算正确的堆大小参数很容易，但它可能对应用程序启动时间和运行时性能有很大的影响。初始大小和最大值分别由参数 -Xms 和 -Xmx 控制，这些值通常是根据理想情况和重负荷情况下堆的使用情况的估计来设置的，但 verbosegc 可以帮助确定这些值，而避免胡乱猜测。下面是从启动到完成程序的初始化（或者进入“就绪”状态）这段时间里，一个应用程序的 verbosegc 输出，如下所示。

			
<GC[0]: Expanded System Heap by 65536 bytes
<GC[0]: Expanded System Heap by 65536 bytes

<AF[1]: Allocation Failure. need 64 bytes, 0 ms since last AF>
<AF[1]: managing allocation failure, action=1 (0/3983128) (209640/209640)>
<GC(1): GC cycle started Tue Oct 29 11:05:04 2002
<GC(1): freed 1244912 bytes, 34% free (1454552/4192768), in 10 ms>
<GC(1): mark: 9 ms, sweep: 1 ms, compact: 0 ms>
<GC(1): refs: soft 0 (age >= 32), weak 5, final 237, phantom 0>
<AF[1]: completed in 12 ms>

上述记录表明，第一次发生 AF 时，堆中的自由空间为 0%（3983128 中有 0 字节可用）。此外，第一次垃圾收集之后，自由空间比例上升到 34%，略高于 -Xminf 标记（默认为 30%）。根据应用程序的使用，使用 -Xms 分配更大的初始堆可能会更好一些。几乎可以肯定的是，上例中的应用程序在下一次 AF 时会导致堆扩展。分配更大的初始堆可以避免这种情况。一旦应用程序进入 Ready 状态，通常不会再遇到 AF，因此也就确定了比较好的初始堆大小。类似地，通过增加应用程序负载也可以探测到避免出现 OutOfMemory 错误的 -Xmx 值。

如果堆太小，即使应用程序不会长期使用很多对象，也会频繁地进行垃圾收集。因此，自然会出现使用很大的堆的倾向。但是由于平台和其他方面的因素，堆的最大大小还受物理因素的限制。如果堆被分页，性能就会急剧恶化，因此堆的大小一定不能超出安装在系统上的物理内存总量。比如，如果 AIX 机器上有 1 GB 的内存，就不应该为 Java 应用程序分配 2 GB 的堆。

即使应用程序在拥有 64 GB 内存的 p690 超级计算机上运行，也不一定就能使用 -Xmx60g（当然是 64 位的 JVM）。虽然在很长时间内，应用程序可能不会遇到 AF，但一旦发生 AF，STW 造成的停顿将很难应付。下面的记录取自 32 GB AIX 系统上分配了 20 GB 堆空间的 64 位 JVM 1.3.1（build caix64131-20021102），它展示了大型堆在这方面的影响。

<AF[29]: Allocation Failure. need 2321688 bytes, 88925 ms since last AF>
<AF[29]: managing allocation failure, action=1 (3235443800/20968372736) 
   (3145728/3145728)>
<GC(29): GC cycle started Mon Nov 4 14:46:20 2002
<GC(29): freed 8838057824 bytes, 57% free (12076647352/20971518464), 
   in 4749 ms>
<GC(29): mark: 4240 ms, sweep: 509 ms, compact: 0 ms>
<GC(29): refs: soft 0 (age >= 32), weak 0, final 1, phantom 0>
<AF[29]: completed in 4763 ms>

垃圾收集用了将近五秒钟，还不包括压缩！垃圾收集周期所花费的时间直接与堆的大小成正比。一条好的原则是根据需要设置堆的大小，而不是将它配置得太大或太小。

常见的一种性能优化技术是将初始堆大小（-Xms）设成与最大堆大小（-Xmx）相同。因为不会出现堆扩展和堆收缩，所以在某些情况下，这样做可以显著地改善性能。通常，只有需要处理大量分配请求的应用程序时，才在初始和最大堆大小之间设置较大的差值。但是要记住，如果指定 -Xms100m -Xmx100m，那么 JVM 将在整个生命期中消耗 100 MB 的内存，即使利用率不超过 10%。

另一方面，也可以使用 -Xinitsh 在开始的时候分配较大的系统堆，从而避免出现 Expanded System Heap 消息。但这些消息完全可以忽略。系统堆随着需要而扩展，并且永远不会发生垃圾收集，它只包含那些度过了 JVM 实例整个生命期的对象。

避免堆失效

如果使用大小可变的堆（比如，-Xms 和 -Xmx 不同），应用程序可能遇到这样的情况，不断出现分配失败而堆没有扩展。这就是堆失效，是由于堆的大小刚刚能够避免扩展但又不足以解决以后的分配失败而造成的。通常，垃圾收集周期释放的空间不仅可以满足当前的分配失败，而且还有很多可供以后的分配请求使用的空间。但是，如果堆处于失效状态，那么每个垃圾收集周期释放的空间刚刚能够满足当前的分配失败。结果，下一次分配请求时，又会进入垃圾收集周期，依此类推。大量生存时间很短的对象也可能造成这种现象。

避免这种循环的一种办法是增加 -Xminf 和 -Xmaxf 的值。比方说，如果使用 -Xminf.5，堆将增长到至少有 50% 的自由空间。同样，增加 -Xmaxf 也是很合理。如果 -Xminf.5 等于 5，-Xmaxf 为默认值 0.6，因为 JVM 要把自由空间比例保持在 50% 和 60% 之间，所以就会出现太多的扩展和收缩。两者相差 0.3 是一个不错的选择，这样 -Xmaxf.8 可以很好地匹配 -Xminf.5。

如果记录表明，需要多次扩展才能达到稳定的堆大小，但可以更改 -Xmine，根据应用程序的行为来设置扩展大小的最小值。目标是获得足够的可用空间，不仅能满足当前的请求，而且能满足以后的很多请求，从而避免过多的垃圾收集周期。-Xmine、-Xmaxf 和 -Xminf 为控制应用程序的内存使用特性提供了很大的灵活性。

标记栈溢出

使用 verbosegc 最重要的一项检查是没有出现“mark stack overflow”消息。下面的记录显示了这种消息及其影响。

<AF[50]: Allocation Failure. need 272 bytes, 18097 ms since last AF>
<AF[50]: managing allocation failure, action=1 (0/190698952) 
   (9584432/10036784)>
<GC(111): mark stack overflow>
<GC(111): freed 77795928 bytes in 1041 ms, 43% free (87380360/200735736)>
<GC(111): mark: 949 ms, sweep: 92 ms, compact: 0 ms>
<GC(111): refs: soft 0 (age >= 32), weak 0, final 0, phantom 0>
<AF[50]: completed in 1042 ms>

在垃圾收集的标记阶段，如果引用的个数造成 JVM 内部的“标记栈”溢出，就会引发这种消息。在标记阶段，垃圾收集处理代码使用这个栈压入所有已知的引用，以便递归扫描每个活动引用。溢出的原因是堆中的活动对象过多（或者更准确地说，对象嵌套过深），这通常表明应用程序代码存在缺陷。除非能够通过外部设置控制应用程序中的活动对象个数（比如某种对象池），那么需要在应用程序源代码中解决这个问题。建议使用分析工具确定活动的引用。

如果不能避免大量的活动引用，并发标记可能是一种可行的选择。

摆脱 finalizer

下面的记录显示了一种有趣的情况：解决分配失败花费了 2.78 秒钟，其中还不包括压缩所用的时间。

<AF[1]: Allocation Failure. need 56 bytes, 0 ms since last AF>
<AF[1]: managing allocation failure, action=1 (0/521140736) 
   (3145728/3145728)>
<GC(1): GC cycle started Thu Aug 29 19:25:45 2002
<GC(1): freed 321890808 bytes, 61% free (325036536/524286464), in 2776 ms>
<GC(1): mark: 2672 ms, sweep: 104 ms, compact: 0 ms>
<GC(1): refs: soft 0 (age >= 32), weak 11, final 549708, phantom 0>
<AF[1]: completed in 2780 ms>

罪魁祸首是必须被结束掉的对象数量。无论如何，使用 finalizer 不是一个好主意，虽然在特定的情况下这是不可避免的，但是应该仅仅将它作为完成其他方法不能实现的操作的不得已方法。比方说，无论如何都要避免在 finalizer 内部执行分配。

避免非常大的分配

有时候问题不是由当时的堆状态造成的，而是因为分配失败造成的。比如：

<AF[212]: Allocation Failure. need 912920 bytes, 34284 ms since last AF>
<AF[212]: managing allocation failure, action=2 (117758504/261028856)>
<GC(273): freed 65646648 bytes in 2100 ms, 70% free (183405152/261028856)>
<GC(273): mark: 425 ms, sweep: 89 ms, compact: 1586 ms>
<GC(273): refs: soft 0 (age >= 32), weak 0, final 0, phantom 0>
<GC(273): moved 755766 objects, 43253888 bytes, reason=0, used x4C0 more 
   bytes>
<AF[212]: completed in 2101 ms>

这些记录来自一个非常老的 JVM（准确地说是 ca130-20010615），因此压缩的原因（红色显示）显示为 0。但是压缩 256 MB 的堆花费了 1.5 秒！为何这么差？再来看一看最初的请求，最初请求的是 912920 字节 —— 将近 1 MB。

分配的内存块都必须是连续的，而随着堆越来越满，找到较大的连续块越来越困难。这不仅仅是 Java 的问题，使用 C 中的 malloc 也会遇到这个问题。JVM 在压缩阶段通过重新分配引用来减少碎片，但其代价是要冻结应用程序较长的时间。上面的记录表明已经完成了压缩阶段，分配一大块空间的总时间超过了 2秒。

下面的记录说明了最糟糕的一种情况。

<AF[370]: Allocation Failure. need 2241056 bytes, 613 ms since last AF>
<AF[370]: managing allocation failure, action=2 (135487112/1291844600)>
<GC: Wed Oct 16 10:16:46 2002
<GC(455): freed 41815176 bytes in 28663 ms, 13% free (177302288/1291844600)>
<GC(455): mark: 3233 ms, sweep: 328 ms, compact: 25102 ms>
<GC(455): refs: soft 0 (age >= 32), weak 0, final 17, phantom 0>
<GC(455): moved 15822115 objects, 615093008 bytes, reason=1, used x698 
   more bytes>
<AF[370]: managing allocation failure, action=3 (177302288/1291844600)>
<AF[370]: managing allocation failure, action=4 (177302288/1291844600)>
<AF[370]: clearing all remaining soft refs>
<GC(456): freed 176216 bytes in 3532 ms, 13% free (177478504/1291844600)>
<GC(456): mark: 3215 ms, sweep: 317 ms, compact: 0 ms>
<GC(456): refs: soft 16 (age >= 32), weak 0, final 0, phantom 0>
<GC(457): freed 9592 bytes in 23781 ms, 13% free (177488096/1291844600)>
<GC(457): mark: 3231 ms, sweep: 315 ms, compact: 20235 ms>
<GC(457): refs: soft 0 (age >= 32), weak 0, final 0, phantom 0>
<GC(457): moved 2794668 objects, 110333360 bytes, reason=1, used x30 more 
   bytes>
<AF[370]: managing allocation failure, action=5 (177488096/1291844600)>
<AF[370]: totally out of heap space>
<AF[370]: completed in 268307 ms>

请求的是一个 2 MB 的对象（2241056 bytes），虽然在 1.2 GB 的堆（1291844600）中有 135 MB (135487112) 自由空间，但却不能分配一个 2 MB 的块。虽然进行了一切可能的搜索，花费了 268 秒，但仍然没有找到足够大的块。而且还出现了糟糕的“堆空间严重不足”消息，指出 JVM 的内存不足。

最好的办法是：如果可能的话，把分配请求分解成较小的块。这样，较大的堆空间可能会起作用，但多数情况下，这样做只是推迟了问题出现的时间。

碎片及其成因

我们再看一看上例中的其中一行：

<GC(455): freed 41815176 bytes in 28663 ms, 13% free 
   (177302288/1291844600)>

虽然有 177 MB 的自由空间，却不能分配 2 MB 的块。原因在于：虽然垃圾收集周期可以压缩堆中的孔洞，但是堆中有些内容不能在压缩过程中重新分配。比如，应用程序可能使用 JNI 分配和引用对象或数组。这些分配在内存中是固定的，既不能被重新分配，也不能被回收，除非使用适当的 JNI 调用来释放它们。IBM Java 服务团队可以帮助确定这类引用，在这种情况下，分析工具也大有用武之地。

类似地，因为类块是在堆的外部引用的，因此也是固定的。即使没有固定的对象，大的分配一般也会导致出现碎片。所幸的是，这类严重的碎片很少出现。

需要并发标记吗？

如果由于垃圾收集造成 Java 应用程序不时地停顿，并发标记可以帮助减少停顿的时间，使应用程序运行更平稳。但有时候，并发标记可能会降低应用程序的吞吐能力。建议分别使用和禁止并发标记，使用相同的负荷来测量对应用程序性能的影响，并加以比较。

但是，观察并发标记运行的 verbosegc 输出可能提供大量关于加速的信息。不需要分析打印出来的记录的每一部分，有意义的部分包括并发标记能够成功扫描的概率（EXHAUSTED 和 ABORTED/HALTED），以及后台线程能够做多少工作。

下面的三个记录属于同一个 Java 应用程序，是在一次运行中的不同阶段创建的，它们说明了并发运行的三种不同结果。

第一种可能的结果是并发标记得到 EXHAUSTED：

<CON[3]: Concurrent collection, (3457752/533723648) (3145728/3145728), 
   23273 ms since last CON>
<GC(246): Concurrent EXHAUSTED by Background helper . Target=82856559 
   Traced=57287216 (3324474+53962742) Free=3457752>
<GC(246): Cards cleaning Done. cleaned:13668 (33 skipped). Initial count 
   13701 (Factor 0.142)>
<GC(246): GC cycle started Tue Oct 1 00:05:56 2002
<GC(246): freed 436622248 bytes, 82% free (443225728/536869376), in 218 ms>
<GC(246): mark: 51 ms, sweep: 167 ms, compact: 0 ms>
<GC(246): In mark: Final dirty Cards scan: 43 ms 158 cards (total:127 ms)
<GC(246): refs: soft 0 (age >= 32), weak 0, final 5, phantom 0>
<CON[3]: completed in 230 ms>

这表明并发标记按照我们所预期的那样工作。EXHAUSTED 意味着后台线程能够在出现分配失败之前完成自己的工作。因为后台线程扫描了 3324474 个字节（而应用程序线程扫描了 53962742 个字节），后台线程能够获得足够的 CPU 时间来减少总的标记时间。因此，STW 中的标记阶段只用了 51 毫秒（ms），总的 STW 时间也不过 230 毫秒。这对于 512 MB 的堆来说，这已经很不错了。

下面是 ABORTED 并发标记运行：

<AF[164]: Allocation Failure. need 962336 bytes, 75323 ms since last AF>
<AF[164]: managing allocation failure, action=1 (83408328/533723648) 
   (3145728/3145728)>
<GC(247): Concurrent ABORTED. Target=84703195 Traced=0 (0+0) Free=83408328>
<GC(247): GC cycle started Tue Oct 1 00:06:22 2002
<GC(247): freed 350077400 bytes, 81% free (436631456/536869376), in 896 ms>
<GC(247): mark: 695 ms, sweep: 201 ms, compact: 0 ms>
<GC(247): refs: soft 0 (age >= 32), weak 0, final 7, phantom 0>
<AF[164]: completed in 912 ms>
<CONCURRENT GC Free= 11530600 Expected free space= 11526488 Kickoff=11530370>
< Initial Trace rate is 8.00>

这是最糟糕的情况。并发标记被终止，主要是因为要分配大型对象和调用了 System.gc()。如果应用程序频繁地这样做，那么就不能从并发标记中获得好处。

最好是 HALTED 并发标记：

<AF[168]: Allocation Failure. need 139280 bytes, 25520 ms since last AF>
<AF[168]: managing allocation failure, action=1 (11204296/533723648) 
   (3145728/3145728)>
<GC(251): Concurrent HALTED (state=64). Target=118320773 Traced=35469830 
   (14765196+20704634) Free=11204296>
<GC(251): No Dirty Cards cleaned (Factor 0.177)>
<GC(251): GC cycle started Tue Oct 1 00:08:06 2002
<GC(251): freed 385174400 bytes, 74% free (399524424/536869376), in 389 ms>
<GC(251): mark: 274 ms, sweep: 115 ms, compact: 0 ms>
<GC(251): In mark: Final dirty Cards scan: 46 ms 2619 cards (total:225 ms)
<GC(251): refs: soft 0 (age >= 32), weak 0, final 6, phantom 0>
<AF[168]: completed in 414 ms>

从并发标记的应用来看，HALTED 介于 EXHAUSTED 和 ABORTED 之间，它表明只完成了部分工作。上面的记录说明，在进行下一次分配失败之前，没有完成扫描。在垃圾收集周期中，标记阶段花费了 274 毫秒，总的时间上升到 414 毫秒。

在理想的情况下，多数垃圾收集周期都并发收集（由于并发标记完成其工作而触发，标记为 EXHAUSTED），而不是出现分配失败。如果应用程序调用 System.gc()，记录中会出现很多 ABORTED 行。

在多数应用程序中，并发标记都可以改善性能，对于“标记栈溢出”也有所帮助。但是，如果标记栈溢出是由于缺陷造成的，惟一的解决办法就是修正缺陷。

应该避免的开关

下列命令行开关应避免 使用。

回页首

结束语

本文简单介绍了 IBM JVM 的垃圾收集和堆管理能力。以后的 verbosegc 日志很可能提供更多有用的信息。

总结一下文中提出的建议：

• 只要可能就升级到最新的 JVM 版本。您遇到的错误可能已经被发现并解决了。
• 调整 -Xms、-Xmx 和 -Xminf，直到 verbosegc 输出给出分配失败数量与每次垃圾收集造成的停顿数量之间的一个可接受平衡。使用固定大小的堆避免收缩或扩展。
• 如果可能的话，将较大的（>500 KB）块分解成更小的块。
• 不要忽略“标记栈溢出”消息。
• 避免使用 finalizer。
• 试一试并发标记。
• 问问是否有必要调用 System.gc()，如果没有必要则删除它。

如您所见，这个话题可不是三言两语就能说明白的。但是，只需要打一个电话或者发一封电子邮件，就能与您的好伙伴 IBM Technical Support Team 取得联系（参考资料中的链接是很好的起点）。对于您遇到的特殊情况，他们要比任何文章都更清楚。

回页首

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• Sam Borman 关于 IBM JVM Storage 组件的系列文章是 IBM Java 垃圾收集实现的最详尽的参考资料：
  • “Sensible sanitation: Understanding the IBM Java Garbage Collector, Part 1: Object Allocation”（developerWorks，2002 年 8 月）
  • “Sensible sanitation: Understanding the IBM Java Garbage Collector, Part 2: Garbage Collection”（developerWorks，2002 年 8 月）
  • “Sensible sanitation: Understanding the IBM Java Garbage Collector, Part 3: verbosegc and command-line parameters”（developerWorks，2002 年 9 月）
  
  
• 请访问 Java 2 on the OS/390 and z/OS Platforms 站点，关于可重置 JVM 的信息，请参阅 New IBM Technology featuring Persistent Reusable Java Virtual Machines (PDF)。
  
  
• artima.com 的 Inside Java 2 Virtual Machine 中，“Heap of Fish”对 Mark-Sweep-Compact 算法作了很好的介绍。
  
  
• 如果需要帮助的话，请访问 IBM eServer 技术支持页面。
  
  
• 关于 IBM 服务器的应用方面，可以在 IBM eServer Developer Domain 上可以找到更多技术文章。
  
  
• developerWorks Java 技术专区有数百篇的技术文章和教程。
  

回页首

关于作者

	Sumit Chawla 在 IBM eServer 部门为 ISV 提供 Java 支持。您可以通过 sumitc@us.ibm.com 和他联系。

关注性能: 调优垃圾收集

将 100 MB 的垃圾打包成 50 MB 的包

文档选项 将此页作为电子邮件发送 未显示需要 JavaScript 的文档选项 对此页的评价 帮助我们改进这些内容

级别: 初级

Jack Shirazi, 董事, JavaPerformanceTuning.com
Kirk Pepperdine, CTO, JavaPerformanceTuning.com

2004 年 7 月 30 日

如果您是当前写网志（blogging）狂热者中的一员，则可能听说过 Blog-City，这是由苏格兰的一家小公司 Blog-City Ltd. 拥有和运营的网志站点。当一些意料之外的性能问题突然出现时，Java 性能专家 Jack Shirazi 和 Kirk Pepperdine 被邀请帮助进行 Blog-City 的技术调整。他们的检测工作因为受硬件约束和整个项目所使用的通信通道（IRC、ftp 和 偶尔的电子邮件）的限制而变得复杂。

随着网志作为公共日记的流行，网志主机迅速地增长。所以对于 Blog-City 的人来说，非常清楚他们的站点需要发展和提高。为了满足其增长的需要，该公司最近刚刚推出了 Blog-City version 2.0。正像经常出现的情况那样，当新的应用程序转入运行阶段时，由于各种原因，其性能无法完全满足期望的要求，突然出现随机的长时间应用程序被挂起的现象还不是最坏的情况。

在其核心，Blog-City 依靠 Blue Dragon Servlet 引擎（CFML 引擎）和数据库。令人惊讶的是，所有这些软件都宿主在运行 Red Hat Linux 的相当老的 P3 机器上。这台机器具有单个硬盘和 512MB 内存，这对于过去的负载来说是足够强大的，但它正在承受不断增长的负载。Blog-City 的运作方式很成功，但其资源限制却成了其成功路上的绊脚石。尽管如此，这就是未来还要继续使用一段时间的所有硬件。

问题定义

整个过程的第一步是确定突然出现应用程序减慢的原因。首先我们怀疑的对象是垃圾收集。正如我们在 本专栏的上月文章 中所论述的那样，确定垃圾收集和内存利用问题是否对应用程序产生负面影响的最容易的方式是，设置 -verbose:gc JVM 选项，并检查日志输出。因此我们重新启动应用程序，打开冗长的垃圾收集日志选项，然后耐心地等待应用程序的性能降低。我们的耐心换来的是非常详细的垃圾收集日志文件。

从对日志文件的最初分析中看，在这一应用程序中垃圾收集的瓶颈是显而易见的。种种迹象包括垃圾收集的频率、持续时间和总体效率都已表明这一点。高于普通垃圾收集频率的常见原因是，堆的大小刚好足以适应所有当前正在使用的运行对象，无法适应新的正被创建的对象。虽然应用程序消耗大量堆可能有许多原因，但主要原因可能是没有足够内存而导致垃圾收集器运行，因为它设法满足当前需要。换句话说，应用程序试图分配新对象，但失败了，如果失败的话，将触发垃圾收集程序。如果垃圾收集失败而无法恢复足够内存，它将迫使另一个花费更大的垃圾收集程序发生。即使 GC 恢复了足够的空间来满足瞬间需求，可以肯定的是，在应用程序程序另一次分配失败，触发另一个 GC 之前，时间不会很长。因此，应该关注重复扫描空闲堆空间的无效任务，而不是服务于应用程序的 JVM。

应用程序逐步消耗所有可用的堆空间可能有许多原因，但如果有更多内存的话，临时解决方案就是配置更大的堆。假设应用程序没有内存泄漏（或者也就是我们常说的“无意识地保留对象”），它将找到一个“自然”级别的堆消耗，在这个级别中，GC 将能够很适应地得到维持（除非对象创建的速度过快，以至 GC 总是处于赛跑状态）。在这种情况下，以及无意识地保留对象的情况下，我们需要对应用程序做一些变动，以便获得某些改进。

回页首

如果仅仅是这样，那就太简单了

遗憾的是，我们必须面对严酷的现实因素——正在运行的机器只有 512 MB 内存。更糟的是，我们必须与数据库和其他运行在机器中的进程共享该空间。要完整理解这一点为什么至关重要，首先您必须明确理解垃圾收集的基本知识，以及它如何与底层操作系统进行交互。

虚拟内存不再是灵丹妙药

操作系统已经使用虚拟内存许多年了。正如您所知道的，虚拟内存使操作系统的内存看起来比实际的内存要多，这允许计算机运行那些所需内存比可用物理内存更大的程序，不使用内存的应用程序部分将保存在磁盘上。为了进一步简化，操作系统同时按页管理内存。页通常包含 512 字节到 8 KB，所有页的组合就组成了一个虚拟地址空间。操作系统维持一个页表，用于告诉操作系统如何映射虚拟地址到物理地址。当应用程序要求某个内存位置的内容时，操作系统（或硬件）将识别包含虚拟地址的页面。然后确定该页面是否在内存中，如果不在，将会报告 页面错误。但是有许多种方式来处理页面错误，最终的结果是，页面必须从磁盘载入到内存中。这样应用程序就可以访问到有效虚拟地址的内容。

如果相关对象总是在内存的同一页面上聚合，那么 GC 的连续工作很可能出现困难。但是现实世界中，相关对象很少（如果有的话）出现聚合现象。实际结果是，依靠虚拟内存的系统将导致操作系统将页从内存中换入和换出，因为它标记然后废弃堆空间，而当聚合现象发生时，GC 将很多时间花在等待页面从磁盘换入而不是实际恢复内存上。因此，应用程序正在等待 GC，而 GC 正在等待磁盘，其间未完成任何真正的工作。由于本系统只有一个磁盘，并且它还需要支持数据库，因此我们在解决问题时处于两难境地。一方面，我们需要增加内存数量，这样我们可以减少 GC 的频率，但另一方面，我们还需要确保数据库的完好运行，而数据库也是内存的消耗大户。因此，我们需要了解应用程序所需的最小内存数量。

正如我们在上月看到的，在冗长的 GC 日志中这一信息可以很容易得到，无需为这一信息而扫描整个日志，我们使用免费的 JTune 工具（请参阅 参考资料）来解释冗长的 GC 日志。图 1 显示了经过垃圾收集之后的内存利用情况，其中我们将 -Xmx 设置为 256 MB。

回页首

分析 verbose:gc 输出

在图 1 中，蓝色部分表示部分 GC。橙色区域表示完整的 GC，而粉色矩形表示两个完整 GC 在它们之间少于一毫秒之内已经发生的堆利用情况。从结果中我们看到，平均每 0.257 秒有 12,823 次清除。总共有 345 次完整的垃圾收集和 44 次紧挨着的垃圾收集。完整垃圾收集的平均持续时间是 7.303 秒，结果表明有 9.36% 的运行时间花费在垃圾收集程序上。虽然这个值偏高，它仍然保持在 10% 的正常水平之内。因此，在本例中，GC 是系统的繁重负担但还没有达到严重的地步。真正的问题是存在内存泄漏，这一点可以从总体上堆利用率不断增长的趋势看出来。

即使内存泄漏消耗了 50 MB 内存，它也应该是经过很长一段时间后才发生，这使得内存泄漏在较短的测试中很少会引人注意。内存泄漏的实际结果是，它把 JVM 的内存消耗推动到某个点，在该点它强迫 JVM （从而强迫操作系统）消耗内存，它强迫启动分页。图 2 就证明了这一点。注意正好在 55,000 秒标记之后，每一 GC 周期的持续时间中内存消耗突然地持续增加。

如您所想，由于垃圾收集的阻塞将导致系统只有更少的时间来分配给用户线程，因此用户响应开始增加。在日志的过去 10,000 秒中，我们看到每次完全收集（总共 15 次）花费时间超过了 30 秒，平均持续时间大约 70 秒 —— 这导致超过 10% 的处理时间分配给完全 GC。部分收集（这里刚好超过了 1000 次）无法正常工作，平均每次请求耗时 1.24 秒，远高于以前 11,800 次清除中的平均 0.25 秒。

分代收集

本文不涉及太深的细节（请参阅 参考资料，获取分代 GC 的详细描述），分代堆空间产生了“年轻”和“年老”对象，它们位于分开的堆空间中。在本配置中，年轻和年老分代空间可以通过不同的 GC 算法和策略来维持，以提高 GC 的整体性能。

一种这样的策略是，进一步将年轻分代划分为创建空间，称为 Eden，以及残存（survivor）空间，用于幸存一个或者多个收集的年轻对象。如果在 Eden 中有足够的内存来适应新对象创建的话，这一般能工作正常。如果不是这种情况，那么对象可以在年老对象空间中创建。同样，如果残存空间足够的话，那么对象将移入年老分代空间。我们将使用这些事实来帮助调优遇到的问题。

回页首

减少完全收集的次数

Blog-City 所碰到的难题是在某一随机点出现长的暂停时间。一旦应用程序启动出现问题，不重新启动机器的话，就无法返回跟踪。由于长时间暂停的现象直接与长的 GC 相关，我们考虑如果将对象保持在年轻分代来减少完全 GC 的次数。由于完全 GC 的代价如此之大，在年轻分代收集更多对象能够得到更短的暂停时间。要完成这一任务，我们调整了一些垃圾收集参数，包括 残存比率（survivor ratio）和 期限阈值（tenuring threshold）。

残存比率用于设置与年轻分代空间总体大小相关的残存空间的大小。如果残存比率设置为 8（Intel 的默认值），那么每一残存空间将是 Eden 空间的 1/8 大小。另一种考察它的方式是，年轻分代将该 Eden 空间划分为 10 个相同大小的值，该 Eden 将分配其中的 8 个，每一个残存空间的大小为 1。

我们的假设是，通过减少残存比率，我们可以减少由于残存空间中空间的缺乏，对象过早地被提升为年老分代的几率。另一种方法是增加期限阈值，这样的话，对象在提升之前将需要保留更多的 GC 事件。本着这个想法，Blog-City 将设置更改为 -XX:SurvivorRatio=4 ，然后重新启动。

选择低暂停时间的垃圾收集算法

由于这次技术调优的目标之一是减少暂停时间，我们决定抛弃默认的单线程、标记清扫的垃圾收集程序。我们选择通过标志 XX:+UseParallelGC 来采用并行拷贝收集程序。同样，有关实际算法的细节可以在 Resources中找到，这里需要提一下的是，这一标志调用了一个多线程收集程序。线程的数量设置为 CPU 的数量。基于这一事实，了解为什么单线程并行拷贝垃圾收集程序要比传统的标记清扫算法工作更好是很困难的，但是从实际观察中可以体会到提供了某些性能上的优势。

图 3 和图 4 的输出展示了使用标志 -XX:SurvivorRatio=4 +XX:+UseParallelGC -server -Xmx256M 运行时的结果。

结果图表显示了明显的不同。虽然仍然有一个内存漏洞。内存消耗的总数相比前一个图已经是大大降低了。GC 持续时间的快速比较揭示了年轻分代和年老分代的总体 GC 持续时间的明显减少。

有意的、无意的对象保持

由于应用程序是依靠内存的，跟踪内存泄漏并消除它们已经变得越来越重要。在本例中，用于支持缓存策略的组件决定了主要漏洞的来源。从最后的内存分析情况来看（图 3），虽然消除了主要内存泄漏，我们可以看到仍有另一个“低级别的”的漏洞，但这个漏洞比较小，因此它在下一版本发布之前可以忽略。

回页首

结束语

本文提出了许多挑战。首先，我们正在调优一个现实中的应用程序，这意味着更改会受到很多限制。第二个挑战是，这项任务是使用 IRC 聊天室远程操控的。聊天室不提供任何级别或质量的相互通信，而通信在这种类型的任务中往往是必需的。在本例中，团队已经习惯了聊天室的真实性，并能通过这种真实性毫无任何阻碍地工作着。

最后也是最困难的挑战是我们受硬件的限制。由于多种原因，我们不可能为系统添加新硬件。其中最大的问题是系统中物理内存的数量，而 JVM 和 MySQL 需要大量的内存。但是，通过系统地逐一应用许多更改，并度量它们对系统产生的影响，我们可以逐步地改进总体系统性能。

回页首

参考资料

• 阅读 Jack Shirazi 和 Kirk Pepperdine 的完整的 关注性能系列文章 。
  
  
• 文章“ Kernel comparison: Improved memory management in the 2.6 kernel”考察了 IBM Linux 内核的虚拟内存（ developerWorks，2004 年 3 月）。
  
  
• 请访问 Blog-City。
  
  
• 下载 HP JTune。
  
  
• 阅读 Sam Borman 的“ Sensible Sanitation -- Understanding the IBM Java Garbage Collector, Part 1: Object allocation”（ developerWorks，2002 年 8 月）。
  
  
• 在 Java theory and practice专栏中，Brian Goetz 在 Garbage collection and performance（ developerWorks，2004 年 1 月）和 Java 理论与实践：JVM 1.4.1 中的垃圾收集（ developerWorks，2003 年 11 月）中考察了 GC。
  
  
• 有关 Sun VM 的权威指南，请阅读 Tuning Garbage Collection with the 1.4.2 Java[tm] Virtual Machine。
  
  
• 在我们的网站上可以找到 GC 性能的技巧。
  
  
• 从 JavaPerformance Tuning, 2nd Edition一书中学习所有关于性能调优的知识。
  
  
• 请访问 Developer Bookstore，获取技术书籍的完整列表，其中包括数百本 Java 相关的图书。
  
  
• 在 developerWorksJava 技术专区 中可以找到有关 Java 编程各个方面的数百篇文章。
  
  
• 是否对无需通常的高成本入口点（entry point ）或短期评估许可证的 IBM 测试产品感兴趣？ developerWorks Subscription为 WebSphere ®、DB2 ®、Lotus ®、Rational ®和 Tivoli ®产品提供了低成本的 12 个月单用户许可证，包括基于 Eclipse 的 WebSphere Studio IDE，用于开发、测试、评估和展示您的应用程序。
  

回页首

作者简介

	Jack Shirazi 是 JavaPerformanceTuning.com的董事和 Java Performance Tuning, 2nd Edition (O'Reilly) 一书的作者。

	Kirk Pepperdine is 是 Java Performance Tuning.com 的首席技术官（Chief Technical Officer，CTO），过去 15 年来他一直专攻对象技术和性能调优。Kirk 是 Ant Developer's Handbook (MacMillan) 一书的合著者。

文档选项 将此页作为电子邮件发送 未显示需要 JavaScript 的文档选项 对此页的评价 帮助我们改进这些内容

级别: 初级

Jack Shirazi, 董事, JavaPerformanceTuning.com
Kirk Pepperdine, 首席技术官, JavaPerformanceTuning.com

2004 年 5 月 01 日

您的应用程序是否经常出现 out-of-memory 错误？用户是否感受到响应时间有些不稳定？应用程序是否在相当长的时间内变得没有响应？应用程序的性能是否显得迟缓了？如果对任何一个问题的回答是肯定的，那么您很可能遇到了垃圾收集的问题了。先别进行优化，且听听 JavaPerformanceTuning.com 的 Jack Shirazi 和 Kirk Pepperdine 来解释如何识别垃圾收集问题，并由此帮助您回答这个问题：您知道垃圾收集器在干什么吗？

许多开发人员认为，内存管理至多是开发业务逻辑的主要任务之外的一项不重要的工作 —— 直到业务逻辑不能像预期的或者测试时那样执行得好。出现这种情况时，就需要知道哪里出错了及其原因，这意味着要理解应用程序如何与底层计算资源（特别是内存）进行交互。理解应用程序如何利用内存的最好方式是观察垃圾收集器的行动。

为什么我的应用程序不连贯了？

Java 虚拟机中最大的一个性能问题是应用程序线程与同时运行的 GC 的互斥性。垃圾收集器要完成其工作，需要在一段时间内防止所有其他线程访问它正在处理的堆空间（内存）。按 GC 的术语，这段时间称为“stop-the-world”，并且，正如其名字所表明的，在垃圾收集器努力工作时，应用程序有一个急刹车。幸运的是，这种暂停通常是很短的，很难察觉到，但是很容易想像，如果应用程序在随机的时刻出现随机且较长时间的暂停，对应用程序的响应性和吞吐能力会有破坏性的影响。

不过 GC 只是应用程序出现不连贯和停顿的一个原因。那么如何确定 GC 对产生这些问题是否负有责任呢？要回答这个问题，我们需要测量垃圾收集器的工作强度，并当在系统中进行改变时继续这些测量，以定量地确定所做的改变是否有所期望的效果。

我需要多少内存？

普遍接受的信念是，在系统中添加内存将解决许多性能问题。虽然这个原则对于 JVM 来说经常是正确的，但是太多好东西可能对性能是有害的。因此技巧在于 Java 应用程序需要多少内存就给它多少，但是绝不多给。问题是，应用程序需要多少内存？对于应用程序不连贯的情况，我们需要观察垃圾收集行为以了解看它做的是否比所需要的更多。这些观察将告诉我们所做的改变是否有所期望的效果。

回页首

测量 GC 的活动

生成 GC 日志的标准方式是使用 -verbose:gc 旗标，设置这个旗标后，垃圾收集器会在每次运行时生成它所做的事情的汇总，一般是写入到控制台（通过标准输出或者标准错误）。许多 VM 支持一个允许 verbose GC 输出转向到一个文件的选项。例如，在 Sun 的 1.4 JVM 中，可以使用开关 -Xloggc:filename 将 GC 输出写到文件中。对于 HP JVM，要使用 -Xverbosegc=file 开关。在本文中，我们将分析 Sun 1.4.2 和 IBM 1.4.1 JVM 捕获的 verbose GC 输出。

使用这个方法监视内存使用的一个最大好处是它对应用程序的性能的影响很小。不幸的是，这个解决方案并不完美，因为这些日志文件可能变得特别大，而维护它们可能需要重新启动 JVM。尽管如此，这种技术在生产环境中仍然是可行的，因为它可以帮助诊断只在这种环境中才列出的性能问题。

更深入观察 GC

-verbose:gc 旗标生成的输出根据 JVM 厂商而不同，不同的垃圾收集器选项会报告特定于该实现的信息。例如，由 IBM JVM 生成的输出比由 Sun JVM 生成的输出冗长得多，而 Sun 的输出更适合于由工具读取。就是说，每一个 GC 日志传达基本信息 —— 使用了多少内存、恢复了多少内存、GC 周期用了多少时间，以及在收集期间是否采取了其他行动。从这些基本测量中，我们可以推断出有助于更好地理解所发生的事情的细节。我们要计算的统计如下所示：

• 考虑的运行时的持续时间
• 收集总数
• 收集频率
• 收集所用最长时间
• 收集所用总时间
• 收集所用平均时间
• 收集的平均间隔
• 分配的字节总数
• 每次收集每秒分配的字节数
• 恢复的字节总数
• 每次收集每秒恢复的字节总数

理解了暂停时间，我们就可以理解 GC 对应用程序不响应是否负有部分或者全部责任了。一种实现这一任务的方法是将详细（verbose） GC 日志中的 GC 活动与系统采集的其他日志（如 Web 服务器日志中的请求 backlog）相对应。几乎可以肯定最长的 GC 暂停会导致整个系统响应可感觉的下降，所以知道什么时候响应下降是很有用的，这样就可以将 GC 活动与应用程序吞吐相关联起来。

另一种可能的竞争因素是堆内存分配和恢复的比率，称为 churn。产生大量立即释放的对象的应用程序通常会受到 churn 的拖累。更高的 churn 比率对垃圾收集器加以很大压力，创造了更多的内存资源竞争，这又可导致更长的暂停或者可怕的 OutOfMemoryError 。

了解应用程序是否遭遇这些问题的一个方法是测量所考虑的整个运行时期间 GC 所占用的总时间。有了这种计算，我们就可以了解 GC 做的是否比它所应该做的更多。让我们推导出进行这种判断所需要的公式。

回页首

Sun GC 日志记录

清单 1 是由 Sun 1.4.2_03 JVM 以 -Xloggc:filename 运行默认的标记-清除收集器所生成的日志记录的例子。可以看到，日志项非常精确地记录了每次所做的事情。

69.713: [GC 11536K->11044K(12016K), 0.0032621 secs]
69.717: [Full GC 11044K->5143K(12016K), 0.1429698 secs]
69.865: [GC 5958K->5338K(11628K), 0.0021492 secs]
69.872: [GC 6169K->5418K(11628K), 0.0021718 secs]
69.878: [GC 6248K->5588K(11628K), 0.0029761 secs]
69.886: [GC 6404K->5657K(11628K), 0.0017877 secs]

首先注意到的可能是每一项日志记录是写在一组方括号内的。其他 GC 算法，如并发收集器， 可能将一些值分解为更细的信息。如果是这种情况，这些被分解的值会由包围在嵌入的一组方括号中的细节所替代，这使工具可以更容易地处理详细 GC 输出。

我们的研究首先从分析清单 1 中标记为 69.713 的记录开始。这个标记是 JVM 开始后的秒数和毫秒数的时间戳。在这个例子中，JVM 在这个 GC 周期开始之前运行了 69.713 秒。从左到右的字段为：执行的收集的类型、GC 之前的堆使用、总的堆能力和 GC 事件的持续时间。从这个描述中我们可以看出第一个 GC 事件是一个小的收集。在 GC 开始之前，使用了 11536 Kb 的堆空间。在完成时，使用了 11044 Kb，堆能力为 12016 Kb，而整个收集用了 .0032621 秒。下一个事件，一个完全的 GC，在 69.717 秒时或者上一个小 GC 事件之后 0.003 秒时开始。注意，如果将小 GC 事件的持续时间加到其开始时间上，就会看到它在完全的 GC 开始之前不到 1毫秒结束。因此我们可以得出结论：小收集没有恢复足够的空间，这种失败触发了完全的 GC。对应用程序来说，这像是一个持续了 0.1462319 秒的事件。让我们继续确定如何计算其他值。

GC 日志记录的参数确定

我们通过确定每个 GC 日志记录中的值的参数来开始分析：

R(n) = T(n): [ <GC> HB->HE(HC), D]

n	清单中记录的索引，1 是第一个，m 是最后一个
R(n)	GC 记录
T(n)	第 n 个 GC 发生的时间
HB	GC 之前堆的数量
HE	GC 之后使用的堆数量
HC	堆空间的总量
D	GC 周期的持续时间

有了这些定义，我们现在可以推导出用于计算前面描述的值的公式。

回页首

基本值

我们要计算的第一个值是日志所覆盖的运行时整个持续时间。如果要考虑每一项记录，那么就要分析最后一项记录的时间戳。因为清单 1 只表示全部日志记录的一部分，我们需要从最后一项中提取出第一个时间戳。尽管对这个例子来说，这个数字足够精确，但是为了绝对准确，需要加上最后 GC 的持续时间。其原因是时间戳是在 GC 开始时记录的，而记录表示在记录了时间戳以后发生的事情。

剩余值是取记录中相应的值的总和计算的。值得注意的是恢复的字节可以通过分析记录中测量的关系而计算，而分配的字节可以通过分析前后记录测量之间的关系计算。例如，如果考虑在时间戳 69.872 和 69.878 之间发现的记录对，可以用第一个记录中 GC 之后占用的内存数量减去第二个记录在 GC 之前占用的字节数量计算在新的一代（generation）中分配的字节数量： 6248 Kb - 5418 Kb = 830 Kb 。下面表 1 展示了其他值的公式。

要找出最长的 GC 暂停，我们只需要查看持续时间并寻找 D(n) （记录 n 的持续时间）的最大值。

表 1. 统计公式

统计	计算（时间单位调整为秒）
运行时持续时间	RT = (T(M) + D(M)) - T(1)
小收集的总数	TMC = Sum( R(n)) 其中 GC(n) = GC
完全收集的总数	TFC = Sum( R(n)) 其中 GC(n) = Full
收集频率（小收集）	CFM = TMC / RT
收集频率（完全）	CFF = TFC / RT
收集的时间（最长的小收集）	MAX(D(n)) for all n 其中 GC(n) = GC
收集的时间（最长的完全收集）	MAX(D(n)) for all n 其中 GC(n) = Full
小收集的时间（总数）	TTMC = Sum(D(n)) for all n 其中 GC(n) = GC
完全收集的时间（总数）	TTFC Sum(D(n)) for all n 其中 GC(n) = Full
收集的时间（总数）	TTC = TTMC + TTFC
小收集的时间（平均）	ATMC = TTMC / RT
完全收集的时间（平均）	ATFC = TTFC / RT
收集的时间（平均）	ATC = TTC / RT
收集间隔（平均）	Sum( T(n+1) - T(n)) / (TMC + TFC) for all n
分配的字节（总数）	TBA = Sum(HB(n+1) - HE(n)) 对于所有 n
分配的字节（每秒）	TBA / RT
分配的字节（每次收集）	TBA / (TMC + TFC)
小收集恢复的字节（总数）	BRM = Sum(HB(n) - HE(n)) 其中 GC(n) = GC
完全收集恢复的字节（总数）	BRF = Sum(HB(n) - HE(n)) 其中 GC(n) = Full
恢复的字节（总数）	BRT = BRM + BRF
恢复的字节（每次小收集）	BRPM = BRM / TMC
恢复的字节（每次完全收集）	BRPF = BRF / TMF
恢复的字节（小收集每秒）	BRP = BRM / TTMC
恢复的字节（完全收集每秒）	BRF = BRF / TTFC

可以从公式中看出，我们经常需要分别考虑完全 GC 和小 GC。小 GC 与完全 GC 有根本性的不同，一般来说前者至少比后者要快一个数量级。我们可以通过快速分析清单 1 看出这一点 —— 最长的小收集比完全收集快 50 倍。

下面表 2 显示对清单 1 中的值使用表 1 中的公式的结果。

表 2. Sun GC 日志分析

统计	计算（时间单位调整为秒）
运行时持续时间	(69.886 + 0.0017877) - 69.713 = 0.1747877
小收集总数	5
完全收集总数	1
收集频率（小收集）	5 / 0.1747877 = 28.6 per second
收集频率（完全）	1 / 0.1747877 = 5.27 per second
收集时间（最长的小收集）	0.0032621
收集时间（最长的完全收集）	0.1429698
小收集的时间（总数）	0.0123469
完全收集的时间（总数）	0.1429698
收集的时间（总数）	0.1553167
小收集的时间（平均）	7.1%
完全收集的时间（平均）	81.8%
收集的时间（平均）	88.9%
收集间隔（平均）	.173/5=0.0346
分配的字节（总数）	3292
分配的字节（每秒）	18834 Kb/second
分配的字节（每次收集）	549 Kb
小收集恢复的字节（总数）	3270 Kb
完全收集恢复的字节（总数）	5901 Kb
恢复的字节（总数）	5901 + 3270 = 9171 Kb
恢复的字节（每次小收集）	3270/5 = 654
恢复的字节（每次完全收集）	5901/1 = 5901
恢复的字节（小收集每秒）	3270/0.0123469 = 264843 Kb/second
恢复的字节（完全收集每秒）	5901/0.1429698 = 41274K/second

表 2 包含从这些看来简单的日志中推算出的大量信息。取决于所关注的问题，可能不需要计算所有这些值，因为其中一些值比另一些更有用。对于应用程序长时间不响应的情况，要关注的是 GC 持续时间和计数。

回页首

IBM GC 日志记录

与 Sun 日志不同，IBM 日志特别冗长。即使这样，仍然需要一个指导以完全理解所提供的信息。清单 2 是这种 verbose:gc 日志文件的一部分。

<AF[31]: Allocation Failure. need 528 bytes, 969 ms since last AF>
<AF[31]: managing allocation failure, action=1 (0/97133320) (1082224/1824504)>
  <GC(31): GC cycle started Wed Feb 25 23:08:41 2004
  <GC(31): freed 36259000 bytes, 37% free (37341224/98957824), in 569 ms>
  <GC(31): mark: 532 ms, sweep: 37 ms, compact: 0 ms>
  <GC(31): refs: soft 0 (age >= 32), weak 0, final 2, phantom 0>
<AF[31]: managing allocation failure, action=3 (37341224/98957824)>
  <GC(31): need to expand mark bits for 116324864-byte heap>
  <GC(31): expanded mark bits by 270336 to 1818624 bytes>
  <GC(31): need to expand alloc bits for 116324864-byte heap>
  <GC(31): expanded alloc bits by 270336 to 1818624 bytes>
  <GC(31): need to expand FR bits for 116324864-byte heap>
  <GC(31): expanded FR bits by 544768 to 3637248 bytes>
  <GC(31): expanded heap by 17367040 to 116324864 bytes, 47% free, ratio:0.417>
<AF[31]: completed in 812 ms>

<AF[32]: Allocation Failure. need 528 bytes, 1765 ms since last AF>
<AF[32]: managing allocation failure, action=1 (0/115394264) (930600/930600)>
  <GC(32): GC cycle started Wed Feb 25 23:08:43 2004
  <GC(32): freed 54489184 bytes, 47% free (55419784/116324864), in 326 ms>
  <GC(32): mark: 292 ms, sweep: 34 ms, compact: 0 ms>
  <GC(32): refs: soft 0 (age >= 32), weak 0, final 0, phantom 0>
<AF[32]: completed in 328 ms>

<AF[33]: Allocation Failure. need 528 bytes, 1686 ms since last AF>
<AF[33]: managing allocation failure, action=1 (0/115510592) (814272/814272)>
  <GC(33): GC cycle started Wed Feb 25 23:08:45 2004
  <GC(33): freed 56382392 bytes, 49% free (57196664/116324864), in 323 ms>
  <GC(33): mark: 285 ms, sweep: 38 ms, compact: 0 ms>
  <GC(33): refs: soft 0 (age >= 32), weak 0, final 18, phantom 0>
<AF[33]: completed in 324 ms>

清单 2 中有三项 GC 日志记录。我将不会提供完全的说明，而是推荐一篇由 Sam Borman 所写的很好的文章“Sensible Sanitation”（请参阅 参考资料）。对于我们的目的，需要与像对 Sun JVM 的日志那样推算出同样类型的信息。好的方面是有一些计算结果已经是现成的了。例如，如果分析 AF[31] （事件 31 分配失败），将会看到 GC 之间的间隔、恢复的内存数量、事件的持续时间。我们可以根据这些数字计算其他所需要的值。

回页首

这些数字有什么意义

如何看待这些数字取决于所要得到的结果。在许多服务器应用程序中，它归结为缩短暂停时间，这又归结为减少所发生的完全收集的持续时间和次数。下个月，我们将探讨如何用这些信息调优曾经受这个问题困扰的一个真实应用程序。

回页首

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 查看 关注性能系列的其他文章 。
  
  
• Sam Borman 的“ Sensible Sanitation”讨论了 IBM JVM 垃圾收集器的细节（ developerWorks，2002 年 8 月）。
  
  
• Brian Goetz 在 “ Java theory and practice: Garbage collection and performance”（ developerWorks，2004 年 1 月）中讨论了 GC。
  
  
• 对于 Sun VM 的权威指导，请阅读 Tuning Garbage Collection with the 1.4.2 Java[tm] Virtual Machine。
  
  
• 在 Java 性能调优网站找到 GC 性能提示。
  
  
• 阅读 Jack Shirazi 的 Java Performance Tuning, 2nd Edition （O'Reilly）中关于 GC 的所有内容。
  
  
• 在 developerWorksJava 技术专区 中可以找到有关 Java 编程各个方面的数百篇文章。
  
  
• 请访问 Developer Bookstore，获得技术书籍的完整列表，其中包括数百本 Java 相关主题的书籍。
  
  
• 对于测试驱动 IBM 产品而不需要考虑高成本门槛或者短期的评估许可证感兴趣吗？ developerWorks Subscription针对 WebSphere®、DB2®、Lotus®、Rational®以及 Tivoli®产品 —— 其中包括基于 Eclipse 的 WebSphere Studio IDE，提供一个低成本的、12 个月的单用户许可证，用于开发、测试、评估和演示您的应用程序。
  

回页首

作者简介

	Jack Shirazi 是 JavaPerformanceTuning.com的董事，也是 Java Performance Tuning, 2nd Edition （O'Reilly） 一书的作者。

	Kirk Pepperdine 是 Java Performance Tuning.com 的首席技术官，并且在过去 15 年一直关注对象技术和性能调优。Kirk 是 Ant Developer's Handbook （MacMillan）一书的合著者。