JVM family GC
When it comes to JVMS, we all know about the Garbage Collection (GC). The topic of GC is as simple as it can be: automatic Garbage Collection by JVMS, Collection algorithms, various collectors,GC types, and GC trigger points…. RednaxelaFX, which is specialized in JVM development, is known as “R big “in the industry. In view of the author’s lack of knowledge, this blog post is prepared to state the author’s understanding of GC in familiar and easy to understand terms. The summary is as follows:
The article structure
- Which memory needs to be reclaimed (Which)
- When to trigger various GC
- How to Recycle (How) 3.1 Recycle algorithm 3.2 HotSpot implementation – Various collectors
- The GC log
1. Which memory needs to be reclaimed (Which)
Most Javaers who have never worked in C or C++ are happy because they have never experienced the sensation of creating their own new delete memory, regardless of the memory reclamation issues. Our memory is actually reclaimed by the JVM’s GC mechanism. So here’s the question. What memory needs to be reclaimed? Answer: Reacableness analysis algorithm, namely, the JVM predetermines a set of GC roots reference variables, such as Student stu =new Student(); This STU can be used as a GC root, and when garbage collection is done, the JVM finds all the live objects that can be referenced through the GC roots, and marks the rest as “useless “, ready to recycle! References to GC Roots are as follows:
- References to objects in the GC heap in the currently active stack frames of all Java threads; In other words, the parameters/local variables/temporary values of the reference type of all methods currently being called.
- Some static data structures in the VM have references to objects in the GC heap, for example Universe in HotSpot VM has many such references.
- JNI handles, These include global handles and Local Handles All currently loaded Java classes reference types of Java classes static variables Reference types in the runtime constant pool of Java classes Constants (String or Class type) references in the String constant pool
2. When the various GC triggers
2.1 the GC type
When it comes to GC types, it’s even more interesting, because there’s no strict boundaries, and there’s no strict GC types, just one professor on the left and one author on the right. Why is this the case? Because the GC type is specific to the collector, different collectors have their own unique collection types. So the author here quotes R big about GC type introduction, the author feels more appropriate and accurate. As follows:
- Partial GC: Mode that does not collect the entire GC heap
- Young GC(Minor GC) : Collects only GCS of Young Gen
- Old GC: Only Old Gen GC is collected. Only concurrent collection from CMS is in this mode
- Mixed GC: Collects GC for all young Gen and part of old Gen. Only the G1 has this mode
- Full GC(Major GC) : Collects the entire heap, including all parts of young Gen, Old Gen, PERM Gen (if any), and so on.
2.2 Trigger Time
As you can see, the GC type classification is related to the collector, and of course, the timing of the GC firing varies from collector to collector.
- Young GC: Triggered when Young Gen is full. Note that some of the surviving objects in young GC will be promoted to Old Gen, so the charge of old Gen will usually increase after young GC.
- Full GC: When preparing to trigger a Young GC, if the statistics show that the average promotion size of the previous young GC is larger than the current amount of space left in old Gen, the young GC will not trigger but will trigger full GC (because in the HotSpot VM GC, Other than concurrent collections from CMS, GCS that collect old Gen collect the entire GC heap at the same time, including young Gen, so there is no need to trigger a separate Young GC beforehand. Or, if there is a Perm Gen, to fire a full GC when the PerM Gen allocates space but runs out of space. Or system.gc (), heap dump with GC, which also triggers full GC by default.
3. How to Recycle
3.1 Recovery Algorithm
Since there are a number of excellent blog posts on the web that cover this section in detail, the author will cite other blogs and add some descriptions of his own: 3.1.1 Mark-Sweep
3.1.2
Application of replication algorithm in JVM New generation garbage Collection:
Since 90% of the objects in the new generation are “live and die”, it is reasonable TO adopt the replication algorithm. Firstly, only the surviving objects are moved (relatively few). Secondly, the internal existence is moved in order after moving TO the TO region, and there is no memory fragment. It is worth mentioning that in a MinorGC, if the remaining space of the living objects in Eden + the living objects in From >To, the objects will be directly transferred To Old Gen through guarantee mechanism. If the memory space of Old Gen is not enough, a Full GC will be performed. When the age of the object reaches 15 years Old, it will be moved to Old Gen (can be configured by parameter, generally not recommended to change.)
3.1.3 Mark-Compact algorithm:
Since most of the objects of Old Gen are very Old, so the survival rate is relatively high, it is definitely not feasible to adopt the replication algorithm (there are many object replication operations), so most of the Old Gen collectors adopt the Mark-Compact algorithm to avoid space debris.
3.1.4 Comparison of the three algorithms:
To explain a little bit about the common GC time question: why is THE FGC time much longer than MinorGC? A :FGC does old Gen’s GC, and because of its mark-sweep or Mark-Compact algorithm, it does a lot of object movement, which is very time consuming! It’s a matter of space for time, time for space.
3.2 HotSpot implementation – various collectors
As for the collector, I am a beginner to THE JVM and rarely have the opportunity to adjust the collector parameters in a production environment. So it’s safe to say that for some HotSpot collectors, they just stay at the book and blog level, so there’s no showboating here. For a portal under everyone should take a look: www.jianshu.com/p/50d5c88b2…
4 the GC log
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-Xloggc:/Users/zdy/Desktop/dump/gclog.txt
When the server freezes frequently, take a look at your GC log and note the Full GC frequency.
Finally, a few words about the author’s comments:
- If the server is stuck for a long time, generally the full GC time is too long, and the application is most seeking STW time is short, can accept multiple STW, then you can consider increasing the proportion of young Gen, and increase the age of old age (default 15 years old) to avoid FGC as far as possible.
- Choosing the right collector is important. Depending on the characteristics of the application. Throughput versus minimum pauses.
- Always look at the reality against the GC log, such as how often and how often the gc log is used, and then adjust your collector or related memory ratio to achieve your desired effect.
- Under the condition of limited physical resources, to avoid allowing users to accept too much STW, you can consider automatic gc(system.gc ()) in the middle of the night, although it may not take effect, but you can observe the effect. Full GC is triggered in most cases.
- Most applications accept frequent MGC sessions, but not long periods of full GC lag, so be aware of the frequency of full GC and trigger conditions (whether due TO memory guarantee, age, or TO too little memory, FGC every time) when observing gc logs. As a result of the author in the gc that also is not particularly severe, and the lack of actual combat experience, dare not self-pity, so for the portal for your reference to read: www.jianshu.com/p/088d71f20… www.cnblogs.com/mikevictor0… www.cnblogs.com/mikevictor0…