In-depth Understanding of the JVM – Phase Summary and Review (1)

preface

Instead of writing new content, this post is a review of previous content.

Why a column

The purpose of this column is no doubt to make a record and archive of personal growth, because during this period of time, I found that learning things must be systematic and purposefully step by step to have faster growth, the content and details of the JVM is not complete, so it is critical to understand what the role of learning this thing is. Individuals learn this stuff for interviews and to understand the underlying principles, while writing columns based on the principle of less time and less time.

Summary of the series:

Column address: In-depth understanding of the JVM virtual machine

Part 1: A deep understanding of the JVM – a primer on the JVM

In this first column, we need to understand what the JVM really is, what it means to JAVA developers, and how the code we write runs through the JVM and achieves what we want, focusing on the workflow of JAVA loading into the JVM.

It also shows how the JVM’s parent delegate model and Tomcat’s parent delegate model break it down. The classloader is also a core part of the JVM.

Part two: An in-depth understanding of the JVM virtual Machine – the history of virtual machines

These are basically notes from Inside The JVM virtual Machine, as well as from many blogs.

Part three: A deeper understanding of the basic concepts of JVMS – generations

It describes the characteristics of the traditional generational model of the JVM, and the division between the new generation and the old generation, with emphasis on how the new generation enters the old age, the conditions required and the related parameter setting, which is also a frequent interview point. Finally, tuning parameters for the JVM are introduced.

Part four: An in-depth understanding of the JVM virtual machine-JVM object allocation strategy

What I personally think is interesting about this article is that the actual JVM test results are different from those in the book! In addition, the new version of Parnew will assign large objects to the old age directly, which is really strange! Or suggest learning these things must try their own, spend some time in exchange for the benefit of your intention is less than!

Part five: A deeper understanding of the JVM-garbage collection algorithm

As with the title, it introduces the JVM’s garbage collection algorithms and how the new generation and the old are using them to collect. It is important to note that there are no good or bad garbage algorithms. It all depends on the design philosophy of the actual garbage collector developers. For example, CMS is typically mark-clear, but G1 is mark-clean.

Part six: An in-depth understanding of the JVMS-CMS collector

Describes the mobile details of the CMS collector and some of the details of the handling of the CMS partner, CMS+ParNew, which is believed to be the preferred garbage collector for most companies. After all, not everyone has such a large number of users or big projects.

Part seven: Understanding JVMS – Real-world aging optimization

There is no need for further introduction. The content is similar to the title.

Part 8: A deeper understanding of the JVM-G1 collector

The functionality and use of the G1 collector are seemingly simple, but the underlying principles are quite complex.

At the same time, whether you need to study the principle depends on individual needs, of course, it is always good to know more.

Part 9: An in-depth understanding of jVM-G1 tuning briefs

I don’t need to look at it, because I haven’t encountered any situations that need to be tuned with G1 (=-=).

The discussion

I’m confused about recycling?

Minor GC: Minor GC is very confusing, but most of the time it’s a new generation collection

Young GC: Recycling for the New Generation

Full GC: Most people think of it as old-fashioned recycling, but it actually means something different, so Full GC should be similar to Full heap recycling

Old GC: No doubt about it

If you don’t know this, you’ll default to the old gc.

Mixed GC: This concept was first mentioned in G1, so it’s worth recycling old and new together with large objects

What is the system really afraid of?

The stop world operation of garbage collection, but it can be obviously found that the new generation of recycling is almost no impact, there are 20ms can not operate the system, almost few people can feel, even we even a page more than a few seconds, let alone this tiny perception.

But if the old generation takes 10 times as long to recycle as the new generation, it takes 200ms, which doesn’t seem like much, but if it’s 2000ms, it’s a big problem. If the CPU has to stop for 2 seconds, it’s almost like there’s something wrong with the program. So the pause of the old age is intolerable.

The system memory is too large:

If the traditional generational model is used for hundreds of gigabytes of service, then assuming that the old and new generations need dozens of gigabytes of memory, then the time of a pause is about a minute, because there are too many objects, and the efficiency of recycling drops.

So the very large memory is one of the reasons for the G1 collector.

How to solve the problem of garbage collection on large memory systems?

Using the G1 collector, the collector will first determine whether the occupied ratio of the new generation conforms to the parameters of the pause model. In this case, it needs to determine whether processing is required according to the parameters. If processing is required, garbage collection is performed according to the maximum pause time.

Actually is essentially the trigger condition originally recycling into time determine whether conforms to the condition of recycling, there is a little rubbish is recycled, this system can run normally, recycling also can reclaim memory as possible, and as long as the rate of recycling catch up with the allocation rate, so the whole system is basically won’t have any JVM problem!

Damn old age recycling!

Old age recycling must be due to a problem with the new generation, because the old age will definitely implement it when there is no place to put the object. Old age recycling is 10 times slower than the new generation, plus frequent old age is more likely to cause the system to slow down, making the user experience very poor.

Some of the conditions for recycling in the old age were summarized earlier:

  1. Dynamic object age judgment: If old s object is greater than the Cenozoic are available, and then the basic no problem, but if less than this value, you need to check the old s largest contiguous space is greater than all previous dynasties promoted the old s average size, if is the executive mior gc, if not at that time, the old age is certainly not put Full gc is needed, the.
  2. Object age exceeds threshold: generally 1-15, note that there are only 1-15 parameters, no 23,25,26,30, because the Marking word object header only gives 4 bits 1111 to indicate the age of the object!
  3. After object recycling, surviving objects are not fit for the old age.
  4. If the remaining space cannot be allocated during concurrent collection, concurrent Mode fail occurs and Serrial is enabled for Full GC.

How to choose CMS +Parnew or G1?

Parnew+ CMS: Generally small to medium sized systems with low performance requirements and high synchronization and real-time features are not required

G1 collector: A G1 collector is suitable for systems with very large memory.

When is permanent generation collection triggered?

Permanent generation recycling space is limited, in many cases to store the class variables and constants are static or. Class object reference information, need to be aware of is the reflection and dynamic proxy objects is the most likely to cause a permanent generation of overflow, especially modern framework most load object, using reflection method in area appear constantly occupied by the object. Methods to go once recycled are basically all OOM.

Constantly creating dynamic proxy objects is also the best way to test method area overflow.

Almost no impact on young GC?

Assuming that a business system is in the initial stage, the number of users is not very large, about 500 requests per second, and the number of objects produced is about 50M. Assuming that the new generation can be filled in about 3 minutes, and the young gc is frequent, it will be found that this time the young gc takes only 20ms, which is almost impossible to be perceived by users.

But in most cases, you don’t need to tune the JVM at all in the early stages of the business.

Also, tuning is not tuning for tuning’s sake. You can mess around with your own open source projects, but projects that make money for your company need to be considered in many ways, remember.

Impact of garbage collector after system upgrade

Assuming that the system of a small machine is upgraded to 32 cores and 16 GB, and the old and new generation occupy about 6 GB, it is very inefficient to use generational collection at this time. Therefore, we use G1 collector to collect garbage and make the collection operation complete ahead of time to ensure that the subsequent computing tasks will not cause lag or blocking.

Write in the last

Constantly review and review summary, knowledge to learn more reliable!