Introduction

A wide variety of applications use Java Platform, Standard Edition (Java SE), from small applets on desktops to web services on large servers. In support of this diverse range of deployments, the Java HotSpot virtual machine implementation (Java HotSpot VM) provides multiple garbage collectors, each designed to satisfy different requirements. This is an important part of meeting the demands of both large and small applications. Java SE selects the most appropriate garbage collector based on the class of the computer on which the application is run. However, this selection may not be optimal for every application. Users, developers, and administrators with strict performance goals or other requirements may need to explicitly select the garbage collector and tune certain parameters to achieve the desired level of performance. This document provides information to help with these tasks. First, general features of a garbage collector and basic tuning options are described in the context of the serial, stop-the-world collector. Then specific features of the other collectors are presented along with factors to consider when selecting a collector.

各种各样的应用程序使用Java Platform，Standard Edition（Java SE），从桌面上的小应用程序到大型服务器上的Web服务。为支持这种多样化的部署，Java HotSpot虚拟机实现（Java HotSpot VM）提供了多个垃圾收集器，每个垃圾收集器都可以满足不同的需求。这是满足大型和小型应用程序需求的重要组成部分。Java SE根据运行应用程序的计算机的类选择最合适的垃圾收集器。但是，这种选择对于每个应用程序可能都不是最佳的。具有严格性能目标或其他要求的用户，开发人员和管理员可能需要明确选择垃圾收集器并调整某些参数以达到期望的性能水平。本文档提供了有助于完成这些任务的信息。首先，垃圾收集器的一般特性和基本调优选项在串行世界收集器的上下文中描述。然后介绍其他收集器的具体功能以及选择收集器时要考虑的因素。

A garbage collector (GC) is a memory management tool. It achieves automatic memory management through the following operations:

垃圾收集器（GC）是一种内存管理工具。它通过以下操作实现了自动内存管理：

·        Allocating objects to a young generation and promoting aged objects into an old generation.

·        为年轻代分配对象，并将老对象推广到年老代

·        Finding live objects in the old generation through a concurrent (parallel) marking phase. The Java HotSpot VM triggers the marking phase when the total Java heap occupancy exceeds the default threshold. See the sections Concurrent Mark Sweep (CMS) Collector and Garbage-First Garbage Collector.

通过并行（并行）标记阶段在老一代中查找活动对象。当Java堆占用率超过默认阈值时，Java HotSpot VM会触发标记阶段。请参阅并发标记扫描（CMS）收集器和垃圾优先垃圾收集器部分。

·        Recovering free memory by compacting live objects through parallel copying. See the sections The Parallel Collector and Garbage-First Garbage Collector

通过并行复制压缩活动对象来恢复空闲内存。请参阅并行收集器和垃圾优先垃圾收集器

When does the choice of a garbage collector matter? For some applications, the answer is never. That is, the application can perform well in the presence of garbage collection with pauses of modest frequency and duration. However, this is not the case for a large class of applications, particularly those with large amounts of data (multiple gigabytes), many threads, and high transaction rates.

什么时候选择垃圾收集器很重要？对于某些应用程序，答案从不。也就是说，应用程序可以在存在垃圾收集的情况下运行良好，并保持适中的频率和持续时间。但是，对于大量应用程序而言，情况并非如此，特别是那些具有大量数据（多个千兆字节），多个线程和高事务率的应用程序。

Amdahl's law (parallel speedup in a given problem is limited by the sequential portion of the problem) implies that most workloads cannot be perfectly parallelized; some portion is always sequential and does not benefit from parallelism. This is also true for the Java platform. In particular, virtual machines from Oracle for the Java platform prior to Java SE 1.4 do not support parallel garbage collection, so the effect of garbage collection on a multiprocessor system grows relative to an otherwise parallel application.

Amdahl定律（在给定问题中并行加速受限于问题的顺序部分）意味着大多数工作负载不能完全并行化; 有些部分总是顺序的，并不能从并行性中受益。这对于Java平台也是如此。特别是，在Java SE 1.4之前来自Oracle for Java平台的虚拟机不支持并行垃圾收集，因此多处理器系统上垃圾收集的效果相对于其他并行应用程序而言会增加。

The graph in Figure 1-1, "Comparing Percentage of Time Spent in Garbage Collection" models an ideal system that is perfectly scalable with the exception of garbage collection (GC). The red line is an application spending only 1% of the time in garbage collection on a uniprocessor system. This translates to more than a 20% loss in throughput on systems with 32 processors. The magenta line shows that for an application at 10% of the time in garbage collection (not considered an outrageous amount of time in garbage collection in uniprocessor applications), more than 75% of throughput is lost when scaling up to 32 processors.

图1-1中的图表“比较垃圾收集所花费的时间百分比”模型是一个理想的系统，除垃圾收集（GC）外，它是完美可扩展的。红线是一个应用程序只花费1％的时间在单处理器系统上进行垃圾收集。这意味着32个处理器的系统吞吐量损失超过20％。品红线表明，对于10％的垃圾收集时间的应用程序（在单处理器应用程序中垃圾收集时间没有考虑过多），超过75％的吞吐量在扩展到32个处理器时会丢失。

Figure 1-1 Comparing Percentage of Time Spent in Garbage Collection

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

这表明，在小型系统上开发时，微不足道的速度问题可能成为扩展到大型系统时的主要瓶颈。但是，减少这种瓶颈的小小改进可以在性能上带来巨大收益。对于一个足够大的系统来说，选择合适的垃圾收集器并在必要时调整它是值得的。

The serial collector is usually adequate for most "small" applications (those requiring heaps of up to approximately 100 megabytes (MB (on modern processors). The other collectors have additional overhead or complexity, which is the price for specialized behavior. If the application does not need the specialized behavior of an alternate collector, use the serial collector. One situation where the serial collector is not expected to be the best choice is a large, heavily threaded application that runs on a machine with a large amount of memory and two or more processors. When applications are run on such server-class machines, the parallel collector is selected by default. See the section Ergonomics.

串行收集器通常适用于大多数“小型”应用程序（那些需要高达大约100兆字节（MB）（在现代处理器上）的应用程序。其他收集器具有额外的开销或复杂性，这是专门行为的代价。不需要替代收集器的专门行为，可以使用串行收集器。串行收集器不是最佳选择的一种情况是一个大型，重度线程化的应用程序，它运行在具有大量内存和两个或更多的处理器，当应用程序在这些服务器级别的机器上运行时，默认情况下会选择并行采集器，参见人机工程学部分。

This document was developed using Java SE 8 on the Solaris operating system (SPARC Platform Edition) as the reference. However, the concepts and recommendations presented here apply to all supported platforms, including Linux, Microsoft Windows, the Solaris operating system (x64 Platform Edition), and OS X. In addition, the command line options mentioned are available on all supported platforms, although the default values of some options may be different on each platform.

本文档是使用Solaris操作系统（SPARC平台版本）上的Java SE 8作为参考开发的。但是，这里介绍的概念和建议适用于所有支持的平台，包括Linux，Microsoft Windows，Solaris操作系统（x64 Platform Edition）和OS X.另外，所提及的命令行选项在所有支持的平台上均可用，但某些选项的默认值在每个平台上可能不同。

2 Ergonomics

Ergonomics is the process by which the Java Virtual Machine (JVM) and garbage collection tuning, such as behavior-based tuning（基于行为的优化）, improve application performance. The JVM provides platform-dependent default selections for the garbage collector, heap size, and runtime compiler. These selections match the needs of different types of applications while requiring less command-line tuning. In addition, behavior-based tuning dynamically tunes the sizes of the heap to meet a specified behavior of the application（自动调整heap size大小）.

Ergonomics 是Java虚拟机（JVM）和垃圾收集调优（如基于行为的调优）改进应用程序性能的过程。JVM为垃圾收集器，堆大小和运行时编译器由提供平台相关的默认选择。这些选择符合不同类型应用程序的需求，同时需要较少的命令行调整。另外，基于行为的调整动态调整堆的大小以满足应用程序的指定行为。

This section describes these default selections and behavior-based tuning. Use these defaults first before using the more detailed controls described in subsequent sections.

Garbage Collector, Heap, and Runtime Compiler Default Selections

A class of machine referred to as a server-class machine has been defined as a machine with the following:

·        2 or more physical processors

·        2 or more GB of physical memory

On server-class machines, the following are selected by default:（默认值）

·        Throughput garbage collector

·        Initial heap size of 1/64 of physical memory up to 1 GB

·        Maximum heap size of 1/4 of physical memory up to 1 GB

·        Server runtime compiler

For initial heap and maximum heap sizes for 64-bit systems, see the section Default Heap Size in The Parallel Collector.

The definition of a server-class machine applies to all platforms with the exception of 32-bit platforms running a version of the Windows operating system. Table 2-1, "Default Runtime Compiler", shows the choices made for the runtime compiler for different platforms.

Table 2-1 Default Runtime Compiler

Platform	Operating System	DefaultFoot1	Default if Server-ClassFootref1
i586	Linux	Client	Server
i586	Windows	Client	ClientFoot2
SPARC (64-bit)	Solaris	Server	ServerFoot3
AMD (64-bit)	Linux	Server	ServerFootref3
AMD (64-bit)	Windows	Server	ServerFootref3

^Footnote1Client means the client runtime compiler is used. Server means the server runtime compiler is used.

^Footnote2The policy was chosen to use the client runtime compiler even on a server class machine. This choice was made because historically client applications (for example, interactive applications) were run more often on this combination of platform and operating system.

^Footnote3Only the server runtime compiler is supported.

Behavior-Based Tuning

For the parallel collector, Java SE provides two garbage collection tuning parameters that are based on achieving a specified behavior of the application: maximum pause time goal（-XX:MaxGCPauseMillis=<N>） and application throughput goal（-XX:GCTimeRatio=<N>）; see the section The Parallel Collector. (These two options are not available in the other collectors.) Note that these behaviors cannot always be met. The application requires a heap large enough to at least hold all of the live data. In addition, a minimum heap size may preclude reaching these desired goals.

对于并行收集器，Java SE提供了两个垃圾收集调优参数，这些参数基于实现应用程序的指定行为：最大暂停时间目标和应用程序吞吐量目标; 请参阅并行收集器一节。（这两个选项在其他收集器中不可用。）请注意，不能始终满足这些行为。该应用程序需要一个足够大的堆以至少保存所有的实时数据。另外，最小堆大小可能无法达到这些预期目标。

Maximum Pause Time Goal

The pause time is the duration during which the garbage collector stops the application and recovers space that is no longer in use. The intent of the maximum pause time goal is to limit the longest of these pauses. An average time for pauses and a variance on that average is maintained by the garbage collector. The average is taken from the start of the execution but is weighted so that more recent pauses count more heavily. If the average plus the variance of the pause times is greater than the maximum pause time goal, then the garbage collector considers that the goal is not being met.

暂停时间是垃圾收集器停止应用程序并回收不再使用的空间的持续时间。最大暂停时间目标的意图是限制这些暂停中最长的时间。垃圾收集器维持平均停顿时间和平均差异。平均值取自执行开始时的平均值，但会加权以使最近的暂停计数更重。如果平均值加上暂停时间的方差大于最大暂停时间目标，那么垃圾收集器认为目标未被满足。

The maximum pause time goal is specified with the command-line option -XX:MaxGCPauseMillis=<nnn>. This is interpreted as a hint to the garbage collector that pause times of <nnn> milliseconds or less are desired. The garbage collector will adjust the Java heap size and other parameters related to garbage collection in an attempt to keep garbage collection pauses shorter than <nnn> milliseconds. By default there is no maximum pause time goal. These adjustments may cause garbage collector to occur more frequently, reducing the overall throughput of the application. The garbage collector tries to meet any pause time goal before the throughput goal. In some cases, though, the desired pause time goal cannot be met.

最大暂停时间是使用命令行-XX:MaxGCPauseMillis=<nnn>选项指定的。这被解释为垃圾收集器提示需要<nnn>几毫秒或更少的暂停时间。垃圾收集器将调整Java堆大小和与垃圾收集相关的其他参数，以尝试使垃圾收集暂停时间短于<nnn>毫秒。默认情况下没有最大暂停时间目标。这些调整可能会导致垃圾收集器更频繁地发生，从而降低应用程序的整体吞吐量。垃圾收集器试图在吞吐量目标之前满足任何暂停时间目标。但是，在某些情况下，无法满足所需的暂停时间目标。

Throughput Goal

The throughput goal is measured in terms of the time spent collecting garbage and the time spent outside of garbage collection (referred to as application time). The goal is specified by the command-line option -XX:GCTimeRatio=<nnn>. The ratio of garbage collection time to application time is 1 / (1 + <nnn>). For example, -XX:GCTimeRatio=19 sets a goal of 1/20th or 5% of the total time for garbage collection.

The time spent in garbage collection is the total time for both the young generation and old generation collections combined. If the throughput goal is not being met, then the sizes of the generations are increased in an effort to increase the time that the application can run between collections.

吞吐量目标是根据收集垃圾的时间和垃圾收集以外的时间（称为应用程序时间）来衡量的。目标由命令行选项指定-XX:GCTimeRatio=<nnn>。垃圾收集时间与应用时间的比率为1 /（1 + <nnn>）。例如，-XX:GCTimeRatio=19设置垃圾收集总时间的1/20或5％的目标。

花在垃圾收集上的时间是年轻代和年老代垃圾回收的合计的总时间。如果吞吐量目标未得到满足，则会增加各代的大小以增加应用程序在集合之间运行的时间。

Footprint Goal

If the throughput and maximum pause time goals have been met, then the garbage collector reduces the size of the heap until one of the goals (invariably the throughput goal) cannot be met. The goal that is not being met is then addressed.

如果吞吐量和最大暂停时间目标已经满足，那么垃圾收集器会减小堆的大小，直到其中一个目标（总是吞吐量目标）不能满足为止。然后解决未达到的目标。

Tuning Strategy

Do not choose a maximum value for the heap unless you know that you need a heap greater than the default maximum heap size. Choose a throughput goal that is sufficient for your application.

除非您知道您需要的堆大于默认最大堆大小，否则不要选择堆的最大值。只需要选择一个足以满足您的应用程序的吞吐量目标即可。

The heap will grow or shrink to a size that will support the chosen throughput goal. A change in the application's behavior can cause the heap to grow or shrink. For example, if the application starts allocating at a higher rate, the heap will grow to maintain the same throughput.

堆将增长或缩小到可支持所选吞吐量目标的大小。应用程序行为的改变会导致堆增长或缩小。例如，如果应用程序开始以更高的速率分配，则堆将增长以保持相同的吞吐量。

If the heap grows to its maximum size and the throughput goal is not being met, the maximum heap size is too small for the throughput goal. Set the maximum heap size to a value that is close to the total physical memory on the platform but which does not cause swapping of the application. Execute the application again. If the throughput goal is still not met, then the goal for the application time is too high for the available memory on the platform.

如果堆增长到最大大小并且吞吐量目标未达到，则最大堆大小对于吞吐量目标而言太小。将最大堆大小设置为接近平台上的总物理内存但不会导致应用程序页交换的值。再次执行应用程序。如果吞吐量目标仍未达到，则平台上的可用内存的应用程序时间目标太高。

If the throughput goal can be met, but there are pauses that are too long, then select a maximum pause time goal. Choosing a maximum pause time goal may mean that your throughput goal will not be met, so choose values that are an acceptable compromise for the application.

如果吞吐量目标可以达到，但是暂停时间太长，则选择最大暂停时间目标。选择最大暂停时间目标可能意味着您的吞吐量目标将无法满足，因此请选择适合应用程序的折衷值。

It is typical that the size of the heap will oscillate as the garbage collector tries to satisfy competing goals. This is true even if the application has reached a steady state. The pressure to achieve a throughput goal (which may require a larger heap) competes with the goals for a maximum pause time and a minimum footprint (which both may require a small heap).

垃圾收集器试图满足相互竞争的目标时，堆的大小通常会振荡。即使应用程序已达到稳定状态，情况也是如此。达到吞吐量目标（可能需要更大的堆）的压力与最大暂停时间和最小占用空间（这两者可能需要一个小堆）的目标相竞争。

3 Generations

One strength of the Java SE platform is that it shields the developer from the complexity of memory allocation and garbage collection. However, when garbage collection is the principal bottleneck, it is useful to understand some aspects of this hidden implementation. Garbage collectors make assumptions about the way applications use objects, and these are reflected in tunable parameters that can be adjusted for improved performance without sacrificing the power of the abstraction.

Java SE平台的一个优势是它可以避免开发人员从内存分配和垃圾回收的复杂性中解脱出来。但是，当垃圾收集是主要瓶颈时，了解此隐藏实现的某些方面很有用。垃圾收集器对应用程序使用对象的方式做出了假设，并且这些都反映在可调参数中，这些参数可以在不牺牲抽象能力的情况下进行调整以提高性能。

An object is considered garbage when it can no longer be reached from any pointer in the running program. The most straightforward garbage collection algorithms iterate over every reachable object. Any objects left over are considered garbage. The time this approach takes is proportional to the number of live objects, which is prohibitive for large applications maintaining lots of live data.

当运行程序中的对象对于任何指针都不能再到访问时，该对象被视为垃圾。最简单的垃圾收集算法迭代每个可到达的对象。任何遗留的对象都被认为是垃圾。这种方法需要的时间与活动对象的数量成正比，这对于大型应用程序保持大量活动数据而言是禁止的。

The virtual machine incorporates a number of different garbage collection algorithms that are combined using generational collection. While naive garbage collection examines every live object in the heap, generational collection exploits several empirically observed properties of most applications to minimize the work required to reclaim unused (garbage) objects. The most important of these observed properties is the weak generational hypothesis, which states that most objects survive for only a short period of time.

虚拟机包含许多不同的垃圾收集算法，这些算法使用分代集合进行组合。最简单的垃圾检查堆中的每个活动对象，但对于代收集利用了大多数应用程序的几个经验观察属性，以尽量减少回收未使用（垃圾）对象所需的工作。这些观察到的性质中最重要的是弱代数假说理论，它指出大多数对象只能在短时间内存活。

The blue area in Figure 3-1, "Typical Distribution for Lifetimes of Objects" is a typical distribution for the lifetimes of objects. The x-axis is object lifetimes measured in bytes allocated. The byte count on the y-axis is the total bytes in objects with the corresponding lifetime. The sharp peak at the left represents objects that can be reclaimed (in other words, have "died") shortly after being allocated. Iterator objects, for example, are often alive for the duration of a single loop.

图3-1“对象存活的典型分布”中的蓝色区域是对象存活的典型分布。x轴是以分配的字节为单位测量的对象生命周期。y轴上的字节数是具有相应存活的对象中的总字节数。左边的尖峰表示在分配后不久可以回收的对象（换句话说，它们已经“死亡”）。例如，迭代器对象在单个循环中经常存在。

Figure 3-1 Typical Distribution for Lifetimes of Objects

Description of "Figure 3-1 Typical Distribution for Lifetimes of Objects"

Some objects do live longer, and so the distribution stretches out to the right. For instance, there are typically some objects allocated at initialization that live until the process exits. Between these two extremes are objects that live for the duration of some intermediate computation, seen here as the lump to the right of the initial peak. Some applications have very different looking distributions, but a surprisingly large number possess this general shape. Efficient collection is made possible by focusing on the fact that a majority of objects "die young."

有些对象存活更长，因此分布向右延伸。例如，通常会有一些对象在初始化时分配，直到进程退出。在这两个极端之间是在某些中间计算期间存活的对象，在这里被看作是初始峰值右边的块。有些应用程序有着非常不同的外观分布，但有一大部分应用程序拥有这种一般形状。通过关注大多数对象“年轻化”的这个事实，有效收集成为可能。

To optimize for this scenario, memory is managed in generations (memory pools holding objects of different ages). Garbage collection occurs in each generation when the generation fills up. The vast majority of objects are allocated in a pool dedicated to young objects (the young generation), and most objects die there. When the young generation fills up, it causes a minor collection in which only the young generation is collected; garbage in other generations is not reclaimed. Minor collections can be optimized, assuming that the weak generational hypothesis holds and most objects in the young generation are garbage and can be reclaimed. The costs of such collections are, to the first order, proportional to the number of live objects being collected; a young generation full of dead objects is collected very quickly. Typically, some fraction of the surviving objects from the young generation are moved to the tenured generation during each minor collection. Eventually, the tenured generation will fill up and must be collected, resulting in a major collection, in which the entire heap is collected. Major collections usually last much longer than minor collections because a significantly larger number of objects are involved.

为了针对这种情况进行优化，内存按代管理（持有不同年龄的对象的内存池）。在每一代中，当代填满时垃圾收集发生。绝大多数对象被分配在专用于年轻对象的池中（年轻代），并且大部分对象都在那里死亡。当年轻代填满时，它会导致较小的垃圾回收，并且只收集年轻代; 其他代垃圾不回收。假设弱代数成立并且年轻代中的大多数对象都是垃圾并且可以回收，可以对次要集合进行优化。这种收集的成本，对于第一个订单而言，与收集的对象的数量成比例; 一个充满死对象的年轻代很快就被收集起来。通常情况下，年轻代幸存对象的一小部分将在每次小规模收集期间转移到年老代。最终，年老代被填满时必须进行垃圾回收，导致major collection，其中整个堆被收集。Major collections通常比minor collections持续更长的时间，因为涉及的对象数量明显更多。

As noted in the section Ergonomics, ergonomics selects the garbage collector dynamically to provide good performance on a variety of applications. The serial garbage collector is designed for applications with small data sets, and its default parameters were chosen to be effective for most small applications. The parallel or throughput garbage collector is meant to be used with applications that have medium to large data sets. The heap size parameters selected by ergonomics plus the features of the adaptive size policy are meant to provide good performance for server applications. These choices work well in most, but not all, cases, which leads to the central tenet of this document:

如Ergonomics部分所述，Ergonomics动态选择垃圾收集器以在各种应用中提供良好的性能。串行垃圾收集器专为具有小数据集的应用程序而设计，选择默认参数为对大多数小型应用程序有效。并行或吞吐量垃圾收集器旨在用于具有大中型数据集的应用程序。Ergonomics选择的堆大小参数加上自适应大小策略的功能旨在为服务器应用程序提供良好的性能。这些选择在大多数（但不是全部）情况下都能很好地发挥作用，这就是本文的核心原则：

Figure 3-2, "Default Arrangement of Generations, Except for Parallel Collector and G1" shows the default arrangement of generations (for all collectors with the exception of the parallel collector and G1):

其他代的默认排列”显示了代的默认排列（对于除并行收集器和G1之外的所有收集器）：

Figure 3-2 Default Arrangement of Generations, Except for Parallel Collector and G1

Description of "Figure 3-2 Default Arrangement of Generations, Except for Parallel Collector and G1"

At initialization, a maximum address space is virtually reserved but not allocated to physical memory unless it is needed. The complete address space reserved for object memory can be divided into the young and tenured generations.

初始化时，虚拟机保留最大地址空间，但不分配给物理内存，除非需要。为对象存储器保留的完整地址空间可分为年轻代和年老代。

The young generation consists of eden and two survivor spaces. Most objects are initially allocated in eden. One survivor space is empty at any time, and serves as the destination of any live objects in eden; the other survivor space is the destination during the next copying collection. Objects are copied between survivor spaces in this way until they are old enough to be tenured (copied to the tenured generation).

年轻代由eden和两个survivor者空间组成。大多数物体最初分配在eden（伊甸园）。一个survivor空间在任何时候都是空的，并且作为eden中任何活物的目的地; 另一个survivor空间是下一个复制收集期间的目的地。对象以这种方式在survivor空间之间复制，直到他们的年龄足以被终身（复制到年老代）。

Performance Considerations

There are two primary measures of garbage collection performance:

有两个垃圾收集性能的主要措施：

·        Throughput is the percentage of total time not spent in garbage collection considered over long periods of time. Throughput includes time spent in allocation (but tuning for speed of allocation is generally not needed).

Throughput是在长时间内考虑的垃圾收集总时间的百分比。吞吐量包括花在分配上的时间（但通常不需要调整分配速度）。

·        Pauses are the times when an application appears unresponsive because garbage collection is occurring.

Pauses是由于发生垃圾收集而导致应用程序无响应的时间

Users have different requirements of garbage collection. For example, some consider the right metric for a web server to be throughput because pauses during garbage collection may be tolerable or simply obscured by network latencies. However, in an interactive graphics program, even short pauses may negatively affect the user experience.

用户对垃圾收集有不同的要求。例如，有些人认为Web服务器正确的衡量指标是吞吐量，因为垃圾收集期间的暂停可能是容忍的，或者是可以被网络延迟所掩盖。但是，在交互式图形程序中，即使是短暂的暂停也会对用户体验产生负面影响。

Some users are sensitive to other considerations. Footprint is the working set of a process, measured in pages and cache lines. On systems with limited physical memory or many processes, footprint may dictate scalability. Promptness is the time between when an object becomes dead and when the memory becomes available, an important consideration for distributed systems, including Remote Method Invocation (RMI).

有些用户对其他考虑很敏感。Footprint（占用内存空间）是一个进程的工作集，以页面和缓存行来衡量。在物理内存有限或许多进程的系统上，占用空间可能决定可伸缩性。Promptness是指对象变为死亡和内存变为可用之间的时间间隔，这是分布式系统（包括远程方法调用（RMI））的一个重要考虑因素。

In general, choosing the size for a particular generation is a trade-off between these considerations. For example, a very large young generation may maximize throughput, but does so at the expense of footprint, promptness, and pause times. Young generation pauses can be minimized by using a small young generation at the expense of throughput. The sizing of one generation does not affect the collection frequency and pause times for another generation.

一般来说，选择特定代的规模是这些考虑之间的折衷。例如，一个非常大的年轻代可能会使吞吐量最大化，但是这会牺牲footprint，及时性和暂停时间。年轻代的停顿可以通过使用一个小的年轻代来减少吞吐量。一个代的大小不会影响另一个代的收集频率和暂停时间。

There is no one right way to choose the size of a generation. The best choice is determined by the way the application uses memory as well as user requirements. Thus the virtual machine's choice of a garbage collector is not always optimal and may be overridden with command-line options described in the section Sizing the Generations.

没有一个正确的方法来选择代的规模。最好的选择取决于应用程序使用内存的方式以及用户需求。因此，虚拟机对垃圾收集器的选择并不总是最佳的，并且可以通过调整世代中所述的命令行选项来覆盖。

Measurement

Throughput and footprint are best measured using metrics particular to the application. For example, the throughput of a web server may be tested using a client load generator, whereas the footprint of the server may be measured on the Solaris operating system using the pmap command. However, pauses due to garbage collection are easily estimated by inspecting the diagnostic output of the virtual machine itself.

吞吐量和footprint最好使用特定于应用程序的度量来衡量。例如，可以使用客户端负载生成器来测试Web服务器的吞吐量，也可以使用该pmap命令在Solaris操作系统上测量服务器的占用空间。但是，通过检查虚拟机本身的诊断输出，可以轻松地估计垃圾回收造成的暂停。

The command-line option -verbose:gc causes information about the heap and garbage collection to be printed at each collection. For example, here is output from a large server application:

命令行选项-verbose:gc会在每个集合中打印有关堆和垃圾回收的信息。例如，以下是来自大型服务器应用程序的输出：

[GC 325407K->83000K(776768K), 0.2300771 secs]

[GC 325816K->83372K(776768K), 0.2454258 secs]

[Full GC 267628K->83769K(776768K), 1.8479984 secs]

The output shows two minor collections followed by one major collection. The numbers before and after the arrow (for example, 325407K->83000K from the first line) indicate the combined size of live objects before and after garbage collection, respectively. After minor collections, the size includes some objects that are garbage (no longer alive) but cannot be reclaimed. These objects are either contained in the tenured generation or referenced from the tenured generation.

输出显示两个minor collections，后面跟着一个major collection。箭头之前和之后的数字（例如，325407K->83000K从第一行开始）分别表示垃圾收集之前和之后的活动对象的总大小。在minor collections之后，大小包括一些垃圾（不再活动）但不能回收的对象。这些对象要么包含在年老代中，要么是被年老代中引用的。

The next number in parentheses (for example, (776768K) again from the first line) is the committed size of the heap: the amount of space usable for Java objects without requesting more memory from the operating system. Note that this number only includes one of the survivor spaces. Except during a garbage collection, only one survivor space will be used at any given time to store objects.

括号中的下一个数字（例如，(776768K)再次来自第一行）是堆的目标大小：可用于Java对象的需求的空间量，无需从操作系统请求更多内存。请注意，这个数字只包含其中一个幸存者空间。除了在垃圾回收期间，在任何给定时间只有一个幸存者空间将用于存储对象。

The last item on the line (for example, 0.2300771 secs) indicates the time taken to perform the collection, which is in this case approximately a quarter of a second.
线上的最后一项（例如，0.2300771 secs）表示执行收集所花费的时间，在这种情况下约为四分之一秒。

The format for the major collection in the third line is similar.

第三行major collection的格式。

The command-line option -XX:+PrintGCDetails causes additional information about the collections to be printed. An example of the output with -XX:+PrintGCDetails using the serial garbage collector is shown here.

命令行选项-XX:+PrintGCDetails会导致打印有关集合的其他信息。-XX:+PrintGCDetails这里显示了使用串行垃圾回收器的输出示例。

[GC [DefNew: 64575K->959K(64576K), 0.0457646 secs] 196016K->133633K(261184K), 0.0459067 secs]

This indicates that the minor collection recovered about 98% of the young generation, DefNew:

64575K->959K(64576K) and took 0.0457646 secs (about 45 milliseconds).

这表明小收集回收了约98％的年轻一代，DefNew: 64575K->959K(64576K)并花了0.0457646 secs（约45毫秒）。

The usage of the entire heap was reduced to about 51% (196016K->133633K(261184K)), and there was some slight additional overhead for the collection (over and above the collection of the young generation) as indicated by the final time of 0.0459067 secs.

整个堆的使用减少到大约51％（196016K->133633K(261184K)），并且如最后的时间所表明的那样，该集合有一些额外的额外开销（超过年轻一代的收集）0.0459067 secs。

The option -XX:+PrintGCTimeStamps adds a time stamp at the start of each collection. This is useful to see how frequently garbage collections occur.

该选项-XX:+PrintGCTimeStamps在每个集合的开始处添加一个时间戳。看看垃圾收集发生的频率很有用。

111.042: [GC 111.042: [DefNew: 8128K->8128K(8128K), 0.0000505 secs]111.042: [Tenured: 18154K->2311K(24576K), 0.1290354 secs] 26282K->2311K(32704K), 0.1293306 secs]

The collection starts about 111 seconds into the execution of the application. The minor collection starts at about the same time. Additionally, the information is shown for a major collection delineated by Tenured. The tenured generation usage was reduced to about 10% (18154K->2311K(24576K)) and took 0.1290354 secs (approximately 130 milliseconds).

收集开始大约111秒进入应用程序的执行。minor collection大约在同一时间开始。此外，信息显示为由Tenured描绘的主要收集。终身代用量减少到约10％（18154K->2311K(24576K)），并花费了0.1290354 secs大约130毫秒。

Sizing the Generations

A number of parameters affect generation size. Figure 4-1, "Heap Parameters" illustrates the difference between committed space and virtual space in the heap. At initialization of the virtual machine, the entire space for the heap is reserved. The size of the space reserved can be specified with the -Xmx option. If the value of the -Xms parameter is smaller than the value of the -Xmx parameter, than not all of the space that is reserved is immediately committed to the virtual machine. The uncommitted space is labeled "virtual" in this figure. The different parts of the heap (tenured generation and young generation) can grow to the limit of the virtual space as needed.

许多参数影响代的大小。图4-1“堆参数”说明了堆中已提交空间和虚拟空间之间的区别。在虚拟机初始化时，堆的整个空间都被保留。预留空间的大小可以通过-Xmx选项指定。如果-Xms参数的值小于-Xmx参数的值，则-Xmx不是所有保留的空间都会立即提交给虚拟机。该图中未提交的空间被标记为“虚拟”。堆的不同部分（年老代和年轻代）可根据需要增长到虚拟空间的极限。

Some of the parameters are ratios of one part of the heap to another. For example the parameter NewRatio denotes the relative size of the tenured generation to the young generation.

一些参数是堆的一部分与另一部分的比率。例如，参数NewRatio表示年老代对年轻代的相对规模。

Figure 4-1 Heap Parameters

Description of "Figure 4-1 Heap Parameters"

Total Heap

The following discussion regarding growing and shrinking of the heap and default heap sizes does not apply to the parallel collector. (See the section Parallel Collector Ergonomics in Sizing the Generations for details on heap resizing and default heap sizes with the parallel collector.) However, the parameters that control the total size of the heap and the sizes of the generations do apply to the parallel collector.

以下有关堆和默认堆大小增长和缩小的讨论不适用于并行收集器。（见节Parallel Collector Ergonomics在Sizing the Generations对堆调整大小和缺省堆大小与并行收集的信息。）然而，控制堆的总大小和各代的尺寸的参数确实适用于并行收集。

The most important factor affecting garbage collection performance is total available memory. Because collections occur when generations fill up, throughput is inversely proportional to the amount of memory available.

影响垃圾回收性能的最重要因素是总可用内存。由于回收发生在代填满时，吞吐量与可用内存量成反比。

By default, the virtual machine grows or shrinks the heap at each collection to try to keep the proportion of free space to live objects at each collection within a specific range. This target range is set as a percentage by the parameters -XX:MinHeapFreeRatio=<minimum> and -XX:MaxHeapFreeRatio=<maximum>, and the total size is bounded below by -Xms<min> and above by -Xmx<max>. The default parameters for the 64-bit Solaris operating system (SPARC Platform Edition) are shown in Table 4-1, "Default Parameters for 64-Bit Solaris Operating System":

默认情况下，虚拟机会在每个集合上增大或缩小堆以尝试在特定范围内的每个集合中保留可用空间与活动对象的比例。此目标范围设定为由参数百分比-XX:MinHeapFreeRatio=<minimum>和-XX:MaxHeapFreeRatio=<maximum>，并且总尺寸由下界限-Xms<min>及以上-Xmx<max>。表4-1“64位Solaris操作系统的默认参数”中显示了64位Solaris操作系统（SPARC平台版）的默认参数：

Table 4-1 Default Parameters for 64-Bit Solaris Operating System

Parameter	Default Value
MinHeapFreeRatio	40
MaxHeapFreeRatio	70
-Xms	6656k
-Xmx	calculated

With these parameters, if the percent of free space in a generation falls below 40%, then the generation will be expanded to maintain 40% free space, up to the maximum allowed size of the generation. Similarly, if the free space exceeds 70%, then the generation will be contracted so that only 70% of the space is free, subject to the minimum size of the generation.

使用这些参数，如果代中的可用空间百分比低于40％，那么这个代将扩展到保持40％的可用空间，达到最大允许的最大容量。同样，如果空闲空间超过70％，那么这个代将收缩，只有70％的空间是不受限的，受限于这一代的最小规模。

As noted in Table 4-1, "Default Parameters for 64-Bit Solaris Operating System", the default maximum heap size is a value that is calculated by the JVM. The calculation used in Java SE for the parallel collector and the server JVM are now used for all the garbage collectors. Part of the calculation is an upper limit on the maximum heap size that is different for 32-bit platforms and 64-bit platforms. See the section Default Heap Size in The Parallel Collector. There is a similar calculation for the client JVM, which results in smaller maximum heap sizes than for the server JVM.

如表4-1“64位Solaris操作系统的默认参数”中所述，默认最大堆大小是由JVM计算的值。Java SE中用于并行收集器和服务器JVM的计算现在用于所有垃圾收集器。部分计算是针对32位平台和64位平台而言不同的最大堆大小的上限。请参阅并行收集器中的默认堆大小一节。对于客户端JVM有一个类似的计算，这会导致最大堆大小比服务器JVM小。

The following are general guidelines regarding heap sizes for server applications:

以下是有关服务器应用程序的堆大小的一般准则：

·        Unless you have problems with pauses, try granting as much memory as possible to the virtual machine. The default size is often too small.

除非您遇到pauses问题，否则请尝试为虚拟机授予尽可能多的内存。默认大小通常太小。

·        Setting -Xms and -Xmx to the same value increases predictability by removing the most important sizing decision from the virtual machine. However, the virtual machine is then unable to compensate if you make a poor choice.

设置-Xms和-Xmx相同的值通过从虚拟机中删除最重要的尺寸决定来提高可预测性。但是，如果您做出糟糕的选择，虚拟机将无法补偿。

·        In general, increase the memory as you increase the number of processors, since allocation can be parallelized.

一般来说，增加进程的数量会增加内存，因为分配可以并行化。

The Young Generation

After total available memory, the second most influential factor affecting garbage collection performance is the proportion of the heap dedicated to the young generation. The bigger the young generation, the less often minor collections occur. However, for a bounded heap size, a larger young generation implies a smaller tenured generation, which will increase the frequency of major collections. The optimal choice depends on the lifetime distribution of the objects allocated by the application.

除了全部可用内存，影响垃圾收集性能的第二大影响因素是专用于年轻代的堆的比例。年轻代越大，minor collections越少。然而，对于有限的堆大小，年轻代更大意味着更小的年老代，这将增加主major collections的频率。最佳选择取决于应用程序分配的对象的生命周期分布。

By default, the young generation size is controlled by the parameter NewRatio. For example, setting -XX:NewRatio=3 means that the ratio between the young and tenured generation is 1:3. In other words, the combined size of the eden and survivor spaces will be one-fourth of the total heap size.

默认情况下，年轻代的大小由参数控制NewRatio。例如，设置-XX:NewRatio=3意味着年轻代和老代之间的比例是1：3。换句话说，eden and survivor（伊甸园和幸存者）空间的组合大小将是堆总大小的四分之一。

The parameters NewSize and MaxNewSize bound the young generation size from below and above. Setting these to the same value fixes the young generation, just as setting -Xms and -Xmx to the same value fixes the total heap size. This is useful for tuning the young generation at a finer granularity than the integral multiples allowed by NewRatio.

参数NewSize和MaxNewSize从下面和上面限制年轻代的大小。将这些设置为相同的值可以固定年轻代大小，正如设置-Xms和-Xmx相同的值可以固定堆的总大小一样。这对于以比允许的整数倍（NewRatio）更精细的粒度调整年轻代很有用。

Survivor Space Sizing

You can use the parameter SurvivorRatio can be used to tune the size of the survivor spaces, but this is often not important for performance. For example, -XX:SurvivorRatio=6 sets the ratio between and a survivor space to 1:6. In other words, each survivor space will be one-sixth the size of eden, and thus one-eighth the size of the young generation (not one-seventh, because there are two survivor spaces).

您可以使用SurvivorRatio可用于调整存活空间大小的参数，但这对性能通常不重要。例如，-XX:SurvivorRatio=6将幸存者和伊甸园空间之间的比率设置为1：6。换句话说，每个幸存者的空间将是伊甸园的六分之一，因此是年轻一代的八分之一（不是七分之一，因为有两个幸存者空间）。Survivor/ eden

If survivor spaces are too small, copying collection overflows directly into the tenured generation. If survivor spaces are too large, they will be uselessly empty. At each garbage collection, the virtual machine chooses a threshold number, which is the number times an object can be copied before it is tenured. This threshold is chosen to keep the survivors half full. The command line option -XX:+PrintTenuringDistribution (not available on all garbage collectors) can be used to show this threshold and the ages of objects in the new generation. It is also useful for observing the lifetime distribution of an application.

如果幸存者空间太小，则直接将收集溢出复制到年老代。如果幸存者空间太大，他们将无用空。在每次垃圾回收时，虚拟机会选择一个阈值数量，这是在对象被使用之前可以复制的次数。选择这个阈值是为了让幸存者保持半满状态。命令行选项-XX:+PrintTenuringDistribution（在所有垃圾收集器上不可用）可用于显示新阈值和新一代对象的年龄。这对于观察应用程序的生命周期分布也很有用。

Table 4-2, "Default Parameter Values for Survivor Space Sizing" provides the default values for 64-bit Solaris:

Table 4-2 Default Parameter Values for Survivor Space Sizing

Parameter	Server JVM Default Value
NewRatio	2
NewSize	1310M
MaxNewSize	not limited
SurvivorRatio	8

The maximum size of the young generation will be calculated from the maximum size of the total heap and the value of the NewRatio parameter. The "not limited" default value for the MaxNewSize parameter means that the calculated value is not limited by MaxNewSize unless a value for MaxNewSize is specified on the command line.

年轻代的最大值将根据总堆的最大值和NewRatio参数的值计算。MaxNewSize参数的”默认值为“不受限制”意味着计算值不受限制，MaxNewSize除非MaxNewSize在命令行上指定了值。

The following are general guidelines for server applications:

以下是服务器应用程序的一般准则：

·        First decide the maximum heap size you can afford to give the virtual machine. Then plot your performance metric against young generation sizes to find the best setting.

首先确定您可以承担的虚拟机的最大堆大小。然后根据年轻代的绘制性能指标以找到最佳设置。

o   Note that the maximum heap size should always be smaller than the amount of memory installed on the machine to avoid excessive page faults and thrashing.

请注意，最大堆大小应始终小于计算机上安装的内存量，以避免内存页过度使用和抖动

·        If the total heap size is fixed, then increasing the young generation size requires reducing the tenured generation size. Keep the tenured generation large enough to hold all the live data used by the application at any given time, plus some amount of slack space (10 to 20% or more).

如果总堆大小是固定的，那么增加年轻代的大小就需要缩短年老代。保持年老代足够大以容纳应用程序在任何给定时间使用的所有实时数据，以及保留一些松散空间（10％到20％或更多）

·        Subject to the previously stated constraint on the tenured generation:

根据以前对年老代的约束：

·        Grant plenty of memory to the young generation.（为年轻代提供充足的内存）

o   Increase the young generation size as you increase the number of processors, because allocation can be parallelized.

随着处理器数量的增加，增加年轻代的规模，因为分配可以并行化。

Available Collectors

The discussion to this point has been about the serial collector. The Java HotSpot VM includes three different types of collectors, each with different performance characteristics.

关于这一点的讨论是关于串行收集器的。Java HotSpot VM包含三种不同类型的收集器，每种收集器都具有不同的性能特征。

·        The serial collector uses a single thread to perform all garbage collection work, which makes it relatively efficient because there is no communication overhead between threads. It is best-suited to single processor machines, because it cannot take advantage of multiprocessor hardware, although it can be useful on multiprocessors for applications with small data sets (up to approximately 100 MB). The serial collector is selected by default on certain hardware and operating system configurations, or can be explicitly enabled with the option -XX:+UseSerialGC.

串行收集器使用单个线程执行所有垃圾收集工作，这使得它相对高效，因为线程之间没有通信开销。它最适合于单处理器机器，因为它不能利用多处理器硬件，尽管对于具有小数据集（高达大约100 MB）的应用程序，它可能对多处理器很有用。串行收集器在某些硬件和操作系统配置中默认选中，或者可以使用该选项明确启用-XX:+UseSerialGC。

·        The parallel collector (also known as the throughput collector) performs minor collections in parallel, which can significantly reduce garbage collection overhead. It is intended for applications with medium-sized to large-sized data sets that are run on multiprocessor or multithreaded hardware. The parallel collector is selected by default on certain hardware and operating system configurations, or can be explicitly enabled with the option -XX:+UseParallelGC.

 并行收集器（也称为吞吐量收集器）并行执行次要收集，这可以显着减少垃圾收集开销。它适用于在多处理器或多线程硬件上运行的中型到大型数据集的应用程序。并行收集器在某些硬件和操作系统配置上默认选中，或者可以使用该选项明确启用-XX:+UseParallelGC。

o   Parallel compaction is a feature that enables the parallel collector to perform major collections in parallel. Without parallel compaction, major collections are performed using a single thread, which can significantly limit scalability. Parallel compaction is enabled by default if the option -XX:+UseParallelGC has been specified. The option to turn it off is -XX:-UseParallelOldGC.

并行压缩是一个使并行采集器能够并行执行主要采集的功能。如果没有并行压缩，主要集合将使用单个线程执行，这可能会极大地限制可伸缩性。如果-XX:+UseParallelGC指定了选项，则默认启用并行压缩。关闭它的选项是-XX:-UseParallelOldGC。

·        The mostly concurrent collector performs most of its work concurrently (for example, while the application is still running) to keep garbage collection pauses short. It is designed for applications with medium-sized to large-sized data sets in which response time is more important than overall throughput because the techniques used to minimize pauses can reduce application performance. The Java HotSpot VM offers a choice between two mostly concurrent collectors; see The Mostly Concurrent Collectors. Use the option -XX:+UseConcMarkSweepGC to enable the CMS collector or -XX:+UseG1GC to enable the G1 collector.

大多数并发收集器同时执行其大部分工作（例如，应用程序仍在运行时），以缩短垃圾收集暂停时间。它专为具有中等大小数据集的应用程序而设计，其响应时间比整体吞吐量更重要，因为用于最小化暂停的技术可能会降低应用程序的性能。Java HotSpot VM提供了两种主要并发的收集器之间的选择; 请参阅大多数并发收集器。使用该选项-XX:+UseConcMarkSweepGC启用CMS收集器或-XX:+UseG1GC启用G1收集器。

Selecting a Collector

Unless your application has rather strict pause time requirements, first run your application and allow the VM to select a collector. If necessary, adjust the heap size to improve performance. If the performance still does not meet your goals, then use the following guidelines as a starting point for selecting a collector.

除非您的应用程序具有相当严格的暂停时间要求，否则请先运行您的应用程序并允许VM选择收集器。如有必要，请调整堆大小以提高性能。如果性能仍不能达到您的目标，请使用以下指南作为选择收集器的起点。

·        If the application has a small data set (up to approximately 100 MB), then

select the serial collector with the option -XX:+UseSerialGC.

如果应用程序有一个小数据集（最多大约100 MB），那么用选项选择串行收集器-XX:+UseSerialGC。

·        If the application will be run on a single processor and there are no pause time requirements, then let the VM select the collector, or select the serial collector with the option -XX:+UseSerialGC.

如果应用程序将在单个处理器上运行，并且没有暂停时间要求，则让VM选择收集器，或者使用该选项选择串行收集器-XX:+UseSerialGC。

·        If (a) peak application performance is the first priority and (b) there are no pause time requirements or pauses of 1 second or longer are acceptable, then let the VM select the collector, or select the parallel collector with -XX:+UseParallelGC.

如果（a）峰值应用程序性能是第一优先级并且（b）没有暂停时间要求或暂停1秒或更长时间是可接受的，则让VM选择收集器，或者选择并行收集器-XX:+UseParallelGC。

·        If response time is more important than overall throughput and garbage collection pauses must be kept shorter than approximately 1 second, then select the concurrent collector with -XX:+UseConcMarkSweepGC or -XX:+UseG1GC.

如果响应时间比整体吞吐量更重要，并且垃圾收集暂停时间必须短于大约1秒，那么使用-XX:+UseConcMarkSweepGC或选择并发收集器-XX:+UseG1GC。

These guidelines provide only a starting point for selecting a collector because performance is dependent on the size of the heap, the amount of live data maintained by the application, and the number and speed of available processors. Pause times are particularly sensitive to these factors, so the threshold of 1 second mentioned previously is only approximate: the parallel collector will experience pause times longer than 1 second on many data size and hardware combinations; conversely, the concurrent collector may not be able to keep pauses shorter than 1 second on some combinations.

这些准则仅提供选择收集器初始化，因为性能取决于堆的大小，应用程序维护的实时数据量以及可用处理器的数量和速度。暂停时间对这些因素特别敏感，因此前面提到的1秒阈值仅为近似值：在许多数据大小和硬件组合上，并行采集器的暂停时间会超过1秒;相反，并发收集器可能无法在某些组合上保持短于1秒的暂停。

If the recommended collector does not achieve the desired performance, first attempt to adjust the heap and generation sizes to meet the desired goals. If performance is still inadequate, then try a different collector: use the concurrent collector to reduce pause times and use the parallel collector to increase overall throughput on multiprocessor hardware.

如果推荐的收集器无法达到所需的性能，请首先尝试调整堆和代的大小以达到所需的目标。如果性能仍然不足，请尝试使用其他收集器：使用并发收集器来减少暂停时间，并使用并行收集器来提高多处理器硬件的整体吞吐量。

The Parallel Collector

The parallel collector (also referred to here as the throughput collector) is a generational collector similar to the serial collector; the primary difference is that multiple threads are used to speed up garbage collection. The parallel collector is enabled with the command-line option -XX:+UseParallelGC. By default, with this option, both minor and major collections are executed in parallel to further reduce garbage collection overhead.

并行收集器（这里也称为吞吐量收集器）是类似于串行收集器的分代收集器; 主要的区别是多线程用于加速垃圾收集。并行收集器通过命令行选项启用-XX:+UseParallelGC。默认情况下，使用此选项，并行执行次要集合和主要集合以进一步减少垃圾回收开销。

On a machine with N hardware threads where N is greater than 8, the parallel collector uses a fixed fraction of N as the number of garbage collector threads. The fraction is approximately 5/8 for large values of N. At values of N below 8, the number used is N. On selected platforms, the fraction drops to 5/16. The specific number of garbage collector threads can be adjusted with a command-line option (which is described later). On a host with one processor, the parallel collector will likely not perform as well as the serial collector because of the overhead required for parallel execution (for example, synchronization). However, when running applications with medium-sized to large-sized heaps, it generally outperforms the serial collector by a modest amount on machines with two processors, and usually performs significantly better than the serial collector when more than two processors are available.

在具有N个硬件线程（其中N大于8）的计算机上，并行收集器使用N个固定的线程作为垃圾收集器线程的数量。对于较大的N值，比例约为5/8 。在N低于8的值处，使用的数字是N.。在选定的平台上，比例下降到5/16。垃圾收集器线程的具体数量可以通过命令行选项进行调整（稍后介绍）。在具有一个处理器的主机上，由于并行执行所需的开销（例如同步），并行收集器的性能可能不如串行收集器。但是，在运行具有中等到大型堆的应用程序时，它通常在具有两个处理器的机器上的性能优于串行收集器，并且在两个以上的处理器可用时，通常性能会优于串行收集器。

The number of garbage collector threads can be controlled with the command-line option -XX:ParallelGCThreads=<N>. If explicit tuning of the heap is being done with command-line options, then the size of the heap needed for good performance with the parallel collector is the same as needed with the serial collector. However, enabling the parallel collector should make the collection pauses shorter. Because multiple garbage collector threads are participating in a minor collection, some fragmentation is possible due to promotions from the young generation to the tenured generation during the collection. Each garbage collection thread involved in a minor collection reserves a part of the tenured generation for promotions and the division of the available space into these "promotion buffers" can cause a fragmentation effect. Reducing the number of garbage collector threads and increasing the size of the tenured generation will reduce this fragmentation effect.

垃圾回收器线程的数量可以通过命令行选项进行控制 -XX:ParallelGCThreads=<N>。如果使用命令行选项对堆进行显式调整，那么使用并行收集器获得良好性能所需的堆大小与串行收集器所需的大小相同。但是，启用并行收集器应该缩短收集时间。由于多个垃圾收集器线程正在参与minor回收，因此在收集期间由于从年轻代到年老代的转化而导致一些碎片化。涉及minor回收的每个垃圾收集线程都会保留一部分用于转化的年老代的生成，并将可用空间划分到这些“提升缓冲区”中会导致分段效应。

Generations

As mentioned earlier, the arrangement of the generations is different in the parallel collector. That arrangement is shown in Figure 6-1, "Arrangement of Generations in the Parallel Collector":

如前所述，并行收集器中代的排列是不同的。图6-1“并行收集器中的发生器排列”中显示了这种安排：

Figure 6-1 Arrangement of Generations in the Parallel Collector

Description of "Figure 6-1 Arrangement of Generations in the Parallel Collector"

Parallel Collector Ergonomics

The parallel collector is selected by default on server-class machines. In addition, the parallel collector uses a method of automatic tuning that allows you to specify specific behaviors instead of generation sizes and other low-level tuning details. You can specify maximum garbage collection pause time, throughput, and footprint (heap size).

并行收集器在服务器级机器上默认选中。此外，并行收集器使用自动调整方法，允许您指定特定行为而不是大小和其他低级调整详细信息。您可以指定最大垃圾收集暂停时间，吞吐量和占用空间（堆大小）。

·        Maximum Garbage Collection Pause Time: The maximum pause time goal is specified with the command-line option -XX:MaxGCPauseMillis=<N>. This is interpreted as a hint that pause times of <N> milliseconds or less are desired; by default, there is no maximum pause time goal. If a pause time goal is specified, the heap size and other parameters related to garbage collection are adjusted in an attempt to keep garbage collection pauses shorter than the specified value. These adjustments may cause the garbage collector to reduce the overall throughput of the application, and the desired pause time goal cannot always be met.

最大垃圾收集暂停时间：通过命令行选项指定最大暂停时间目标-XX:MaxGCPauseMillis=<N>。这被解释为希望暂停时间为<N>毫秒或更短的提示; 默认情况下，没有最大暂停时间目标。如果指定了暂停时间目标，则会调整与垃圾收集相关的堆大小和其他参数，以尝试使垃圾收集暂停时间短于指定值。这些调整可能会导致垃圾收集器降低应用程序的整体吞吐量，并且并不能保证始终满足所需的暂停时间目标。

·        Throughput: The throughput goal is measured in terms of the time spent doing garbage collection versus the time spent outside of garbage collection (referred to as application time). The goal is specified by the command-line option -XX:GCTimeRatio=<N>, which sets the ratio of garbage collection time to application time to 1 / (1 + <N>).

吞吐量目标是根据进行垃圾收集的时间与垃圾收集以外的时间（称为应用程序时间）来衡量的。目标由命令行选项指定，该选项-XX:GCTimeRatio=<N>设置垃圾收集时间与应用程序时间的比率1 / (1 + <N>)。

For example, -XX:GCTimeRatio=19 sets a goal of 1/20 or 5% of the total time in garbage collection. The default value is 99, resulting in a goal of 1% of the time in garbage collection.

-XX:GCTimeRatio=19在垃圾收集中设定1/20或5％的总时间。默认值为99，则垃圾收集时间的目标为1％。

·        Footprint: Maximum heap footprint is specified using the option -Xmx<N>. In addition, the collector has an implicit goal of minimizing the size of the heap as long as the other goals are being met.

最大堆占用空间使用选项指定-Xmx<N>。另外，只要其他目标得到满足，收集器就有一个隐含的目标，即尽可能减小堆的大小。

·       

Priority of Goals

The goals are addressed in the following order:

1.      Maximum pause time goal

2.      Throughput goal

3.      Minimum footprint goal

The maximum pause time goal is met first. Only after it is met is the throughput goal addressed. Similarly, only after the first two goals have been met is the footprint goal considered.

目标按以下顺序处理：

1.      最大暂停时间目标

2.      吞吐量目标

3.      最小的占用空间目标

首先满足最大暂停时间目标。只有满足后才能解决吞吐量目标。同样，只有在前两个目标得到满足之后才考虑占用空间目标。

Generation Size Adjustments

The statistics such as average pause time kept by the collector are updated at the end of each collection. The tests to determine if the goals have been met are then made and any needed adjustments to the size of a generation is made. The exception is that explicit garbage collections (for example, calls to System.gc()) are ignored in terms of keeping statistics and making adjustments to the sizes of generations.

回收器保存的平均暂停时间等统计信息在每次收集结束时更新。然后进行测试以确定目标是否已经达到，并且对代的大小进行任何所需的调整。例外情况是，显式垃圾回收（例如调用System.gc()）在保留统计数据和调整代大小方面被忽略。

Growing and shrinking the size of a generation is done by increments that are a fixed percentage of the size of the generation so that a generation steps up or down toward its desired size. Growing and shrinking are done at different rates. By default a generation grows in increments of 20% and shrinks in increments of 5%. The percentage for growing is controlled by the command-line option -XX:YoungGenerationSizeIncrement=<Y> for the young generation and -XX:TenuredGenerationSizeIncrement=<T> for the tenured generation. The percentage by which a generation shrinks is adjusted by the command-line flag -XX:AdaptiveSizeDecrementScaleFactor=<D>. If the growth increment is X percent, then the decrement for shrinking is X/D percent.

增长和缩小代的规模是通过增加一定的百分比来实现的，这样代就可以上升或下降到所需的大小。增长和收缩都是以不同的速度完成的。默认情况下，代以20％的增量增长并以5％的增量收缩。增长的百分比由-XX:YoungGenerationSizeIncrement=<Y>年轻代和-XX:TenuredGenerationSizeIncrement=<T>年老代的命令行选项控制。代缩小的百分比通过命令行标志进行调整-XX:AdaptiveSizeDecrementScaleFactor=<D>。如果增长率为X百分比，那么收缩的减少量为X/D.

If the collector decides to grow a generation at startup, then there is a supplemental percentage is added to the increment. This supplement decays with the number of collections and has no long-term effect. The intent of the supplement is to increase startup performance. There is no supplement to the percentage for shrinking.

如果收集器决定在启动时增长一代，则会在增量中添加一个补充百分比。这个补充随回收数量而衰减并且不会产生长期影响。补充的目的是提高启动时性能。缩小的百分比是没有补充。

If the maximum pause time goal is not being met, then the size of only one generation is shrunk at a time. If the pause times of both generations are above the goal, then the size of the generation with the larger pause time is shrunk first.

如果最大暂停时间目标未达到，则仅缩小代的大小。如果年轻代和年老代的暂停时间都高于目标，那么具有较大暂停时间会将代的大小将首先缩小。

If the throughput goal is not being met, the sizes of both generations are increased. Each is increased in proportion to its respective contribution to the total garbage collection time. For example, if the garbage collection time of the young generation is 25% of the total collection time and if a full increment of the young generation would be by 20%, then the young generation would be increased by 5%.

如果吞吐量目标未得到满足，则两个代的规模都会增加。每个垃圾收集时间的比例都会增加。例如，如果年轻代的垃圾收集时间是总收集时间的25％，并且如果年轻代的全部增量将是20％，则年轻代将增加5％。

Default Heap Size

Unless the initial and maximum heap sizes are specified on the command line, they are calculated based on the amount of memory on the machine.

除非在命令行上指定了初始和最大堆大小，否则将根据机器上的内存量计算它们。

Client JVM Default Initial and Maximum Heap Sizes

The default maximum heap size is half of the physical memory up to a physical memory size of 192 megabytes (MB) and otherwise one fourth of the physical memory up to a physical memory size of 1 gigabyte (GB).

物理内存的默认最大堆大小为物理内存的一半，最大物理内存大小为192 MB，否则为物理内存的四分之一，直至物理内存大小为1 GB。

For example, if your computer has 128 MB of physical memory, then the maximum heap size is 64 MB, and greater than or equal to 1 GB of physical memory results in a maximum heap size of 256 MB.

例如，如果您的计算机具有128 MB物理内存，则最大堆大小为64 MB，大于或等于1 GB物理内存会导致最大堆大小为256 MB。

The maximum heap size is not actually used by the JVM unless your program creates enough objects to require it. A much smaller amount, called the initial heap size, is allocated during JVM initialization. This amount is at least 8 MB and otherwise 1/64th of physical memory up to a physical memory size of 1 GB.

除非您的程序创建了足够的对象来请求它，否则JVM不会实际使用最大堆大小。在JVM初始化期间分配的数量小得多，称为初始堆大小。该数量至少为8 MB，否则为物理内存的1/64，最大物理内存大小为1 GB。

The maximum amount of space allocated to the young generation is one third of the total heap size.

分配给年轻代的最大空间大小是总堆大小的三分之一。

Server JVM Default Initial and Maximum Heap Sizes

The default initial and maximum heap sizes work similarly on the server JVM as it does on the client JVM, except that the default values can go higher. On 32-bit JVMs, the default maximum heap size can be up to 1 GB if there is 4 GB or more of physical memory. On 64-bit JVMs, the default maximum heap size can be up to 32 GB if there is 128 GB or more of physical memory. You can always set a higher or lower initial and maximum heap by specifying those values directly; see the next section.

缺省初始和最大堆大小在服务器JVM上的工作方式与在客户端JVM上的工作方式类似，但默认值可以更高。在32位JVM上，如果有4 GB或更多的物理内存，默认最大堆大小可以高达1 GB。在64位JVM上，如果有128 GB或更多的物理内存，默认最大堆大小可以高达32 GB。您可以通过直接指定这些值来始终设置更高或更低的初始和最大堆; 请参阅下一节。

Specifying Initial and Maximum Heap Sizes

You can specify the initial and maximum heap sizes using the flags -Xms (initial heap size) and -Xmx (maximum heap size). If you know how much heap your application needs to work well, you can set -Xms and -Xmx to the same value. If not, the JVM will start by using the initial heap size and will then grow the Java heap until it finds a balance between heap usage and performance.

您可以使用标志-Xms（初始堆大小）和-Xmx（最大堆大小）指定初始堆大小和最大堆大小。如果您知道您的应用程序需要多少堆才能正常工作，则可以设置-Xms和-Xmx使用相同的值。否则，JVM将使用初始堆大小开始，然后增大Java堆直到在堆使用率和性能之间找到平衡。

Other parameters and options can affect these defaults. To verify your default values, use the -XX:+PrintFlagsFinal option and look for MaxHeapSize in the output. For example, on Linux or Solaris, you can run the following:

java -XX:+PrintFlagsFinal <GC options> -version | grep MaxHeapSize

其他参数和选项可能会影响这些默认设置。要验证您的默认值，请使用该-XX:+PrintFlagsFinal选项并MaxHeapSize在输出中查找。例如，在Linux或Solaris上，可以运行以下命令：

java -XX：+ PrintFlagsFinal <GC options> -version | grep MaxHeapSize

Excessive GC Time and OutOfMemoryError

The parallel collector throws an OutOfMemoryError if too much time is being spent in garbage collection (GC): If more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, then an OutOfMemoryError is thrown. This feature is designed to prevent applications from running for an extended period of time while making little or no progress because the heap is too small. If necessary, this feature can be disabled by adding the option -XX:-UseGCOverheadLimit to the command line.

GC时间过长和OutOfMemory错误

OutOfMemoryError如果在垃圾收集（GC）中花费了太多时间，并行收集器会抛出：如果超过总时间的98％用于垃圾收集，并且小于2％的堆被恢复，则抛出一个OutOfMemoryError。此功能旨在防止应用程序长时间运行，而由于堆太小，因此应用程序很少或没有工作。如有必要，可以通过将选项添加-XX:-UseGCOverheadLimit命令行来禁用此功能。

Measurements

The verbose garbage collector output from the parallel collector is essentially the same as that from the serial collector.

并行收集器的详细垃圾收集器输出与串行收集器的输出基本相同。

The Mostly Concurrent Collectors

Java Hotspot VM has two mostly concurrent collectors in JDK 8:

Java Hotspot VM在JDK 8中有两个主要并发的收集器：

·        Concurrent Mark Sweep (CMS) Collector: This collector is for applications that prefer shorter garbage collection pauses and can afford to share processor resources with the garbage collection.

并发标记扫描（CMS）收集器：此收集器适用于希望缩短垃圾收集暂停时间并能够与垃圾收集共享处理器资源的应用程序。

·        Garbage-First Garbage Collector: This server-style collector is for multiprocessor machines with large memories. It meets garbage collection pause time goals with high probability while achieving high throughput.

垃圾优先回收器：这种服务器式垃圾收集器适用于内存较大的多处理器机器。它以高概率满足垃圾收集暂停时间目标，同时实现高吞吐量。

Overhead of Concurrency

The mostly concurrent collector trades processor resources (which would otherwise be available to the application) for shorter major collection pause times. The most visible overhead is the use of one or more processors during the concurrent parts of the collection. On an N processor system, the concurrent part of the collection will use K/N of the available processors, where 1<=K<=ceiling{N/4}. (Note that the precise choice of and bounds on K are subject to change.) In addition to the use of processors during concurrent phases, additional overhead is incurred to enable concurrency. Thus while garbage collection pauses are typically much shorter with the concurrent collector, application throughput also tends to be slightly lower than with the other collectors.

大多数并发回收器通过交换处理器资源（否则可用于应用程序）以缩短主要收集暂停时间。最明显的开销是在收集的并发部分期间使用一个或多个处理器。在N处理器系统上，并发部分集合将使用可用处理器的K / N，其中1 <= K <= ceiling { N / 4}。（注意K上的精确选择和边界）除了在并行阶段使用处理器之外，还会产生额外的开销以实现并发。因此，虽然垃圾收集暂停通常比并发回收短得多，但应用程序吞吐量也往往略低于其他收集器。

On a machine with more than one processing core, processors are available for application threads during the concurrent part of the collection, so the concurrent garbage collector thread does not "pause" the application. This usually results in shorter pauses, but again fewer processor resources are available to the application and some slowdown should be expected, especially if the application uses all of the processing cores maximally. As N increases, the reduction in processor resources due to concurrent garbage collection becomes smaller, and the benefit from concurrent collection increases. The section Concurrent Mode Failure in Concurrent Mark Sweep (CMS) Collector discusses potential limits to such scaling.

在具有多个处理核心的计算机上，处理器可用于集合并发部分中的应用程序线程，因此并发垃圾收集器线程不会“暂停”应用程序。这通常会导致更短的暂停，但是应用程序可用的处理器资源也较少，应该会出现一些减速，尤其是在应用程序最大限度地使用所有处理核心的情况下。随着N的增加，由于并发垃圾收集导致的处理器资源减少变得更小，同时收集的收益也增加。的部分并行模故障在并发标记扫描（CMS）集电极讨论了这样的缩放潜在限制。

Because at least one processor is used for garbage collection during the concurrent phases, the concurrent collectors do not normally provide any benefit on a uniprocessor (single-core) machine. However, there is a separate mode available for CMS (not G1) that can achieve low pauses on systems with only one or two processors; see Incremental Mode in Concurrent Mark Sweep (CMS) Collector for details. This feature is being deprecated in Java SE 8 and may be removed in a later major release.

由于至少有一个处理器用于并发阶段的垃圾收集，因此并发收集器通常不会为单处理器（单核）机器提供任何好处。但是，对于CMS（不是G1），可以使用单处理器的模式，可以在只有一个或两个处理器的系统上实现低暂停; 看到增量模式在并发标记扫描（CMS）收集器的详细信息。此功能在Java SE 8中不推荐使用，并可能在以后的主要版本中删除。

Additional References

The Garbage-First Garbage Collector:

http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html

Garbage-First Garbage Collector Tuning:

http://www.oracle.com/technetwork/articles/java/g1gc-1984535.html

Concurrent Mark Sweep (CMS) Collector

The Concurrent Mark Sweep (CMS) collector is designed for applications that prefer shorter garbage collection pauses and that can afford to share processor resources with the garbage collector while the application is running. Typically applications that have a relatively large set of long-lived data (a large tenured generation) and run on machines with two or more processors tend to benefit from the use of this collector. However, this collector should be considered for any application with a low pause time requirement. The CMS collector is enabled with the command-line option -XX:+UseConcMarkSweepGC.

并发标记扫描（CMS）收集器专为那些希望缩短垃圾收集暂停时间并能够在应用程序运行时与垃圾回收器共享处理器资源的应用程序而设计。通常，具有相对较大的长寿命数据集合（大型年老代）并且在具有两个或更多处理器的机器上运行的应用程序倾向于从使用该收集器。但是，对于任何需要较短暂停时间的应用，都应考虑回收器的选择。使用命令行选项启用CMS收集器-XX:+UseConcMarkSweepGC。

Similar to the other available collectors, the CMS collector is generational; thus both minor and major collections occur. The CMS collector attempts to reduce pause times due to major collections by using separate garbage collector threads to trace the reachable objects concurrently with the execution of the application threads. During each major collection cycle, the CMS collector pauses all the application threads for a brief period at the beginning of the collection and again toward the middle of the collection. The second pause tends to be the longer of the two pauses. Multiple threads are used to do the collection work during both pauses. The remainder of the collection (including most of the tracing of live objects and sweeping of unreachable objects is done with one or more garbage collector threads that run concurrently with the application. Minor collections can interleave with an ongoing major cycle, and are done in a manner similar to the parallel collector (in particular, the application threads are stopped during minor collections).

与其他可用的回收器类似，CMS回收器是使用分代的; 因此发生次要和主要回收。CMS收集器通过使用单独的垃圾回收器线程跟踪，执行应用程序线程的可访问的对象，尝试减少主要收集造成的暂停时间。在每个主要收集周期中，CMS收集器会在收集开始时暂时将所有应用程序线程暂停一段时间，并再次收集到收集的中间。第二次停顿往往是两次暂停中较长的一次。在两次暂停期间，都使用多个线程完成收集工作。

Concurrent Mode Failure

The CMS collector uses one or more garbage collector threads that run simultaneously with the application threads with the goal of completing the collection of the tenured generation before it becomes full. As described previously, in normal operation, the CMS collector does most of its tracing and sweeping work with the application threads still running, so only brief pauses are seen by the application threads. However, if the CMS collector is unable to finish reclaiming the unreachable objects before the tenured generation fills up, or if an allocation cannot be satisfied with the available free space blocks in the tenured generation, then the application is paused and the collection is completed with all the application threads stopped. The inability to complete a collection concurrently is referred to as concurrent mode failure and indicates the need to adjust the CMS collector parameters. If a concurrent collection is interrupted by an explicit garbage collection (System.gc()) or for a garbage collection needed to provide information for diagnostic tools, then a concurrent mode interruption is reported.

并发模式故障

CMS收集器使用一个或多个与应用程序线程同时运行的垃圾收集器线程，目标是在已满的代中完成旧代的收集。如前所述，在正常操作中，CMS收集器在应用程序线程仍在运行的情况下执行大部分跟踪和清理工作，因此应用程序线程只能看到短暂暂停。但是，如果CMS收集器无法在代填满之前完成回收不可访问的对象，或者如果分配无法满足持久生成中的可用空闲块，则应用程序暂停并且收集完成所有的应用程序线程停止。无法同时完成集合被称为并发模式失败这表明需要调整CMS收集器参数。如果一个并发集合被显式垃圾回收（System.gc()）或一个为诊断工具提供信息所需的垃圾回收中断，则会报告并发模式中断。

Excessive GC Time and OutOfMemoryError

The CMS collector throws an OutOfMemoryError if too much time is being spent in garbage collection: if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, then an OutOfMemoryError is thrown. This feature is designed to prevent applications from running for an extended period of time while making little or no progress because the heap is too small. If necessary, this feature can be disabled by adding the option -XX:-UseGCOverheadLimit to the command line.

如果在垃圾收集过程中花费了太多时间，CMS收集器会抛出：OutOfMemoryError。如果超过总时间的98％用于垃圾收集，并且小于2％的堆被恢复，则抛出一个OutOfMemoryError。此功能旨在防止应用程序长时间运行，而由于堆太小，应用程序不工作或者是工作非常的慢。如有必要，可以通过将选项添加-XX:-UseGCOverheadLimit到命令行来禁用此功能。

The policy is the same as that in the parallel collector, except that time spent performing concurrent collections is not counted toward the 98% time limit. In other words, only collections performed while the application is stopped count toward excessive GC time. Such collections are typically due to a concurrent mode failure or an explicit collection request (for example, a call to System.gc).
该策略与并行收集器中的策略相同，只是执行并发集合的时间不计入98％的时间限制。换句话说，只有在应用程序停止时执行的收集才会占用过多的GC时间。这样的集合通常是由于并发模式失败或明确的收集请求（例如，调用System.gc）造成的。

Floating Garbage

The CMS collector, like all the other collectors in Java HotSpot VM, is a tracing collector that identifies at least all the reachable objects in the heap. In the parlance of Richard Jones and Rafael D. Lins in their publication Garbage Collection: Algorithms for Automated Dynamic Memory, it is an incremental update collector. Because application threads and the garbage collector thread run concurrently during a major collection, objects that are traced by the garbage collector thread may subsequently become unreachable by the time collection process ends. Such unreachable objects that have not yet been reclaimed are referred to as floating garbage. The amount of floating garbage depends on the duration of the concurrent collection cycle and on the frequency of reference updates, also known as mutations, by the application. Furthermore, because the young generation and the tenured generation are collected independently, each acts a source of roots to the other. As a rough guideline, try increasing the size of the tenured generation by 20% to account for the floating garbage. Floating garbage in the heap at the end of one concurrent collection cycle is collected during the next collection cycle.

与Java HotSpot VM中的所有其他收集器一样，CMS收集器也是一个跟踪收集器，用于标识堆中至少所有可到达的对象。在Richard Jones和Rafael D. Lins的出版物Garbage Collection：Algorithms for Automated Dynamic Memory中，它是一个增量更新收集器。由于应用程序线程和垃圾收集器线程在major collection期间并发运行，因此垃圾收集器线程所跟踪的对象随后可能在时间收集过程结束时变得无法访问。这种尚未被回收的不可达对象被称为浮动垃圾。漂浮垃圾的数量取决于同时收集周期的持续时间和应用程序的参考更新频率（也称为突变）。此外，由于年轻代和年老代是独立收集的，每个代都是另一方的根源。作为一个粗略的指导方针，尝试增加20％的年老代的大小来解决浮动垃圾。在下一个收集周期中收集一个并发收集周期结束时在堆中的浮动垃圾。

Pauses

The CMS collector pauses an application twice during a concurrent collection cycle. The first pause is to mark as live the objects directly reachable from the roots (for example, object references from application thread stacks and registers, static objects and so on) and from elsewhere in the heap (for example, the young generation). This first pause is referred to as the initial mark pause. The second pause comes at the end of the concurrent tracing phase and finds objects that were missed by the concurrent tracing due to updates by the application threads of references in an object after the CMS collector had finished tracing that object. This second pause is referred to as the remark pause.

CMS收集器在并发收集周期中暂停两次应用程序。第一个暂停是将从根直接可访问的对象（例如，应用程序线程堆栈和寄存器，静态对象等的对象引用）以及堆中其他位置（例如年轻一代）标记为活动。这第一次暂停被称为初始标记暂停。第二次暂停是在并发跟踪阶段结束时发现的，并且在CMS收集器完成跟踪该对象之后，由于对象中引用的应用程序线程的更新而找到由并发跟踪错过的对象。第二次暂停称为重标记暂停。

Concurrent Phases

The concurrent tracing of the reachable object graph occurs between the initial mark pause and the remark pause. During this concurrent tracing phase one or more concurrent garbage collector threads may be using processor resources that would otherwise have been available to the application. As a result, compute-bound applications may see a commensurate fall in application throughput during this and other concurrent phases even though the application threads are not paused. After the remark pause, a concurrent sweeping phase collects the objects identified as unreachable. Once a collection cycle completes, the CMS collector waits, consuming almost no computational resources, until the start of the next major collection cycle.

可达对象阶段的并发跟踪发生在初始标记暂停和标记暂停之间。在此并发跟踪阶段期间，一个或多个并发垃圾收集器线程可能正在使用本来可用于应用程序的处理器资源。因此，即使应用程序线程未暂停，计算绑定应用程序在此阶段和其他并发阶段中的应用程序吞吐量可能会出现相应的下降。标记暂停后，并发扫描阶段收集标识为不可访问的对象。一旦收集周期完成，CMS收集器就会等待，几乎不消耗计算资源，直到下一个主要收集周期开始。

Starting a Concurrent Collection Cycle

With the serial collector a major collection occurs whenever the tenured generation becomes full and all application threads are stopped while the collection is done. In contrast, the start of a concurrent collection must be timed such that the collection can finish before the tenured generation becomes full; otherwise, the application would observe longer pauses due to concurrent mode failure. There are several ways to start a concurrent collection.

使用串行收集器时，只要年老代满了并且收集完成时所有应用程序线程都停止，就会发生主要收集。相反，并发收集的开始必须定时，以便收集可以在年老代满之前完成; 否则，由于并发模式故障，应用程序会观察到更长的暂停。有几种方法可以启动并发收集。

Based on recent history, the CMS collector maintains estimates of the time remaining before the tenured generation will be exhausted and of the time needed for a concurrent collection cycle. Using these dynamic estimates, a concurrent collection cycle is started with the aim of completing the collection cycle before the tenured generation is exhausted. These estimates are padded for safety, because concurrent mode failure can be very costly.

根据最近的历史情况，CMS收集器维护着年老代将耗尽之前的剩余时间估计以及同时收集周期所需的时间。利用这些动态估算，开始并发采集循环，目的是在年老代用完之前完成采集周期。为了安全起见，这些估计值需要被指定，因为并发模式故障可能非常昂贵。

A concurrent collection also starts if the occupancy of the tenured generation exceeds an initiating occupancy (a percentage of the tenured generation). The default value for this initiating occupancy threshold is approximately 92%, but the value is subject to change from release to release. This value can be manually adjusted using the command-line option -XX:CMSInitiatingOccupancyFraction=<N>, where <N> is an integral percentage (0 to 100) of the tenured generation size.

并发收集也开始，如果年老代占用超过初始占用（年老代的百分比）。此启动占用率阈值的默认值大约为92％，但该值可能随发布版本而变化。可以使用命令行选项手动调整此值-XX:CMSInitiatingOccupancyFraction=<N>，其中<N>是占用代生成数的整数百分比（0到100）。

Scheduling Pauses

The pauses for the young generation collection and the tenured generation collection occur independently. They do not overlap, but may occur in quick succession such that the pause from one collection, immediately followed by one from the other collection, can appear to be a single, longer pause. To avoid this, the CMS collector attempts to schedule the remark pause roughly midway between the previous and next young generation pauses. This scheduling is currently not done for the initial mark pause, which is usually much shorter than the remark pause.

年轻代回收和年老代的暂停是独立发生的。它们不重叠，但可能会快速连续发生，这样一个集合中的紧接着一个来自另一个集合的暂停可以看起来是单个的更长的暂停。为了避免这种情况，CMS收集器试图在上一代和下一代年轻代之间安排中途暂停。目前尚未针对初始标记暂停执行此调度，该暂停通常比暂停标记短得多。

Incremental Mode

Note that the incremental mode is being deprecated in Java SE 8 and may be removed in a future major release.

请注意，增量模式在Java SE 8中已被弃用，并可能在未来的主要版本中删除。

The CMS collector can be used in a mode in which the concurrent phases are done incrementally. Recall that during a concurrent phase the garbage collector thread is using one or more processors. The incremental mode is meant to lessen the effect of long concurrent phases by periodically stopping the concurrent phase to yield back the processor to the application. This mode, referred to here as i-cms, divides the work done concurrently by the collector into small chunks of time that are scheduled between young generation collections. This feature is useful when applications that need the low pause times provided by the CMS collector are run on machines with small numbers of processors (for example, 1 or 2).

The concurrent collection cycle typically includes the following steps:

CMS收集器可用于并发阶段逐步完成的模式。回想一下，在并发阶段，垃圾收集器线程正在使用一个或多个处理器。增量模式旨在通过定期停止并发阶段以将处理器退回给应用程序来减少长并发阶段的影响。这种模式在这里被称为i-cms，它将收集器同时完成的工作划分为年轻一代收集之间的小块时间。当需要由CMS收集器提供的较低暂停时间的应用程序在具有少量处理器（例如1或2）的计算机上运行时，此功能非常有用。

·        Stop all application threads, identify the set of objects reachable from roots, and then resume all application threads.

停止所有应用程序线程，识别可从根访问的对象集合，然后恢复所有应用程序线程

·        Concurrently trace the reachable object graph, using one or more processors, while the application threads are executing.

在应用程序线程正在执行的同时，使用一个或多个处理器同时跟踪可到达的对象图。

·        Concurrently retrace sections of the object graph that were modified since the tracing in the previous step, using one processor.

同时回溯自上一步跟踪后修改的对象图的部分，使用一个处理器。

·        Stop all application threads and retrace sections of the roots and object graph that may have been modified since they were last examined, and then resume all application threads.

停止所有应用程序线程并回溯自上次检查后可能已被修改的根和对象图的部分，然后恢复所有应用程序线程。

·        Concurrently sweep up the unreachable objects to the free lists used for allocation, using one processor.

同时使用一个处理器将无法访问的对象扫描到用于分配的空闲列表。

·        Concurrently resize the heap and prepare the support data structures for the next collection cycle, using one processor.

同时调整堆大小，并使用一个处理器为下一个采集周期准备支持数据结构。

Normally, the CMS collector uses one or more processors during the entire concurrent tracing phase, without voluntarily relinquishing them. Similarly, one processor is used for the entire concurrent sweep phase, again without relinquishing it. This overhead can be too much of a disruption for applications with response time constraints that might otherwise have used the processing cores, particularly when run on systems with just one or two processors. Incremental mode solves this problem by breaking up the concurrent phases into short bursts of activity, which are scheduled to occur midway between minor pauses.

通常，CMS收集器在整个并发跟踪阶段使用一个或多个处理器，而不自愿放弃它们。同样，一个处理器用于整个并发扫描阶段，同样不会放弃它。如果应用程序具有响应时间限制，否则可能会使用处理内核，尤其是在只有一个或两个处理器的系统上运行时，这种开销可能会造成太多的中断。增量模式通过将并发阶段分解成活动的短时间突发来解决这个问题，这些短时间活动被安排在小暂停之间的中间发生。

The i-cms mode uses a duty cycle to control the amount of work the CMS collector is allowed to do before voluntarily giving up the processor. The duty cycle is the percentage of time between young generation collections that the CMS collector is allowed to run. The i-cms mode can automatically compute the duty cycle based on the behavior of the application (the recommended method, known as automatic pacing), or the duty cycle can be set to a fixed value on the command line.

i-cms模式使用占空比来控制CMS收集器在自愿放弃处理器之前允许执行的工作量。该占空比是时间的CMS收集器允许运行新生代收集之间的百分比。i-cms模式可以根据应用程序的行为自动计算占空比（推荐的方法，称为自动起搏），或者可以在命令行上将占空比设置为固定值。

Command-Line Options

Table 8-1, "Command-Line Options for i-cms" list command-line options that control the i-cms mode. The section Recommended Options suggests an initial set of options.

Table 8-1 Command-Line Options for i-cms

Option	Description	Default Value, Java SE 5 and Earlier	Default Value, Java SE 6 and Later
-XX:+CMSIncrementalMode	Enables incremental mode. Note that the CMS collector must also be enabled (with -XX:+UseConcMarkSweepGC) for this option to work.	disabled	disabled
-XX:+CMSIncrementalPacing	Enables automatic pacing. The incremental mode duty cycle is automatically adjusted based on statistics collected while the JVM is running.	disabled	disabled
-XX:CMSIncrementalDutyCycle=<N>	The percentage (0 to 100) of time between minor collections that the CMS collector is allowed to run. If CMSIncrementalPacing is enabled, then this is just the initial value.	50	10
-XX:CMSIncrementalDutyCycleMin=<N>	The percentage (0 to 100) that is the lower bound on the duty cycle when CMSIncrementalPacing is enabled.	10	0
-XX:CMSIncrementalSafetyFactor=<N>	The percentage (0 to 100) used to add conservatism when computing the duty cycle	10	10
-XX:CMSIncrementalOffset=<N>	The percentage (0 to 100) by which the incremental mode duty cycle is shifted to the right within the period between minor collections.	0	0
-XX:CMSExpAvgFactor=<N>	The percentage (0 to 100) used to weight the current sample when computing exponential averages for the CMS collection statistics.	25	25

Recommended Options

To use i-cms in Java SE 8, use the following command-line options:

-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode \

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps

The first two options enable the CMS collector and i-cms, respectively. The last two options are not required; they simply cause diagnostic information about garbage collection to be written to standard output, so that garbage collection behavior can be seen and later analyzed.

前两个选项分别启用CMS收集器和i-cms。最后两个选项不是必需的; 他们只是简单地将关于垃圾收集的诊断信息写入标准输出，以便可以看到垃圾收集行为并在以后进行分析。

For Java SE 5 and earlier releases, Oracle recommends using the following as an initial set of command-line options for i-cms:

-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode \

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps \

-XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0

-XX:CMSIncrementalDutyCycle=10

The same values are recommended for JavaSE8 although the values for the three options that control i-cms automatic pacing became the default in JavaSE6.

对于JavaSE8，推荐使用相同的值，尽管控制i-cms自动调整的三个选项的值在JavaSE6中成为默认值。

Basic Troubleshooting

The i-cms automatic pacing feature uses statistics gathered while the program is running to compute a duty cycle so that concurrent collections complete before the heap becomes full. However, past behavior is not a perfect predictor of future behavior and the estimates may not always be accurate enough to prevent the heap from becoming full. If too many full collections occur, then try the steps in Table 8-2, "Troubleshooting the i-cms Automatic Pacing Feature", one at a time.

i-cms自动调整功能使用在程序运行时收集的统计信息来计算占空比，以便在堆满之前完成并发收集。但是，过去的行为并不是未来行为的完美预测因子，估计可能并不总是足够准确，不足以防止堆满。如果出现过多的完整收集，请尝试执行表8-2“排除i-cms自动起搏功能”中的步骤。

Table 8-2 Troubleshooting the i-cms Automatic Pacing Feature

Step	Options
1. Increase the safety factor.	-XX:CMSIncrementalSafetyFactor=<N>
2. Increase the minimum duty cycle.	-XX:CMSIncrementalDutyCycleMin=<N>
3. Disable automatic pacing and use a fixed duty cycle.	-XX:-CMSIncrementalPacing -XX:CMSIncrementalDutyCycle=<N>

Measurements

Example 8-1, "Output from the CMS Collector" is the output from the CMS collector with the options -verbose:gc and -XX:+PrintGCDetails, with a few minor details removed. Note that the output for the CMS collector is interspersed with the output from the minor collections; typically many minor collections occur during a concurrent collection cycle. CMS-initial-mark indicates the start of the concurrent collection cycle, CMS-concurrent-mark indicates the end of the concurrent marking phase, and CMS-concurrent-sweep marks the end of the concurrent sweeping phase. Not discussed previously is the precleaning phase indicated by CMS-concurrent-preclean. Precleaning represents work that can be done concurrently in preparation for the remark phase CMS-remark. The final phase is indicated by CMS-concurrent-reset and is in preparation for the next concurrent collection.

示例8-1“CMS收集器的输出”是CMS收集器的输出，带有选项-verbose:gc和-XX:+PrintGCDetails，删除了一些小的细节。请注意，CMS收集器的输出中散布有次要收集的输出; 通常会在并发收集周期中发生许多次要收集。CMS-initial-mark指示并发收集周期的开始，CMS-concurrent-mark指示并发标记阶段的结束，并且CMS-concurrent-sweep标记并发扫描阶段的结束。之前没有讨论过由CMS-concurrent-preclean表示的预清理阶段。预清理代表可以同时完成的工作，为备注阶段CMS-remark做准备。最后阶段由CMS-concurrent-reset指示，并准备下一个并发收集。

Example 8-1 Output from the CMS Collector

[GC [1 CMS-initial-mark: 13991K(20288K)] 14103K(22400K), 0.0023781 secs]

[GC [DefNew: 2112K->64K(2112K), 0.0837052 secs] 16103K->15476K(22400K), 0.0838519 secs]

...

[GC [DefNew: 2077K->63K(2112K), 0.0126205 secs] 17552K->15855K(22400K), 0.0127482 secs]

[CMS-concurrent-mark: 0.267/0.374 secs]

[GC [DefNew: 2111K->64K(2112K), 0.0190851 secs] 17903K->16154K(22400K), 0.0191903 secs]

[CMS-concurrent-preclean: 0.044/0.064 secs]

[GC [1 CMS-remark: 16090K(20288K)] 17242K(22400K), 0.0210460 secs]

[GC [DefNew: 2112K->63K(2112K), 0.0716116 secs] 18177K->17382K(22400K), 0.0718204 secs]

[GC [DefNew: 2111K->63K(2112K), 0.0830392 secs] 19363K->18757K(22400K), 0.0832943 secs]

...

[GC [DefNew: 2111K->0K(2112K), 0.0035190 secs] 17527K->15479K(22400K), 0.0036052 secs]

[CMS-concurrent-sweep: 0.291/0.662 secs]

[GC [DefNew: 2048K->0K(2112K), 0.0013347 secs] 17527K->15479K(27912K), 0.0014231 secs]

[CMS-concurrent-reset: 0.016/0.016 secs]

[GC [DefNew: 2048K->1K(2112K), 0.0013936 secs] 17527K->15479K(27912K), 0.0014814 secs

]

The initial mark pause is typically short relative to the minor collection pause time. The concurrent phases (concurrent mark, concurrent preclean and concurrent sweep) normally last significantly longer than a minor collection pause, as indicated by Example 8-1, "Output from the CMS Collector". Note, however, that the application is not paused during these concurrent phases. The remark pause is often comparable in length to a minor collection. The remark pause is affected by certain application characteristics (for example, a high rate of object modification can increase this pause) and the time since the last minor collection (for example, more objects in the young generation may increase this pause).

相对于次要收集暂停时间，初始标记暂停通常较短。正如示例8-1“从CMS收集器中输出” 所示，并发阶段（并发标记，并发预清除和并发扫描）通常会比次要收集暂停持续时间明显更长。但请注意，在这些并发阶段中，应用程序未暂停。重标记暂停的长度通常与minor collection相当。重标记暂停受某些应用程序特性（例如，高速率的对象修改可能增加此暂停）以及自上次minor collection以来的时间（例如，年轻一代中的更多对象可能增加此暂停）的影响。

Garbage-First Garbage Collector

The Garbage-First (G1) garbage collector is a server-style garbage collector, targeted for multiprocessor machines with large memories. It attempts to meet garbage collection (GC) pause time goals with high probability while achieving high throughput. Whole-heap operations, such as global marking, are performed concurrently with the application threads. This prevents interruptions proportional to heap or live-data size.

Garbage-First（G1）垃圾收集器是一种服务器式垃圾收集器，针对具有大内存的多处理器机器。它试图以高概率满足垃圾收集（GC）暂停时间目标，同时实现高吞吐量。整个堆操作（如全局标记）与应用程序线程同时执行。这可以防止中断并实现堆或实时数据大小成比例。

The G1 collector achieves high performance and pause time goals through several techniques.

G1采集器通过多种技术实现了高性能和暂停时间目标。

The heap is partitioned into a set of equally sized heap regions, each a contiguous range of virtual memory. G1 performs a concurrent global marking phase to determine the liveness of objects throughout the heap. After the marking phase completes, G1 knows which regions are mostly empty. It collects these regions first, which often yields a large amount of free space. This is why this method of garbage collection is called Garbage-First. As the name suggests, G1 concentrates its collection and compaction activity on the areas of the heap that are likely to be full of reclaimable objects, that is, garbage. G1 uses a pause prediction model to meet a user-defined pause time target and selects the number of regions to collect based on the specified pause time target.

堆被分割成一组相同大小的堆区，每个堆区都是连续的虚拟内存。G1执行一个并行的全局标记阶段来确定整个堆中对象的活性。标记阶段完成后，G1知道哪些区域大部分是空的。它首先收集这些区域，这往往产生大量的可用空间。这就是为什么这种垃圾收集方法称为垃圾优先。顾名思义，G1将其收集和压缩活动集中在可能充满可回收对象的堆的区域，即垃圾。G1使用暂停预测模型来满足用户定义的暂停时间目标，并根据指定的暂停时间目标选择要收集的区域数量。

G1 copies objects from one or more regions of the heap to a single region on the heap, and in the process both compacts and frees up memory. This evacuation is performed in parallel on multiprocessors to decrease pause times and increase throughput. Thus, with each garbage collection, G1 continuously works to reduce fragmentation. This is beyond the capability of both of the previous methods. CMS (Concurrent Mark Sweep) garbage collection does not do compaction. Parallel compaction performs only whole-heap compaction, which results in considerable pause times.

G1将对象从堆的一个或多个区域复制到堆上的单个区域，并在此过程中压缩并释放内存。这种撤离在多处理器上并行执行，以减少暂停时间及提高吞吐量。因此，对于每个垃圾收集，G1不断努力减少碎片。这超出了以前两种方法的能力。CMS（并发标记扫描）垃圾收集不会执行压缩。平行压实仅执行全堆压实，这导致相当多的暂停时间。

It is important to note that G1 is not a real-time collector. It meets the set pause time target with high probability but not absolute certainty. Based on data from previous collections, G1 estimates how many regions can be collected within the target time. Thus, the collector has a reasonably accurate model of the cost of collecting the regions, and it uses this model to determine which and how many regions to collect while staying within the pause time target.

需要注意的是，G1不是实时收集器。它以高概率满足设定的暂停时间目标，但不是绝对确定的。根据以前收集的数据，G1会估算在目标时间内可以收集多少个地区。因此，收集者具有相当准确的收集区域成本的模型，并且它使用该模型来确定在停留时间目标内停留时收集哪些区域和收集多少区域。

The first focus of G1 is to provide a solution for users running applications that require large heaps with limited GC latency. This means heap sizes of around 6 GB or larger, and a stable and predictable pause time below 0.5 seconds.

G1的第一个重点是为运行应用程序的用户提供一个解决方案，这些应用程序需要具有有限GC延迟的大堆。这意味着堆大小约6 GB或更大，以及稳定和可预测的暂停时间低于0.5秒。

Applications running today with either the CMS or the with parallel compaction would benefit from switching to G1 if the application has one or more of the following traits.

如果应用程序具有以下一项或多项特征，那么现在运行CMS或具有并行压缩的应用程序不如切换到G1。

·         More than 50% of the Java heap is occupied with live data.（超过50％的Java堆被实时数据占用。）

·        The rate of object allocation rate or promotion varies significantly（对象分配率或促销率显着不同）.

·        The application is experiencing undesired long garbage collection or compaction pauses (longer than 0.5 to 1 second).（该应用程序正在经历不希望的长时间垃圾收集或压缩暂停（大于0.5到1秒））

G1 is planned as the long-term replacement for the Concurrent Mark-Sweep Collector (CMS). Comparing G1 with CMS reveals differences that make G1 a better solution. One difference is that G1 is a compacting collector. Also, G1 offers more predictable garbage collection pauses than the CMS collector, and allows users to specify desired pause targets.

G1计划作为并发标记扫描收集器（CMS）的长期替代品。将G1与CMS进行比较可以发现G1的差异，这是更好的解决方案。一个区别是G1是一个压缩收集器。此外，G1提供比CMS收集器更多可预测的垃圾收集暂停，并允许用户指定所需的暂停目标。

As with CMS, G1 is designed for applications that require shorter GC pauses.

与CMS一样，G1专为需要更短GC暂停的应用而设计。

G1 divides the heap into fixed-sized regions (the gray boxes) as in Figure 9-1, "Heap Division by G1".

G1将堆分成固定大小的区域（灰色框），如图9-1“由G1 分割堆积”所示。

Figure 9-1 Heap Division by G1

Description of "Figure 9-1 Heap Division by G1"

G1 is generational in a logical sense. A set of empty regions is designated as the logical young generation. In the figure, the young generation is light blue. Allocations are done out of that logical young generation, and when the young generation is full, that set of regions is garbage collected (a young collection). In some cases, regions outside the set of young regions (old regions in dark blue) can be garbage collected at the same time. This is referred to as a mixed collection. In the figure, the regions being collected are marked by red boxes. The figure illustrates a mixed collection because both young regions and old regions are being collected. The garbage collection is a compacting collection that copies live objects to selected, initially empty regions. Based on the age of a surviving object, the object can be copied to a survivor region (marked by "S") or to an old region (not specifically shown). The regions marked by "H" contain humongous objects that are larger than half a region and are treated specially; see the section Humongous Objects and Humongous Allocations in Garbage-First Garbage Collector.

从逻辑上讲，G1是也是代的。一组空白区域被指定为逻辑上的年轻代。在图中，年轻代是淡蓝色。分配工作是由那些逻辑上的年轻代完成的，当年轻代充满时，这些区域就会进行垃圾收集（年轻代回收）。在某些情况下，在一组年轻代区之外的区（深蓝色的旧地区）可以同时进行垃圾收集。这被称为混合回收。在该图中，收集的区域用红色框标记。该图显示了混合回收，因此收集了年轻区域和旧区域。垃圾收集是一个压缩收集，它将活动对象复制到选定的初始空白区域。根据幸存对象的年龄，可以将对象复制到幸存者区域（标有“S”）或旧区域（未具体显示）。标有“H”的区域包含大于半个区的大型物体，并进行专门处理; 请参见了Humongous对象和分配了Humongous在垃圾-First垃圾收集。

Allocation (Evacuation) Failure

As with CMS, the G1 collector runs parts of its collection while the application continues to run and there is a risk that the application will allocate objects faster than the garbage collector can recover free space. See the section Concurrent Mode Failure in Concurrent Mark Sweep (CMS) Collector for the analogous CMS behavior. In G1, the failure (exhaustion of the Java heap) occurs while G1 is copying live data out of one region (evacuating) into another region. The copying is done to compact the live data. If a free (empty) region cannot be found during the evacuation of a region being garbage collected, then an allocation failure occurs (because there is no space to allocate the live objects from the region being evacuated) and a stop-the-world (STW) full collection is done.

与CMS一样，G1收集器运行并行收集，与应用程序同时运行，当应用程序将分配对象的速度比垃圾收集器回收时可用空间会出现风险。请参阅并发标记扫描（CMS）收集器中的并发模式故障以了解类似CMS的行为。在G1中，当G1将一个区域（撤出）的实时数据复制到另一个区域时，出现故障（Java堆耗尽）。复制完成以压缩实时数据。如果在疏散垃圾收集区域的过程中找不到空闲（空的）区域，则会发生分配失败（因为没有空间可以分配正在疏散的区域的活体）和stop-the-world（ STW）等待全面收集完成。

Floating Garbage

Objects can die during a G1 collection and not be collected. G1 uses a technique called snapshot-at-the-beginning (SATB) to guarantee that all live objects are found by the garbage collector. SATB states that any object that is live at the start of the concurrent marking (a marking over the entire heap) is considered live for the purpose of the collection. SATB allows floating garbage in a way analogous to that of a CMS incremental update.

对象可能在G1收集期间死亡，是不会被回收的。G1使用了一种称为快照（SATB）的技术来保证所有活动对象都能被垃圾收集器找到。SATB规定，在并发标记开始时（直接在整个堆上标记）的任何对象都被认为是为了收集目的而存在的。SATB允许以类似于CMS增量更新的方式浮动垃圾。

Pauses

G1 pauses the application to copy live objects to new regions. These pauses can either be young collection pauses where only young regions are collected or mixed collection pauses where young and old regions are evacuated. As with CMS there is a final marking or remark pause to complete the marking while the application is stopped. Whereas CMS also had an initial marking pause, G1 does the initial marking work as part of an evacuation pause. G1 has a cleanup phase at the end of a collection which is partly STW and partly concurrent. The STW part of the cleanup phase identifies empty regions and determines old regions that are candidates for the next collection.

G1暂停应用程序以将活动对象复制到新区域。这些停顿可以是只收集年轻区域的年轻代回收停顿或者是收集年轻带和老年代区域的混合收集暂停。与CMS一样，当应用程序停止时，会有最终标记或重标记暂停以完成标记。尽管CMS也有一个初始标记暂停，但G1将初始标记工作作为避难暂停的一部分。G1在收集结束时有一个清理阶段，部分STW和部分并发。清理阶段的STW部分识别空白区域并确定作为下一个集合的候选区域的旧区域。

Card Tables and Concurrent Phases

If a garbage collector does not collect the entire heap (an incremental collection), the garbage collector needs to know where there are pointers from the uncollected part of the heap into the part of the heap that is being collected. This is typically for a generational garbage collector in which the uncollected part of the heap is usually the old generation, and the collected part of the heap is the young generation. The data structure for keeping this information (old generation pointers to young generation objects), is a remembered set. A card table is a particular type of remembered set. Java HotSpot VM uses an array of bytes as a card table. Each byte is referred to as a card. A card corresponds to a range of addresses in the heap. Dirtying a card means changing the value of the byte to a dirty value; a dirty value might contain a new pointer from the old generation to the young generation in the address range covered by the card.

如果垃圾收集器不收集整个堆（增量收集），则垃圾收集器需要知道从堆的未收集部分到正在收集的堆部分的指针。这通常用于代代垃圾收集器，其中堆的未收集部分通常是年老代，堆中收集的部分是年轻代。保存这些信息的数据结构（老一代指向年轻一代对象）是一个记忆集合。卡表是一个特定类型的记录置位的。Java HotSpot VM使用一组字节作为卡表。每个字节都称为卡。卡对应于堆中的一系列地址。脏卡意味着将字节的值改为脏值 ; 脏的值可能包含从年老代到该卡覆盖的地址范围内的年轻代的新指针。

Processing a card means looking at the card to see if there is an old generation to young generation pointer and perhaps doing something with that information such as transferring it to another data structure.

处理卡片意味着查看卡片以查看是否存在年老代到年轻代的指针，并且可能使用该信息进行某些操作，例如将其传送到另一个数据结构。

G1 has concurrent marking phase which marks live objects found from the application. The concurrent marking extends from the end of a evacuation pause (where the initial marking work is done) to the remark. The concurrent cleanup phase adds regions emptied by the collection to the list of free regions and clears the remembered sets of those regions. In addition, a concurrent refinement thread runs as needed to process card table entries that have been dirtied by application writes and which may have cross region references.

G1具有并发标记阶段，该阶段标记从应用程序找到的活动对象。并发标记从evacuation暂停的结束（初始标记工作完成的地方）延续到remark。并行清理阶段将由集合清空的区域添加到空闲区域列表中，并清除这些区域的记忆集合。此外，并发优化线程根据需要运行，以处理已被应用程序写入脏卡且可能具有跨区域引用的卡片表条目。

Starting a Concurrent Collection Cycle

As mentioned previously, both young and old regions are garbage collected in a mixed collection. To collect old regions, G1 does a complete marking of the live objects in the heap. Such a marking is done by a concurrent marking phase. A concurrent marking phase is started when the occupancy of the entire Java heap reaches the value of the parameter InitiatingHeapOccupancyPercent. Set the value of this parameter with the command-line option -XX:InitiatingHeapOccupancyPercent=<NN>. The default value of InitiatingHeapOccupancyPercent is 45.

如前所述，无论是年轻的还是老的区，垃圾都是以混合收集方式收集的。为了收集旧区域，G1会对堆中的活对象进行完整标记。这种标记是通过同时标记阶段完成的。当整个Java堆的占用量达到参数值InitiatingHeapOccupancyPercent时，将启动并发标记阶段。使用命令行选项设置此参数的值-XX:InitiatingHeapOccupancyPercent=<NN>。默认值InitiatingHeapOccupancyPercent是45。

Pause Time Goal

Set a pause time goal for G1 with the flag MaxGCPauseMillis. G1 uses a prediction model to decide how much garbage collection work can be done within that target pause time. At the end of a collection, G1 chooses the regions to be collected in the next collection (the collection set). The collection set will contain young regions (the sum of whose sizes determines the size of the logical young generation). It is partly through the selection of the number of young regions in the collection set that G1 exerts control over the length of the GC pauses. You can specify the size of the young generation on the command line as with the other garbage collectors, but doing so may hamper the ability of G1 to attain the target pause time. In addition to the pause time goal, you can specify the length of the time period during which the pause can occur. You can specify the minimum mutator usage with this time span (GCPauseIntervalMillis) along with the pause time goal. The default value for MaxGCPauseMillisis 200 milliseconds. The default value for GCPauseIntervalMillis (0) is the equivalent of no requirement on the time span.

用标志设置G1的暂停时间目标 MaxGCPauseMillis。G1使用预测模型来确定在该目标暂停时间内可以完成多少垃圾收集工作。在收集结束时，G1选择要在下一个收集（收集集合）中收集的区域。收藏集将包含年轻区域（其大小的总和决定了合乎逻辑的年轻一代的规模）。部分是通过选择收集组中的年轻区域的数量，G1对GC暂停的长度施加控制。您可以像其他垃圾收集器一样在命令行中指定年轻一代的大小，但这样做可能会妨碍G1获得目标暂停时间的能力。除了暂停时间目标之外，您还可以指定可能发生暂停的时间段的长度。您可以指定此时间跨度的最小增变器用量（GCPauseIntervalMillis）以及暂停时间目标。缺省值为MaxGCPauseMillis200毫秒。GCPauseIntervalMillis（0）的默认值相当于时间跨度上无需求。

Garbage-First Garbage Collector Tuning

This section describes how to adapt and tune the Garbage-First garbage collector (G1 GC) for evaluation, analysis and performance.

本节介绍如何调整和调整垃圾收集器（G1 GC）以进行评估，分析和性能。

As described in the section Garbage-First Garbage Collector, the G1 GC is a regionalized and generational garbage collector, which means that the Java object heap (heap) is divided into a number of equally sized regions. Upon startup, the Java Virtual Machine (JVM) sets the region size. The region sizes can vary from 1 MB to 32 MB depending on the heap size. The goal is to have no more than 2048 regions. The eden, survivor, and old generations are logical sets of these regions and are not contiguous.

正如Garbage-First Garbage Collector 部分所述，G1 GC是一个区域化的代垃圾收集器，这意味着Java对象堆（堆）被分成许多大小相同的区域。启动时，Java虚拟机（JVM）设置区域大小。根据堆大小，区域大小可以从1 MB到32 MB不等。目标是不超过2048个地区。eden, survivor, and old generations是这些地区的逻辑集合，并且不是连续的。

The G1 GC has a pause time target that it tries to meet (soft real time). During young collections, the G1 GC adjusts its young generation (eden and survivor sizes) to meet the soft real-time target. See the sections Pauses and Pause Time Goal in Garbage-First Garbage Collectorfor information about why the G1 GC takes pauses and how to set pause time targets.

G1 GC有一个试图满足的暂停时间目标（软实时）。在年轻代回收中，G1 GC调整其年轻代（eden and survivor的大小）以满足软实时目标。请参阅章节暂停和停顿时间目标在垃圾-First垃圾收集有关信息，为什么G1 GC需要暂停，以及如何设置暂停时间目标。

During mixed collections, the G1 GC adjusts the number of old regions that are collected based on a target number of mixed garbage collections, the percentage of live objects in each region of the heap, and the overall acceptable heap waste percentage.

在混合收集期间，G1 GC会根据混合垃圾收集的目标数量，堆中每个区域中的活动对象的百分比以及总体可接受的堆垃圾百分比来调整收集的旧区域的数量。

The G1 GC reduces heap fragmentation by incremental parallel copying of live objects from one or more sets of regions (called Collection Sets (CSet)s) into one or more different new regions to achieve compaction. The goal is to reclaim as much heap space as possible, starting with those regions that contain the most reclaimable space, while attempting to not exceed the pause time goal (garbage first).

G1 GC通过从一个或多个区域（称为集合集（CSet））将活动对象增量并行复制到一个或多个不同的新区域以减少堆碎片，从而实现压缩。目标是尽可能回收堆空间，从包含最多可回收空间的区域开始，同时尽量实现不超过暂停时间目标（垃圾优先）。

The G1 GC uses independent Remembered Sets (RSets) to track references into regions. Independent RSets enable parallel and independent collection of regions because only a region's RSet must be scanned for references into that region, instead of the whole heap. The G1 GC uses a post-write barrier to record changes to the heap and update the RSets.

G1 GC使用独立的记忆集（RSets）来跟踪对区域的引用。独立RSets可以并行和独立地收集区域，因此只有区域的RSet必须被扫描以引用该区域，而不是整个堆。G1 GC使用写后屏障来记录对堆的更改并更新RSets。

Garbage Collection Phases

Apart from evacuation pauses (see the section Allocation (Evacuation) Failure in Garbage-First Garbage Collector) that compose the stop-the-world (STW) young and mixed garbage collections, the G1 GC also has parallel, concurrent, and multiphase marking cycles. G1 GC uses the snapshot-at-the-beginning (SATB) algorithm, which logically takes a snapshot of the set of live objects in the heap at the start of a marking cycle. The set of live objects also includes objects allocated since the start of the marking cycle. The G1 GC marking algorithm uses a pre-write barrier to record and mark objects that are part of the logical snapshot.

除了evacuation暂停（请参见分配（疏散）未在垃圾-First垃圾收集）还有年轻和混合垃圾回收，组成该停止的世界（STW）的G1 GC还具有平行，实时及重标记循环。G1 GC使用开始快照（SATB）算法，该算法逻辑上在标记循环开始时在堆中生成一组活动对象的快照。活动对象集合还包括自标记周期开始以来分配的对象。G1 GC标记算法使用预写屏障来记录和标记属于逻辑快照一部分的对象。

Young Garbage Collections

The G1 GC satisfies most allocation requests from regions added to the eden set of regions. During a young garbage collection, the G1 GC collects both the eden regions and the survivor regions from the previous garbage collection. The live objects from the eden and survivor regions are copied, or evacuated, to a new set of regions. The destination region for a particular object depends upon the object's age; an object that has aged sufficiently evacuates to an old generation region (that is, it is promoted); otherwise, the object evacuates to a survivor region and will be included in the CSet of the next young or mixed garbage collection.

G1 GC满足来自添加到伊甸园区域集合的区域的大部分分配请求。在年轻代垃圾收集期间，G1 GC从前一次垃圾收集中收集伊甸园区域和幸存区域。来自伊甸园和幸存者地区的存活对象被复制或疏散到一组新的区域。特定对象的目标区域取决于对象的存活时间长短; 一个已经老化的对象已经足够撤离到一个年老代的区域（即它被推广）; 否则，对象撤离到幸存者区域，并将被包含在下一个年轻代中或混合垃圾收集的CSet中。

Mixed Garbage Collections

Upon successful completion of a concurrent marking cycle, the G1 GC switches from performing young garbage collections to performing mixed garbage collections. In a mixed garbage collection, the G1 GC optionally adds some old regions to the set of eden and survivor regions that will be collected. The exact number of old regions added is controlled by a number of flags (see "Taming Mixed Garbage Collectors" in the section Recommendations). After the G1 GC collects a sufficient number of old regions (over multiple mixed garbage collections), G1 reverts to performing young garbage collections until the next marking cycle completes.

成功完成并发标记循环后，G1 GC将从执行年轻代垃圾收集切换到执行混合垃圾收集。在混合垃圾收集中，G1 GC有选择的将一些旧区域添加到将要收集的伊甸园和幸存区域集合中。添加的旧区域的确切数量由多个标记控制（请参阅建议部分中的“驯服混合垃圾收集器”）。在G1 GC收集足够数量的旧区域（通过多个混合垃圾收集）之后，G1将恢复执行年轻垃圾收集，直到下一个标记周期完成。

Phases of the Marking Cycle

The marking cycle has the following phases:

·        Initial marking phase: The G1 GC marks the roots during this phase. This phase is piggybacked on a normal (STW) young garbage collection.（初始标记阶段：G1 GC在此阶段标记根。这个阶段是在一个正常的（STW）年轻垃圾收集上搭载的。）

·        Root region scanning phase: The G1 GC scans survivor regions marked during the initial marking phase for references to the old generation and marks the referenced objects. This phase runs concurrently with the application (not STW) and must complete before the next STW young garbage collection can start.

根区扫描阶段：G1 GC扫描在初始标记阶段标记的存活区域，以便参考旧代并标记参考对象。此阶段与应用程序同时运行（不是STW），并且必须在下一个STW年轻垃圾回收开始之前完成。

·        Concurrent marking phase: The G1 GC finds reachable (live) objects across the entire heap. This phase happens concurrently with the application, and can be interrupted by STW young garbage collections.（并发标记阶段：G1 GC在整个堆中找到可访问（活动）的对象。这个阶段与应用程序同时发生，并且可以被STW年轻垃圾收集中断。）

·        Remark phase: This phase is STW collection and helps the completion of the marking cycle. G1 GC drains SATB buffers, traces unvisited live objects, and performs reference processing.（这个阶段是STW收集并帮助完成标记周期。G1 GC消耗SATB缓冲区，跟踪未访问的活动对象，并执行刷新处理。）

·        Cleanup phase: In this final phase, the G1 GC performs the STW operations of accounting and RSet scrubbing. During accounting, the G1 GC identifies completely free regions and mixed garbage collection candidates. The cleanup phase is partly concurrent when it resets and returns the empty regions to the free list. 在此最后阶段，G1 GC执行RSet清理及STW操作。在会计期间，G1 GC标识完全空闲区域和混合垃圾收集候选对象。清理阶段在重置并将空白区域返回到空闲列表时是部分并发的。

Important Defaults

The G1 GC is an adaptive garbage collector with defaults that enable it to work efficiently without modification. Table 10-1, "Default Values of Important Options for G1 Garbage Collector" lists of important options and their default values in Java HotSpot VM, build 24. You can adapt and tune the G1 GC to your application performance needs by entering the options in Table 10-1, "Default Values of Important Options for G1 Garbage Collector" with changed settings on the JVM command line.

G1 GC是一个自适应垃圾回收器，具有默认设置，无需修改即可高效工作。表10-1“G1垃圾收集器的重要选项的默认值”列出了Java HotSpot VM build 24中的重要选项及其默认值。您可以通过输入以下选项来调整和调整G1 GC以满足您的应用程序性能需求表10-1“G1垃圾收集器的重要选项的默认值”在JVM命令行中具有更改的设置。

Table 10-1 Default Values of Important Options for G1 Garbage Collector

Option and Default Value	Option
-XX:G1HeapRegionSize=n	Sets the size of a G1 region. The value will be a power of two and can range from 1 MB to 32 MB. The goal is to have around 2048 regions based on the minimum Java heap size. 设置G1区域的大小。该值将是2的幂，范围可以从1 MB到32 MB。目标是基于最小的Java堆大小，最大有2048个区域。
-XX:MaxGCPauseMillis=200	Sets a target value for desired maximum pause time. The default value is 200 milliseconds. The specified value does not adapt to your heap size. 为所需的最大暂停时间设置一个目标值。默认值是200毫秒。指定的值不适应您的堆大小。
-XX:G1NewSizePercent=5	Sets the percentage of the heap to use as the minimum for the young generation size. The default value is 5 percent of your Java heap.Foot1 设置堆的百分比作为年轻代大小的最小值。默认值是Java堆的5％ This is an experimental flag. See How to Unlock Experimental VM Flags for an example. This setting replaces the -XX:DefaultMinNewGenPercent setting. 这是一个实验性的标志。例如，请参阅如何解锁实验性VM标志。此设置取代-XX:DefaultMinNewGenPercent设置。
-XX:G1MaxNewSizePercent=60	Sets the percentage of the heap size to use as the maximum for young generation size. The default value is 60 percent of your Java heap.Footref1 设置堆大小的百分比作为年轻代大小的最大值。默认值是Java堆的60％。Footref1 This is an experimental flag. See How to Unlock Experimental VM Flags for an example. This setting replaces the -XX:DefaultMaxNewGenPercent setting.
-XX:ParallelGCThreads=n	Sets the value of the STW worker threads. Sets the value of n to the number of logical processors. The value of n is the same as the number of logical processors up to a value of 8. 设置STW工作线程的值。将值设置n为逻辑处理器的数量。该值与n逻辑处理器的数量相同，最大值为8。 If there are more than eight logical processors, sets the value of n to approximately 5/8 of the logical processors. This works in most cases except for larger SPARC systems where the value of ncan be approximately 5/16 of the logical processors. 如果有八个以上的逻辑处理器，则将n的值设置为大约5/8个逻辑处理器。这在大多数情况下都适用，除了较大的SPARC系统，其值n可以约为逻辑处理器的5/16。
-XX:ConcGCThreads=n	Sets the number of parallel marking threads. Sets n to approximately 1/4 of the number of parallel garbage collection threads (ParallelGCThreads). 设置并行标记线程的数量。设置n大约为并行垃圾回收线程数量的1/4（ParallelGCThreads）。
-XX:InitiatingHeapOccupancyPercent=45	Sets the Java heap occupancy threshold that triggers a marking cycle. The default occupancy is 45 percent of the entire Java heap. 设置触发标记周期的Java堆占用阈值。默认占用率是整个Java堆的45％。
-XX:G1MixedGCLiveThresholdPercent=85	Sets the occupancy threshold for an old region to be included in a mixed garbage collection cycle. The default occupancy is 85 percent.Footref1 将旧区域的占用阈值设置为包含在混合垃圾回收循环中。默认占用率为85％。Footref1 This is an experimental flag. See How to Unlock Experimental VM Flags for an example. This setting replaces the -XX:G1OldCSetRegionLiveThresholdPercent setting.
-XX:G1HeapWastePercent=5	Sets the percentage of heap that you are willing to waste. The Java HotSpot VM does not initiate the mixed garbage collection cycle when the reclaimable percentage is less than the heap waste percentage. The default is 5 percent.Footref1 设置你愿意浪费的堆的百分比。当可回收百分比小于堆浪费百分比时，Java HotSpot VM不会启动混合垃圾回收循环。默认值是5％。
-XX:G1MixedGCCountTarget=8	Sets the target number of mixed garbage collections after a marking cycle to collect old regions with at most G1MixedGCLIveThresholdPercent live data. The default is 8 mixed garbage collections. The goal for mixed collections is to be within this target number.Footref1 设置标记周期后混合垃圾收集的目标数量，以收集最多带有G1MixedGCLIveThresholdPercent实时数据的旧区域。默认值是8个混合垃圾收集。混合收藏的目标是在这个目标数量内。Footref1
-XX:G1OldCSetRegionThresholdPercent=10	Sets an upper limit on the number of old regions to be collected during a mixed garbage collection cycle. The default is 10 percent of the Java heap.Footref1 设置混合垃圾回收周期中要收集的旧区域数量的上限。默认值是Java堆的10％。Footref1
-XX:G1ReservePercent=10	Sets the percentage of reserve memory to keep free so as to reduce the risk of to-space overflows. The default is 10 percent. When you increase or decrease the percentage, make sure to adjust the total Java heap by the same amount.Footref1 设置保留内存的百分比以保持空闲状态，以减少发生空间溢出的风险。默认值是10％。当您增加或减少百分比时，请确保将Java堆总数调整为相同的数量。Footref1

^Footnote1This setting is not available in Java HotSpot VM build 23 or earlier.

How to Unlock Experimental VM Flags

To change the value of experimental flags, you must unlock them first. You can do this by setting -XX:+UnlockExperimentalVMOptions explicitly on the command line before any experimental flags. For example:

要更改实验标志的值，您必须先解锁它们。您可以通过-XX:+UnlockExperimentalVMOptions在任何实验性标志之前在命令行上明确设置来实现。例如：

java -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=10 -XX:G1MaxNewSizePercent=75 G1test.jar

Recommendations

When you evaluate and fine-tune G1 GC, keep the following recommendations in mind:

当您评估和微调G1 GC时，请牢记以下建议：

·        Young Generation Size: Avoid explicitly setting young generation size with the -Xmn option or any or other related option such as -XX:NewRatio. Fixing the size of the young generation overrides the target pause-time goal.

年轻代的大小：避免使用-Xmn选项或-XX:NewRatio任何或其他相关选项（例如）来明确设置年轻一代的规模。确定年轻代的大小优先于目标暂停时间目标。

·        Pause Time Goals: When you evaluate or tune any garbage collection, there is always a latency versus throughput trade-off. The G1 GC is an incremental garbage collector with uniform pauses, but also more overhead on the application threads. The throughput goal for the G1 GC is 90 percent application time and 10 percent garbage collection time. Compare this to the Java HotSpot VM parallel collector. The throughput goal of the parallel collector is 99 percent application time and 1 percent garbage collection time. Therefore, when you evaluate the G1 GC for throughput, relax your pause time target. Setting too aggressive a goal indicates that you are willing to bear an increase in garbage collection overhead, which has a direct effect on throughput. When you evaluate the G1 GC for latency, you set your desired (soft) real-time goal, and the G1 GC will try to meet it. As a side effect, throughput may suffer. See the section Pause Time Goal in Garbage-First Garbage Collector for additional information.

当您评估或调整任何垃圾回收时，始终存在延迟与吞吐量的权衡。G1 GC是一个具有统一暂停的增量垃圾收集器，但是在应用程序线程上的开销也更大。G1 GC的吞吐量目标是90％的应用程序时间和10％的垃圾收集时间。将其与Java HotSpot VM并行收集器进行比较。并行收集器的吞吐量目标是99％的应用程序时间和1％的垃圾收集时间。因此，当您评估G1 GC的吞吐量时，请放松您的暂停时间目标。设置过于激进的目标意味着您愿意承担垃圾收集开销的增加，这会直接影响吞吐量。当您评估G1 GC的等待时间时，您可以设置您想要的（软）实时目标，并且G1 GC将尝试满足它。作为副作用，吞吐量可能会受到影响。请参阅部分在垃圾优先垃圾收集器中暂停时间目标以获取更多信息。

·        Taming Mixed Garbage Collections: Experiment with the following options when you tune mixed garbage collections. See the section Important Defaults for information about these options:

驯服混合垃圾收集：调整混合垃圾收集时，请尝试以下选项。有关这些选项的信息，请参阅重要默认值部分：

o  -XX:InitiatingHeapOccupancyPercent: Use to change the marking threshold.

-XX:InitiatingHeapOccupancyPercent：用于更改标记阈值。

o  -XX:G1MixedGCLiveThresholdPercent and -XX:G1HeapWastePercent: Use to change the mixed garbage collection decisions.

-XX:G1MixedGCLiveThresholdPercent和-XX:G1HeapWastePercent：用于更改混合垃圾收集决策。

o  -XX:G1MixedGCCountTarget and -XX:G1OldCSetRegionThresholdPercent: Use to adjust the CSet for old regions.

-XX:G1MixedGCCountTarget和-XX:G1OldCSetRegionThresholdPercent：用于调整旧区域的CSet。

Overflow and Exhausted Log Messages

When you see to-space overflow or to-space exhausted messages in your logs, the G1 GC does not have enough memory for either survivor or promoted objects, or for both. The Java heap cannot because it is already at its maximum. Example messages:

当您在日志中看到空间溢出或空间耗尽的消息时，G1 GC没有足够的内存用于生还者或升级对象或两者。Java堆不能，因为它已经达到最大值。示例消息：

·       924.897: [GC pause (G1 Evacuation Pause) (mixed) (to-space exhausted), 0.1957310 secs]

·       924.897: [GC pause (G1 Evacuation Pause) (mixed) (to-space overflow), 0.1957310 secs]

To alleviate the problem, try the following adjustments:

为了缓解这个问题，请尝试以下调整：

·        Increase the value of the -XX:G1ReservePercent option (and the total heap accordingly) to increase the amount of reserve memory for "to-space".

增加该-XX:G1ReservePercent选项的值（以及相应的总堆）以增加“到空间”的预留内存量。

·       Start the marking cycle earlier by reducing the value of -XX:InitiatingHeapOccupancyPercent.

通过减少值来提前开始标记循环 -XX:InitiatingHeapOccupancyPercent.

·        Increase the value of the -XX:ConcGCThreads option to increase the number of parallel marking threads.

增加-XX:ConcGCThreads选项的值以增加并行标记线程的数量。

See the section Important Defaults for a description of these options.

Humongous Objects and Humongous Allocations

For G1 GC, any object that is more than half a region size is considered a humongous object. Such an object is allocated directly in the old generation into humongous regions. These humongous regions are a contiguous set of regions. StartsHumongous marks the start of the contiguous set and ContinuesHumongous marks the continuation of the set.

对于G1 GC，超过一半区域大小的任何对象都被视为一个大型对象。 这样的对象直接分配到年老代进入巨大的区域。这些巨大的地区是一个连续的地区。StartsHumongous标志着连续集的开始并ContinuesHumongous标志着该集的延续。

Before allocating any humongous region, the marking threshold is checked, initiating a concurrent cycle, if necessary.

在分配任何大型区域之前，必须检查标记阈值，启动并发循环。

Dead humongous objects are freed at the end of the marking cycle during the cleanup phase and also during a full garbage collection cycle.

在清理阶段和整个垃圾收集周期期间，在标记周期结束时释放死亡的大型对象。

To reduce copying overhead, the humongous objects are not included in any evacuation pause. A full garbage collection cycle compacts humongous objects in place.

为了减少复制开销，任何疏散暂停都不包括大型物体。一个完整的垃圾收集周期压缩了大量的物体。

Because each individual set of StartsHumongous and ContinuesHumongous regions contains just one humongous object, the space between the end of the humongous object and the end of the last region spanned by the object is unused. For objects that are just slightly larger than a multiple of the heap region size, this unused space can cause the heap to become fragmented.

因为每个单独的区域StartsHumongous和ContinuesHumongous区域只包含一个大型物体，所以在该物体所跨越的最后区域的末端与该大型物体的末端之间的空间未被使用。对于略大于堆区大小倍数的对象，此未使用的空间可能会导致堆变得碎片化。

If you see back-to-back concurrent cycles initiated due to humongous allocations and if such allocations are fragmenting your old generation, then increase the value of -XX:G1HeapRegionSize such that previous humongous objects are no longer humongous and will follow the regular allocation path.

如果您看到由于冗长的分配而启动的背靠背并发循环，并且如果这样的分配将碎片化您的老一代，那么请增加-XX:G1HeapRegionSize先前的大型对象不再冗长并且遵循常规分配路径的值。

Training - How to Tune G1 Garbage Collector (文档 ID 2103280.1)

转到底部

In this Document Purpose Troubleshooting Steps   G1 garbage collector basics   Common G1 performance tuning issues and tuning tips References APPLIES TO: Java SE JDK and JRE - Version 7 and later Information in this document applies to any platform. PURPOSE This document discusses common performance issues in the Garbage First (G1) garbage collector and how to tune it effectively.  Please note that performance tuning is outside the scope of Oracle Support.  Please see Document 166650.1, "Working Effectively with Support Best Practices", under the "Support Policies" tab.  Tuning assistance is provided by Oracle Consulting Services. TROUBLESHOOTING STEPS G1 garbage collector basics Background: When the G1 GC determines that a garbage collection is necessary, it collects the regions with the least live data first (garbage first).  G1 GC uses concurrent and parallel phases to achieve its target pause time (tuned with -XX:MaxGCPauseMillis, default is 200ms) and to maintain good throughput.  The G1 Java heap is divided into a number of equally sized regions. The region sizes (tuned with -XX:G1HeapRegionSize) can vary from 1 MB to 32 MB depending on the heap size (tuned with -Xms/-Xmx). The goal is to have no more than 2048 regions.  The percentage of heap used for young generation is bounded by -XX:G1NewSizePercent (default is 5) and -XX:G1MaxNewSizePercent (default is 60). Being experimental flags, these two new generation sizing options need to be specified together with -XX:+UnlockExperimentalVMOptions. Regions are designated as eden, survivor, old, free or humongous.  Unlike the other GC implementations, the G1 Java heap does not need to be contiguous.  G1 GC selects an adaptive young generation size based on the pause time goal.  The regions help provide finer granularity for an incremental collection of the old generation.  Objects start in eden, move to survivor after a young GC, aged objects promote into old generation.  Most allocations happen in eden except for humongous allocations.  Objects that span more than half a region size are considered Humongous objects and are directly allocated into humongous regions out of the old generation. More Details When eden reaches capacity, a young garbage collection, also known as an evacuation pause, will occur. This is a stop-the-world pause that copies (evacuates) the live objects from the regions that make up the eden, to the 'to-space' survivor regions. In addition, live objects from the 'from-space' survivor regions will either be copied to the 'to-space' survivor regions or, based on the object's age and the 'tenuring threshold', will be promoted to region(s) from the old generation space. Live objects from eden and survivor regions are evacuated to a set of unused regions which become the new survivor regions. The number of regions in eden and survivor can change between GCs based on pause time target and other heuristics. Young generation GCs are multi-threaded, stop-the-world collections denoted in GC logs as: [GC pause (young)... If the heap occupancy after GC is higher than the threshold (tuned with -XX:InitiatingHeapOccupancyPercent with a default of 45), the concurrent cycle begins with initial parallel marking phase piggy-backed on a young GC. After initial marking, G1 will perform additional root scanning, concurrent mark, remark and clean up.  It is likely you will see several young GCs between the marking cycles. Upon successful completion of a concurrent marking cycle, the G1 GC switches from performing young garbage collections to performing mixed garbage collections.  In a mixed garbage collection, the G1 GC adjusts the number of old regions that are collected based on a target number of mixed garbage collections (tuned with -XX:G1MixedGCCountTarget,default is 8), the percentage of live objects in each region of the heap (tuned with -XX:G1MixedGCLiveThresholdPercent, default is 65), and the overall acceptable heap waste percentage (tuned with -XX:G1HeapWastePercent, default is 10). After marking, the old regions are sorted by the occupancy for the regions. If the occupancy of a region is lower than a threshold (-XX:G1MixedGCLiveThresholdPercent), this region is considered as a candidate region. The reclaimable heap is calculated by checking how much can be reclaimed from the candidate (old) regions.  If the reclaimable is higher than the waste threshold (-XX:G1HeapWastePercent), a mixed gc cycle will start. After each mixed GC, G1 will check if the reclaimable heap is over the wasted threshold. If it is, it will continue with another mixed GC. Mixed generation GC (Young + old generation) are denoted as: [GC pause (mixed)... The number of parallel working GC threads used in GC can be tuned with -XX:ParallelGCThreads, default number depends on the HW configuration The number of parallel marking (concurrent phase) GC threads used in GC can be tuned with -XX:ConcGCThreads (default is 1/4 of ParallelGCThreads), Setting -Xmn, -XX:NewSize, -XX:MaxNewSize, -XX:NewRatio, -XX:SurvivorRatio, or other young generation space tweaking flags will effectively disable G1 adaptive heuristics.   Common G1 performance tuning issues and tuning tips For the majority of cases, you usually only need to worry about the heap size (-Xms/-Xmx), pause time goal (-XX:MaxGCPauseMillis), and concurrent cycle trigger (-XX:InitiatingHeapOccupancyPercent). 1. If a concurrent marking cycle is too long increase the number of concurrent GC threads via -XX:ConcGCThreads adjust the trigger of concurrent cycle via -XX:InitiatingHeapOccupancyPercent 2. Evacuation failure:  When no more regions are available for promotion or tenure to survivor or old spaces, an evacuation failure results.  This is usually followed by a stop-the-world full GC, denoted by [Full GC (Allocation Failure)... increase total heap space through -Xms and -Xmx increase the number of concurrent GC threads via -XX:ConcGCThreads adjust the trigger of concurrent cycle via -XX:InitiatingHeapOccupancyPercent 3. When to-space exhausted/to-space overflow increase heap size increase reserved memory in survivor space via -XX:G1ReservePercent.  This sets the percentage of reserved memory to keep free so as to reduce the risk of to-space overflows.  The default is 10 percent and there is a hard cap at 50%. 4. If mixed collection pause is too long adjust the trigger of concurrent cycle via -XX:InitiatingHeapOccupancyPercent adjust target number of old regions to collect via -XX:G1MixedGCCountTarget adjust the occupancy threshold of live objects in each region via -XX:G1MixedGCLiveThresholdPercent adjust acceptable heap waste percentage via -XX:G1HeapWastePercent 5. If reference processing time is too high, denoted by [GC ref-proc .... in the GC log Make sure parallel reference processing is enabled through -XX:+ParallelRefProcEnabled Adjust the number of parallel working GC threads with -XX:ParallelGCThreads 6. Excessive humongous allocations Consider adjusting the -XX:G1HeapRegionSize to match the humongous objects being allocated. 7. Allocation Failure even there is plenty of free heap space We have seen this happens when-XX:G1HeapRegionSize was inadvertently set to an unreasonably low value. For instance, set to 2 instead of 2M. 8. High refinement work load When you notice mutator/java threads doing the remembered sets related refinement work then there is a lot of refinement work that the G1 concurrent refinement threads alone are unable to handle. Here is what it might look in a mutator/java thread (non-GC worker thread) from jstack -m output: 0x00007fbc5a31d5fc _ZN17OtherRegionsTable13add_referenceEPvi + 0x9c  0x00007fbc5a5f4c4b _ZN13ObjArrayKlass20oop_oop_iterate_nv_mEP7oopDescP24Filter  OutOfRegionClosure9MemRegion + 0xeb  0x00007fbc5a31672e _ZN10HeapRegion32oops_on_card_seq_iterate_carefulE9MemRegio  nP24FilterOutOfRegionClosurebPa + 0x35e  0x00007fbc5a2b635c _ZN8G1RemSet11refine_cardEPajb + 0x20c  0x00007fbc5a296272 _ZN27RefineCardTableEntryClosure11do_card_ptrEPaj + 0x22  0x00007fbc5a2528de _ZN17DirtyCardQueueSet18mut_process_bufferEPPv + 0x8e  0x00007fbc5a684e25 _ZN8PtrQueue20enqueue_known_activeEPv + 0x125   To avoid this work falling onto the mutator threads, we can increase the number of refinement threads using -XX:G1ConcRefinementThreads. You can also look for "0 ( 0.0%) by mutator threads." in the GC log output - if it's not 0, consider increasing the refinement threads limit. To find out what the GC worker thread counts are for your JVM instance, you can use -XX:+PrintFlagsFinal. 9. High RememberSet scan time Use the option -XX:+G1SummarizeRSetStats and if Scan RS times seem high relative to the overall GC pause time,  look for the text string "Did xyz coarsenings" in your GC log output to determine if you have many coarsened remembered sets  - you can alter the proportion of time spent in updating remembered sets with -XX:G1RSetUpdatingPauseTimePercent=N (default N=10, i.e. 10%).     Reference on types of GC worker threads: http://xmlandmore.blogspot.com/2014/06/oracle-has-published-some-tuning-guides.html Reference on G1 tuning reference: https://docs.oracle.com/javase/9/gctuning/garbage-first-garbage-collector-tuning.htm