Can the GC problem handling ability be mastered systematically? How to analyze the problem that some influencing factors are mutually cause and effect ? For example, if the RT of a service suddenly rises, there are four symptoms: increased GC time, increased thread blocks, increased slow queries, and high CPU load. Which one is the cause? How to judge whether there is a problem with GC? What are the common problems when using CMS? How to judge the root cause? How to solve or avoid these problems? After reading this article, I believe you will have a systematic understanding of the problem handling of CMS GC, and will be able to solve these problems more easily. Let's get started!
Preface
If you want to systematically master GC problem handling, the author here gives a learning path. The overall article framework is also expanded according to this structure, mainly divided into four major steps.
-
Establish a knowledge system: from JVM memory structure to garbage collection algorithms and collectors, learn the basics of GC, and master some commonly used GC problem analysis tools.
-
Determine the evaluation index: understand the basic GC evaluation method, figure out how to set the index of the independent system, and the means to judge whether there is a problem with the GC in the business scenario.
-
Scenario tuning practice: Use the knowledge and system evaluation indicators to analyze and solve nine common GC problem scenarios in CMS.
-
Summarize and optimize experience: summarize the overall process and put forward some suggestions of the author, and at the same time improve the summarized experience into the knowledge system.
1. GC basics
Before the official start, let’s make some brief preparations and introduce common concepts such as JVM memory partition, collection algorithm, collector, etc. Students with a better foundation can skip this part directly.
2.1 Basic concepts
-
GC: GC itself has three kinds of semantics, the following needs to be brought into different semantics according to specific scenarios:
-
Garbage Collection : Garbage collection technology, noun.
-
Garbage Collector : Garbage collector, noun.
-
Garbage Collecting : Garbage collection action, verb.
-
- Mutator: The role of garbage production, that is, our application, the garbage maker, allocates and frees through Allocator.
- TLAB: Shorthand for Thread Local Allocation Buffer, CAS-based exclusive threads (Mutator Threads) can allocate objects in a block of memory in Eden first. Because the memory area exclusive to Java threads has no lock competition, the allocation speed is faster. Each TLAB is exclusive to a thread.
- Card Table: Chinese translation is a card table, which is mainly used to mark the status of the card page. Each card table item corresponds to a card page. When an object reference in the card page has a write operation, the write barrier will change the status of the card table where the object is marked to dirty. The essence of the card table is to solve the problem of cross-generation references. For specific solutions, please refer to this question on StackOverflow how-actually-card-table-and-writer-barrier-works , or study the source code in cardTableRS.app.