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 次完整的垃圾收集�