In-depth Understanding of the JVM – Stage Summary and Review (II)

This is the 4th day of my participation in the August More Text Challenge

preface

Are as follows: on the deep understanding of the JVM – stage summary and review of (a), a main stage summary content for some of the JVM tuning knowledge reserves and review the previous article, this section will summarize some common JVM tuning, help people don’t have to panic when problems encountered in the actual situation, it must be a special emphasis on one point: Usually write code to often review and logical sorting, for some uncertain methods must point to open source interpretation.

Previous comments said that mind maps are more intuitive, so subsequent articles will try to attach mind maps to save time.

Previous review:

In the last section, we gave two simple cases to explain the common troubleshooting routines of FULL GC. According to the troubleshooting routines, we can quickly find the direction of the investigation and timely locate the real problem points, which is a very important skill for troubleshooting online problems.

In addition, we describe how string.split () causes the JVM to perform FULL GC frequently. We chart the root results step by step, and interpret the source code to analyze the changes to this method in JDK versions. Because after upgrading the source code after cutting string to create a SubList object (the underlying array) lead to this problem, here the JDK to back part of the pot, because it violates the downward compatible with this rule, but more often is because developers method for knowledge is not enough, eventually lead to code logic memory leak!

That’s all we had in the last video.

Phase summary:

In-depth understanding of the JVM – Interpreting GC logs

The main content of this article is to explain how to read logs, and different machines run different results, but more about how to read parameters.

In-depth Understanding of the JVM – Live JVM Tools (PART 1)

This article focuses on the common JVM tools, which of course are pointless because you’ll almost forget them if you don’t use them, so this article focuses on using the tools to get a feel for how to monitor and tune your code.

In-depth Understanding of the JVM – Live JVM Tools (Part 2)

  1. Introduces three JVM tuning cases, with a step-by-step analysis of the problems and solutions.
  2. Summarize and analyze the thinking and solving process, self-reflection and reflection.
  3. Summary and personal feelings.

In-depth understanding of the JVM – case studies

  1. What is the routine of checking Full Gc? Here is an e-commerce case to illustrate.
  2. How does the spilt() method cause memory leaks? How to analyze problems through visual graphics. And how do you find root problems at the source level

Mind mapping:

The curtain address: www.mubucm.com/doc/IgrEXbw…

An overview of the

  1. Review and summary of the second stage
  2. Are you really familiar with the old days? When does the object enter the old age?
  3. What are the common reasons for frequent FULL GC
  4. What do you need to pay attention to when tuning the JVM?

Are you really familiar with vintage recycling?

The traditional JVM model takes the form of fixed generation, so let’s first review the old collection trigger conditions.

When does the object enter the old age

How does the new generation recycle memory?

The new generation uses Eden +2 survior regions for memory layout. The default value is 8:1:1. This value can be changed by using the following parameter: -xx :SurvivorRatio=8

When the Eden area is full, the improved replication algorithm will trigger YGC once, which will copy the living objects to S1 area and then clear the whole Eden area. This process is very fast. When the next YGC comes, the living objects in S1 and Eden area will be copied to S2 area and the S1 area and Eden area will be cleared. Therefore, the characteristics of the new generation of recycling are: memory is divided into three areas, and only two of them are used at a time, leaving one as a backup switch

This is the next generation of recycling processes. When the Cenozoic generation triggers YGC, the surviving object will enter the old age according to the dynamic judgment condition, so how to deal with the old age FULL GC? What was his trigger? It’s important to review this because it’s important:

  1. An object has avoided 15 garbage collections and is old as soon as it reaches its age
  2. Objects that exceed the total size of the new generation, beyond a certain threshold, are allocated directly to the old generation
  3. There are too many surviving objects after a Young GC, and since Survior can’t be stored, the batch goes straight to old age
  4. After entering the Survior region, Survior suddenly finds that the content occupied by the object is more than 50%. At this time, Survior will sort the object with the age N of 50% greater than Survior region into the old age, for example, the object with age 2, 3, and 4, and the object with age 3 accounts for more than 50%. It means that at ages 3 or 4, they will enter the old age.

How is old GC triggered?

In the previous article, there was a table describing when the old generation FULL GC was triggered. Here is a summary:

  • In the CMS collector, the old age itself has a threshold that will be triggered after the old age space is 92% occupied by default after JDK6. However, it is important to note that this percentage is not fixed, and garbage collection is done ahead of time in the JVM based on actual old age usage.

  • Before YGC, the system determines whether the maximum continuous available memory space of the old age is greater than the average size of the Cenozoic era. If it does not meet the requirements, the system triggers a FULL GC before YGC to reclaim part of the old age objects, and then YGC is executed.

  • If there are too many YGC survivors, Survior will not fit, and if the survivors will not fit at this time, Full GC will be triggered to reclaim a batch of survivors from the old generation, and then put the survivors from the younger generation into the old generation.

How many GC cycles are there under normal conditions?

In normal cases, the frequency of FULL GC is tens of minutes, a few hours, this frequency is relatively acceptable, of course, each FULL GC should be within a few hundred milliseconds.

If the system on the line behaves like this, you don’t really need to worry too much about optimization.

How to observe the JVM memory model:

Analysis methods:

The analysis can be carried out according to the following process:

  • How fast are objects in EDEN growing?
  • What is the frequency of YGC
  • How long does a YGC take
  • How high is the rate of growth in the old age
  • Full GC frequency
  • Time of a Full GC

Several symptoms of frequent FULL GC:

  • The CPU load is high
  • Frequent FULL GC alarm
  • The system is unable to process requests or is too slow.

Common reasons for frequent FULL GC:

There are many cases mentioned before, here we focus on the following:

  1. The system bears high concurrent requests or processes large amount of data, leading to frequent YGC. After YGC, there are too many objects, memory allocation is unreasonable, Survior region is too small, objects frequently enter the old age, and frequent FULL GC
  2. The system loads a large number of objects in a short time, resulting in a large number of short-lived objects. Moreover, the new generation cannot store them and can only enter the old age, which is bound to cause frequent FULL GC
  3. FULL GC can also be triggered by a memory leak, which causes a large number of objects to be created inexplicably so that they cannot be collected, and by occupying older generations that cannot be collected
  4. FULL GC caused by too many classes being loaded by the permanent generation, most often due to the incorrect use of reflection.
  5. Miss call System. The gc ()

Considerations for optimizing the JVM:

  • It is better to have a general template for the JVM. This is not to say that a set of templates are used in the JVM, but to analyze how many object names are generated in the business system, when is the FULL GC generated, how much memory is allocated for the new generation, and how much memory is allocated for the old generation
  • Do not DUMP logs randomly: You can use this command freely for your own experiments. However, you need to communicate with o&M in the online environment and use this command only when service access traffic is at low peak. Therefore, you need to be very careful.