Shulou(Shulou.com)06/03 Report--

This article mainly explains "what's the difference between Minor GC, Major GC and Full GC". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what's the difference between Minor GC, Major GC and Full GC"?

The introduction of GC

Heap memory is divided into Eden, Survivor (2), and Tenured/Old space.

Happened in the younger generation of GC--Minor GC.

The Minor GC is shown in the following figure

The virtual machine defines an object age (Age) counter for each object. If the object is born in Eden and is still alive after the first Minor GC, and can be accommodated by Survivor, it will be moved to Survivor space and the age of the object will be set to 1.

Each time the object endures Minor GC in the Survivor area, the age increases by 1 year, and when its age increases to a certain extent (the default is 15 years old), it is promoted to the old age.

The age threshold for the promotion of an object can be set by the parameter-XX:MaxTenuringThreshold.

Reclaiming memory from younger generation space (including Eden and Survivor areas) is called Minor GC. This definition is clear and easy to understand, because most Java objects are dead and dying, so Minor GC is very frequent and generally recycling is fast.

Minor GC is triggered when JVM cannot allocate space for a new object, such as when the Eden area is full. So the higher the allocation rate, the more frequently the Minor GC is executed.

When the memory pool is filled, all of its contents are copied, and the pointer tracks free memory starting at 0.

The Eden and Survivor areas are marked and copied, replacing the classic marking, scanning, compression, and cleaning operations.

So there is no memory fragmentation in the Eden and Survivor areas, and the write pointer always stays on top of the memory pool used.

The method area is not affected when the Minor GC operation is performed. References from the method area to the younger generation are treated as GCRoots, and references from the younger generation to the method area are directly ignored at the marking stage.

Questioning conventional wisdom, all Minor GC triggers a "worldwide stop-the-world" to stop the application's threads. For most applications, the delay caused by pause is negligible.

The truth is that most of the objects in the Eden area can be considered rubbish and will never be copied to the Survivor area or the old space.

If, on the contrary, most of the freshmen in the Eden area do not meet the GC conditions, the pause during Minor GC execution will take much longer.

Minor GC trigger mechanism:

Minor GC will be triggered when the light generation is full. The younger generation here refers to Eden generation full, while Survivor full will not trigger GC.

It happened in GC--Major GC/Full GC in the old days.

MajorGC: mainly to clean up the old days: the speed of MajorGC is generally more than 10 times slower than Minor GC

Full GC: mainly to clean up the entire heap space-including the younger generation and the older generation.

First, many Major GC are triggered by Minor GC, so in many cases it is not possible to separate the two types of GC.

On the other hand, many modern garbage collection mechanisms clean up some of the old space, so the use of the word "cleaning" is only partially correct.

This allows us not to care whether it is called Major GC or Full GC, we should pay attention to whether the current GC stops all application threads or can process concurrently without stopping application threads.

GC (Major GC/Full GC): refers to the GC that occurred in the old years, with the emergence of Major GC, which is often accompanied by Minor GC at least once (but not absolutely, there is a policy selection process for Major GC directly in the collection strategy of the ParallelScavenge collector).

Full GC trigger mechanism:

(1) when calling System.gc, the system recommends that Full GC be executed, but not necessarily.

(2) lack of space in the old years.

(3) insufficient space in the method area: Full GC will also be triggered when the permanent generation / metadata space is full, which will lead to the unloading of Class and method meta-information.

(4) the average size of memory entering the old age after passing Minor GC is larger than the available memory of the old age.

(5) when replicating from Eden and survivor space1 (From Space) regions to survivor space2 (To Space) regions, the size of the object is larger than the available memory of To Space, then the object is transferred to the old age, and the available memory of the old age is less than the size of the object.

The definition of Full GC is relatively clear, which is the global scope of GC for the whole Cenozoic, old age and metaspace (perm gen is replaced by metaspace,java8 or above).

Minor GC and Major GC are commonly known, which can roughly correspond to a combination of Young GC and Old GC algorithms in Serial GC, Parallel GC, CMS and G1 GC implemented by Hotspot JVM.

The first attempt is to output through jstat:

My-precious: me$ jstat-gc-t 4235 1sTime S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 5.734048.0 34048.0 34048.0 272640.0 194699.7 1756416.0181419.9 18304.0 17865.1 2688.02497.6 3 0.275 0 0.000 0.275 6. 7 34048.0 34048.0 34048.0 0.0 272640.0 247555.4 1756416.0 263447.9 18816.0 18123.3 2688.0 2523.1 4 0.359 0 0.000 0.359 7.7 34048.0 34048.0 0.0 34048.0 272640.0 257729.3 1756416.0 345109.8 19072.0 18396.6 2688.0 2550.3 5 0.451 0 0.000 0.451 8.7 34048 . 0 34048.0 34048.0 34048.0 272640.0 272640.0 1756416.0 444982.5 19456.0 18681.3 2816.0 2575.8 7 0.550 0 0.000 0.550 9.7 34048.0 34048.0 34046.7 0.0 272640.0 16777.0 1756416.0 587906.3 20096.0 19235.1 2944.0 2631.8 8 0.720 0 0.000 0.72010.7 34048.0 34048.0 0.0 34046.2 272640.0 80171.6 1756416.0 664913.4 20352.0 19495.9 2944.0 2657.4 9 0.810 0 0.000 0.81011.7 34048.0 34048.0 34048.0 0.0 272640.0 129480.8 1756416.0 745100.2 20608.0 19704.5 2944.0 2678.4 10 0.896 0 0.000 0.89612.7 34048.0 34048.0 0.0 34046.6 272640.0 164070.7 1756416.0 822073.7 20992.0 19937.1 3072.0 2702.8 11 0.978 0 0.000 0.97813.7 34048.0 34048.0 34048.0 0.0 272640.0 211949.9 1756416.0 897364.4 21248.0 20179.6 3072.0 2728.1 12 1.087 1 0.004 1.09114.7 34048.0 34048.0 0.0 34047.1 272640 . 0 245801.5 1756416.0 597362.6 21504.0 20390.6 3072.0 2750.3 13 1.183 2 0.050 1.23315.7 34048.0 34048.0 0.0 34048.0 272640.0 21474.1 1756416.0 757347.0 22012.0 20792.0 3200.0 2791.0 15 1.336 2 0.050 1.38616.7 34048.0 34048.0 34047.0 0.0 272640.0 48378. 0 1756416.0 838594.4 22268.0 21003.5 3200.0 2813.2 16 1.433 2 0.050 1.484

This segment was extracted 17 seconds after JVM was started. Based on this information, we can get the result that we ran Minor GC 12 times and Full GC 2 times for a total time span of 50 milliseconds.

Java-XX:+PrintGCDetails-XX:+UseConcMarkSweepGC eu.plumbr.demo.GarbageProducer

3.157: [GC (Allocation Failure) 3.157: [ParNew: 272640K-> 34048K (306688K), 0.0844702 secs] 272640K-> 69574K (2063104K), 0.0845560 secs] [Times: user=0.23 sys=0.03, real=0.09 secs] 4.092: [GC (Allocation Failure) 4.092: [ParNew: 306688K-> 34048K (306688K), 0.1013723 secs] 342214K-> 136584K (2063104K), 0.1014307 secs] [Times: user=0.25 sys=0.05, real=0.10 secs]. Cut for brevity... 11.292: [GC (Allocation Failure) 11.292: [ParNew: 306686K-> 34048K (306688K), 0.0857219 secs] 971599K-> 779148K (2063104K), 0.0857875 secs] [Times: user=0.26 sys=0.04, real=0.09 secs] 12.140: [GC (Allocation Failure) 12.140: [ParNew: 306688K-> 34046K (306688K), 0.0821774 secs] 1051788K-> 856120K (2063104K), 0.0822400 secs] [Times user=0.25 sys=0.03: Real=0.08 secs] 12.989: [GC (Allocation Failure) 12.989: [ParNew: 306686K-> 34048K (306688K), 0.1086667 secs] 1128760K-> 931412K (2063104K), 0.1087416 secs] [Times: user=0.24 sys=0.04, real=0.11 secs] 13.098: [GC (CMS Initial Mark) [1 CMS-initial-mark: 897364K (1756416K)] 936667K (2063104K), 0.0041705 secs] [Times: user=0.02 sys=0.00] Real=0.00 secs] 13.102: [CMS-concurrent-mark-start] 13.341: [CMS-concurrent-mark: 0.238/0.238 secs] [Times: user=0.36 sys=0.01, real=0.24 secs] 13.341: [CMS-concurrent-preclean-start] 13.350: [CMS-concurrent-preclean: 0.009/0.009 secs] [Times: user=0.03 sys=0.00 Real=0.01 secs] 13.350: [CMS-concurrent-abortable-preclean-start] 13.878: [GC (Allocation Failure) 13.878: [ParNew: 306688K-> 34047K (306688K), 0.0960456 secs] 1204052K-> 1010638K (2063104K), 0.0961542 secs] [Times: user=0.29 sys=0.04, real=0.09 secs] 14.366: [CMS-concurrent-abortable-preclean: 0.917max 1.016 secs] [Times: user=2.22 sys=0.07] Real=1.01 secs] 14.366: [GC (CMS Final Remark) [YG occupancy: 182593 K (306688 K)] 14.366: [Rescan (parallel), 0.0291598 secs] 14.395: [weak refs processing, 0.0000232 secs] 14.395: [class unloading, 0.0117661 secs] 14.407: [scrub symbol table, 0.0015323 secs] 14.409: [scrub string table, 0.0003221 secs] [1 CMS-remark: 976591K (1756416K)] 1159184K (2063104K) 0.0462010 secs] [Times: user=0.14 sys=0.00, real=0.05 secs] 14.412: [CMS-concurrent-sweep-start] 14.633: [CMS-concurrent-sweep: 0.221/0.221 secs] [Times: user=0.37 sys=0.00, real=0.22 secs] 14.633: [CMS-concurrent-reset-start] 14.636: [CMS-concurrent-reset: 0.002/0.002 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

Before nodding to this conclusion, let's take a look at the output from the garbage collection log that starts collection from the same JVM. Obviously-XX: + PrintGCDetails tells us a different and more detailed story:

Based on this information, we can see that after 12 times of Minor GC, it began to be a little different from the above. Instead of running Full GC twice, the difference is that a single GC runs twice at different stages in the permanent generation:

The initial marking phase took about 0.0041705 seconds, or about 4ms. This phase pauses the "stop-the-world" event, stops all application threads, and then starts marking.

The marking and cleaning phases are performed in parallel. These are all in parallel with application threads. The final Remark phase took about 0.0462010 seconds to 46ms. All events will be suspended again at this stage. Perform cleanup operations in parallel. As the name suggests, this phase is also parallel and does not stop other threads.

So, as we can see from the garbage collection log, Major GC is actually executed to clean up the old space, not Full GC twice.

Thank you for your reading, the above is the content of "what's the difference between Minor GC, Major GC and Full GC". After the study of this article, I believe you have a deeper understanding of the difference between Minor GC, Major GC and Full GC. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.