Java性能优化宝典：G1垃圾收集器与HotSpot VM深度解析

5星 · 超过95%的资源需积分: 10 181 浏览量更新于2024-07-20 收藏 6.97MB PDF 举报

《Java® Performance Companion》是一本专为Java开发者打造的性能优化指南，由经验丰富的Java性能和HotSpot JVM专家Charlie Hunt、Monica Beckwith、Poonam Parhar和Bengt Rutisson共同编撰。该书在Java® Performance经典之作基础上，着重介绍了两个关键的Java平台创新：Garbage First (G1) 垃圾回收器和HotSpot VM Serviceability Agent。首先，G1垃圾收集器是针对现代多核硬件和复杂操作系统环境中的性能提升而设计的。它弥补了传统并行、串行和Concurrent Mark Sweep (CMS)垃圾收集器的局限性。书中详细讲解如何利用G1，包括深入理解其收集过程（新生代和老年代），掌握如何调整以适应特定应用需求，以及识别和实施潜在优化策略，解读实验结果并采取行动。其次，作者带领读者探索HotSpot VM的内部结构，讲解如何使用Serviceability Agent来分析、诊断和解决各种VM问题，如内存溢出、Java级死锁和VM崩溃。本书还涵盖了如何扩展Serviceability Agent，以及利用VisualVM插件进行更深入的监控。此外，书中特别关注那些在Java Performance中未详尽介绍的HotSpot VM命令行选项，为开发者提供更全面的性能管理工具。通过阅读这本书，无论是在JDK 8还是9环境下，都能帮助用户最大化Java应用程序的性能和价值，适用于任何规模和环境。《Java® Performance Companion》是一本实用的参考书籍，不仅包含了理论知识，还提供了丰富的实战经验和技巧，是每个追求Java性能优化的专业人士不可或缺的工具。同时，读者可以通过informit.com注册获取最新下载、更新和修正，确保始终掌握最前沿的最佳实践。

ptg17009775

About the Authors

Charlie Hunt (Chicago, IL) is currently a JVM Engineer at Oracle leading a variety

of Java SE and HotSpot VM projects whose primary focus is reducing memory

footprint while maintaining throughput and latency. He is also the lead author of

Java™ Performance (Addison-Wesley, 2012). He is a regular presenter at the JavaOne

Conference where he has been recognized as a Java Rock Star. He has also been

a speaker at other well-known conferences, including QCon, Velocity, GoTo, and

Dreamforce. Prior to leading a variety of Java SE and HotSpot VM projects for Oracle,

Charlie worked in several different performance positions, including Performance

Engineering Architect at Salesforce.com and HotSpot VM Performance Architect at

Oracle and Sun Microsystems. He wrote his first Java application in 1998, joined

Sun Microsystems in 1999 as Senior Java Architect, and has had a passion for Java

and JVM performance ever since.

Monica Beckwith is an Independent Performance Consultant optimizing customer

applications for server-class systems running the Java Virtual Machine. Her past

experiences include working with Oracle, Sun Microsystems, and AMD. Monica has

worked with Java HotSpot VM optimizing the JIT compiler, the generated code, the

JVM heuristics, and garbage collection and collectors. She is a regular speaker at

various conferences and has several published articles on topics including garbage

collection, the Java memory model, and others. Monica led Oracle’s Garbage First

Garbage Collector performance team, and was named a JavaOne Rock Star.

ptg17009775

2 Chapter 1



Garbage First Overview

collector is described as parallel, it uses multiple threads to perform garbage collection.

In the case of the HotSpot garbage collectors, almost all multithreaded GC operations

are handled by internal Java VM (JVM) threads. One major exception to this is the

G1 garbage collector, in which some background GC work can be taken on by the

application threads. For more detail see Chapter 2, “Garbage First Garbage Collector

in Depth,” and Chapter 3, “Garbage First Garbage Collector Performance Tuning.”

The term stop-the-world means that all Java application threads are stopped

during a GC event. A stop-the-world garbage collector is one that stops all Java

application threads when it performs a garbage collection. A GC phase or event may

be described as stop-the-world, which means that during that particular GC phase

or event all Java application threads are stopped.

The term concurrent means that garbage collection activity is occurring at the

same time as the Java application is executing. A concurrent GC phase or event

means that the GC phase or event executes at the same time as the application.

A garbage collector may be described by any one or a combination of these three

terms. For example, a parallel concurrent collector is multithreaded (the parallel

part) and also executes at the same time as the application (the concurrent part).

Parallel GC

Parallel GC is a parallel stop-the-world collector, which means that when a GC occurs, it

stops all application threads and performs the GC work using multiple threads. The GC

work can thus be done very efficiently without any interruptions. This is normally the

best way to minimize the total time spent doing GC work relative to application work.

However, individual pauses of the Java application induced by GC can be fairly long.

Both the young and old generation collections in Parallel GC are parallel and

stop-the-world. Old generation collections also perform compaction. Compaction

moves objects closer together to eliminate wasted space between them, leading to an

optimal heap layout. However, compaction may take a considerable amount of time,

which is generally a function of the size of the Java heap and the number and size

of live objects in the old generation.

At the time when Parallel GC was introduced in HotSpot, only the young

generation used a parallel stop-the-world collector. Old generation collections used a

single-threaded stop-the-world collector. Back when Parallel GC was first introduced,

the HotSpot command-line option that enabled Parallel GC in this configuration was

-XX:+UseParallelGC.

At the time when Parallel GC was introduced, the most common use case for

servers required throughput optimization, and hence Parallel GC became the

default collector for the HotSpot Server VM. Additionally, the sizes of most Java

heaps tended to be between 512MB and 2GB, which keeps Parallel GC pause times

ptg17009775

Parallel GC 3

relatively low, even for single-threaded stop-the-world collections. Also at the time,

latency requirements tended to be more relaxed than they are today. It was common

for Web applications to tolerate GC-induced latencies in excess of one second, and as

much as three to five seconds.

As Java heap sizes and the number and size of live objects in old generation grew,

the time to collect the old generation became longer and longer. At the same time,

hardware advances made more hardware threads available. As a result, Parallel GC

was enhanced by adding a multithreaded old generation collector to be used with a

multithreaded young generation collector. This enhanced Parallel GC reduced the

time required to collect and compact the heap.

The enhanced Parallel GC was delivered in a Java 6 update release. It was

enabled by a new command-line option called -XX:+UseParallelOldGC. When

-XX:+UseParallelOldGC is enabled, parallel young generation collection is also

enabled. This is what we think of today as Parallel GC in HotSpot, a multithreaded

stop-the-world young generation collector combined with a multithreaded stop-the-

world old generation collector.

Tip

In Java 7 update release 4 (also referred to as Java 7u4, or JDK 7u4), - XX:+UseParallelOldGC

was made the default GC and the normal mode of operation for Parallel GC. As of Java 7u4,

specifying -XX:+UseParallelGC also enables -XX:+UseParallelOldGC, and likewise

specifying -XX:+UseParallelOldGC also enables -XX:+UseParallelGC.

Parallel GC is a good choice in the following use cases:

1. Application throughput requirements are much more important than latency

requirements.

A batch processing application is a good example since it is noninteractive. When

you start a batch execution, you expect it to run to completion as fast as possible.

2. If worst-case application latency requirements can be met, Parallel GC will offer

the best throughput. Worst-case latency requirements include both worst-case

pause times, and also how frequently the pauses occur. For example, an application

may have a latency requirement of “pauses that exceed 500ms shall not occur

more than once every two hours, and all pauses shall not exceed three seconds.”

An interactive application with a sufficiently small live data size such that

a Parallel GC’s full GC event is able to meet or beat worst-case GC-induced

latency requirements for the application is a good example that fits this use case.

However, since the amount of live data tends to be highly correlated with the size

of the Java heap, the types of applications falling into this category are limited.

剩余183页未读，继续阅读

ramissue

粉丝: 354
资源: 1487

Java性能优化宝典：G1垃圾收集器与HotSpot VM深度解析

Java Performance Companion(Addison,2016)

Java Performance Companion 无水印pdf

Java Performance Tuning Guide 1.3 By 江南白衣

java.lang.nosuchfielderror: companion

Factory method 'okHttpClientBuilder' threw exception; nested exception is java.lang.NoSuchFieldError: Companion

springboot的定时器报错Unexpected error occurred in scheduled task java.lang.NoSuchFieldError: Companion

nested exception is java.lang.NoSuchFieldError: Companion

Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [okhttp3.OkHttpClient$Builder]: Factory method 'okHttpClientBuilder' threw exception; nested exception is java.lang.NoSuchFieldError: Companion

最新资源