JDK 12 HotSpot 虚拟机垃圾收集调优指南

需积分: 5 97 浏览量更新于2024-06-22 收藏 556KB PDF 举报

本指南是针对Java Platform, Standard Edition (Java SE) HotSpot虚拟机（VM）在JDK 12版本中的垃圾收集(Garbage Collection, GC)调优手册，编号为F13888-01，发布于2019年3月。它是Oracle及其关联公司的重要知识产权，受到严格的许可协议约束，未经明确许可，用户不得进行复制、修改、分发等行为。手册强调了对软件的反向工程、解码或编译是非法的，除非法律法规另有规定，如为了兼容性目的。本文档提供了深入理解HotSpot VM在JDK 12中运行时内存管理的详细信息，包括不同类型的垃圾收集器（如G1、Parallel、Serial等）的工作原理、性能特性、调整参数以及如何根据应用程序的需求优化GC策略。内容涵盖了从基本概念到高级调优技术的全面指导，旨在帮助开发者解决性能瓶颈，提高应用的稳定性和效率。此外，该指南也警告用户，手册中的信息可能随时更新，且不保证无误，若发现错误，请通过书面形式向Oracle报告。对于由美国政府或代表其授权的个人使用的软件或文档，特定的法律义务和限制可能适用。在阅读此指南时，读者将学习如何识别和解决垃圾收集相关的性能问题，如何在并发负载、内存限制或资源紧张的环境中调整GC设置，以及如何通过监控和日志分析来诊断和优化垃圾收集的行为。JDK 12 HotSpot VM Garbage Collection Tuning Guide是每个Java开发者和性能优化专家必备的参考资料。

Why Does the Choice of Garbage Collector Matter?

The purpose of a garbage collector is to free the application developer from manual

dynamic memory management. The developer is freed of the requirement to match

allocations with deallocations and closely take care of the lifetimes of allocated

dynamic memory. This completely eliminates some classes of errors related to

memory management at the cost of some additional runtime overhead. The Java

HotSpot VM provides a selection of garbage collection algorithms to choose from.

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 isn't 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 can't be perfectly parallelized; some

portion is always sequential and doesn't benefit from parallelism. In the Java platform,

there are currently four supported garbage collection alternatives and all but one of

them, the serial GC, parallelize the work to improve performance. It's very important to

keep the overhead of doing garbage collection as low as possible. This can be seen in

the following example.

The graph in Figure 1-1 models an ideal system that's perfectly scalable with the

exception of garbage collection. The red line is an application spending only 1% of the

time in garbage collection on a uniprocessor system. This translates to more than a

20% loss in throughput on 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.

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

Processors

Throughput

0.8

0.2

5 10 15 20 25 25 30

0.4

0.6

1% GC

2% GC

3% GC

10% GC

20% GC

30% GC

Chapter 1

Why Does the Choice of Garbage Collector Matter?

1-2

剩余57页未读，继续阅读

weixin_40191861_zj

粉丝: 87

JDK 12 HotSpot 虚拟机垃圾收集调优指南

hotspot-virtual-machine-garbage-collection-tuning-guide.pdf

JDK19-hotspot-virtual-machine-garbage-collection-tuning-guide

JDK15-hotspot-virtual-machine-garbage-collection-tuning-guide

JDK16-hotspot-virtual-machine-garbage-collection-tuning-guide

JDK11-hotspot-virtual-machine-garbage-collection-tuning-guide

JDK17-hotspot-virtual-machine-garbage-collection-tuning-guid

JDK18-hotspot-virtual-machine-garbage-collection-tuning-gui

Java SE 20 HotSpot VM: Garbage Collection Tuning指南

JDK17 HotSpot 虚拟机垃圾收集调优指南

JDK 19 HotSpot 虚拟机垃圾收集调优指南

最新资源