Table of contents
Looking at the garbage collector through the log
Check the GC cause through the log
GC classification
For the implementation of HotSpot VM, the GC in it is divided into two types according to the recovery area: one is partial collection (Partial GC), and the other is full heap collection (Full GC)
- Partial collection (Partial GC): Garbage collection that does not completely collect the entire Java heap. Which is divided into:
- Young GC (Minor GC / Young GC): just the garbage collection of the new generation (Eden / S0, S1)
- Old generation collection (Major GC / Old GC): It is just the garbage collection of the old generation. Currently, only the CMS GC has the behavior of separately collecting the old generation. Note that in many cases, Major GC will be confused with Full GC, and it is necessary to specifically distinguish whether it is old-age collection or full-heap collection.
- Mixed collection (Mixed GC): Collect the entire new generation and part of the old generation garbage collection. Currently, only the G1 GC has this behavior
- Whole heap collection (Full GC): Garbage collection that collects the entire java heap and method area.
GC log classification
MinorGC
MinorGC (or young GC or YGC) log:
FullGC
Analysis of GC log structure
Looking at the garbage collector through the log
● Serial collector: The new generation displays "[DefNew", that is, Default New Generation
● ParNew collector: The new generation displays "[ParNew", that is, Parallel New Generation
● Parallel Scavenge collector: The new generation displays "[PSYoungGen", JDK1. 7 is PSYoungGen used
● Parallel Old collector: display "[ParoldGen" in the old age
● G1 collector: display "garbage-first heap"
Check the GC cause through the log
Allocation Failure: Indicates that the reason for the GC this time is that there is not enough area in the new generation to store the data that needs to be allocated
Metadata GCThreshold: The Metaspace area is not enough
FErgonomics: GC caused by JVM adaptive adjustment
System: System is called .gc() method
Look at the situation before and after GC through the log
Through the diagram, we can find that the pattern of the GC log format is generally: memory usage before GC -> memory usage after GC (total memory size in this area)
[PSYoungGen: 5986K->696K (8704K) ] 5986K->704K (9216K)- In square brackets: size of young generation heap before GC recovery, size after recovery, (total size of young generation heap)
- Outside the brackets: the size of the young generation and the old generation before GC recovery, the size after recovery, (the total size of the young generation and the old generation)
Note: Total Minor GC heap memory capacity = 9/10 young generation + old generation. The reason is that the Survivor area only calculates the from part, and the JVM defaults to the ratio between the Eden area and the Survivor area in the young generation, Eden:S0:S1=8:1:1.
View GC time through logs
There are three times in the GC log: user, sys and real
- user: The time spent by the process executing user-mode code (outside the core). This is the actual CPU time spent executing this process, not counting other processes and the time this process was blocked. In the case of garbage collection, the total CPU time used by the GC thread execution.
- sys: CPU time consumed by the process in kernel mode, that is, the CPU time used by the kernel to execute system calls or wait for system events
- real: Clock time taken by the program from start to finish. This time includes time slices used by other processes and time the process is blocked (such as waiting for I/O to complete). For parallel GC, this number should be close to (user time + system time) divided by the number of threads used by the garbage collector.
Due to multi-core reasons, in general GC events, the real time is less than sys time + user time, because generally multiple threads do GC concurrently, so the real time is less than sys + user time. If real>sys+user, your application may have the following problems: IO load is very heavy or CPU is not enough.
GC log analysis tool
GCEasy
GCEasy is an online GC log analyzer, which can perform functions such as memory leak detection, GC pause cause analysis, and JVM configuration suggestion optimization through GC log analysis. Most of the functions are free.
Official website address: Universal JVM GC analyzer - Java Garbage collection log analysis made easy
GCViewer
GCViewer is an offline GC log analyzer for visualizing data generated by Java VM options -verbose:gc and .NET -Xloggc:<file>. Performance metrics related to garbage collection can also be calculated (throughput, accumulated pauses, longest pauses, etc.). This feature is useful when tuning garbage collection for a particular application by changing the generation size or setting the initial heap size.
Running version download: Changelog chewebug/GCViewer Wiki GitHub