Note source: Silicon Valley JVM complete tutorial, millions of playback, the peak of the entire network (Song Hongkang details Java virtual machine)

Update: gitee.com/vectorx/NOT…

Codechina.csdn.net/qq_35925558…

Github.com/uxiahnan/NO…

[TOC]

5. Analyze GC logs

5.1. The GC classification

In the implementation of HotSpot VM, there are two types of GC in the collection region: Partial GC and Full GC.

  • Partial GC: Garbage collection that does not collect the entire Java heap. Which are divided into:

    • Minor GC/Young GC: This is only garbage collection for the New generation (Eden/S0, S1)
    • Major GC (Old GC) : Just Old GC. Currently, only the CMS GC has a separate collection behavior for older generations.Note that there are many times when the Major GC is confused with the Full GC, and you need to be specific about whether it is old age or whole heap.

  • Mixed GC: Collects garbage from the entire new generation and part of the old generation. Currently, only the G1 GC has this behavior

  • Full GC: Collects the entire Java heap and method area garbage collection.

5.2. GC log classification

MinorGC

MinorGC (or Young GC or YGC) logs:

[GC (Allocation Failure) [PSYoungGen: 31744K->2192K (36864K) ] 31744K->2200K (121856K), 0.0139308 secs] [Times: user=0.05 sys=0.01, real=0.01 secs]
Copy the code

FullGC

[Full GC (Metadata GC Threshold) [PSYoungGen: 5104K->0K (132096K) ] [Par01dGen: 416K->5453K (50176K) ]5520K->5453K (182272K), [Metaspace: 20637K->20637K (1067008K) ], 0.0245883 secs] [Times: user=0.06 sys=0.00, real=0.02 secs]
Copy the code

5.3. GC log structure analysis

See the garbage collector through the logs

  • Serial collector: New Generation displays “[DefNew”, i.e. Default New Generation

  • ParNew collector: New Generation displays “[ParNew”, i.e. Parallel New Generation

  • The Parallel insane collector: the Cenozoic insane show “[PSYoungGen”, the same as the PSYoungGen used in JDK1.7

  • Parallel Old collector: “[ParoldGen”

  • G1 collector: Displays “garbage-first heap”

See the GC cause through the log

  • Allocation Failure: Indicates that GC is caused this time because there are not enough areas in the new generation to store the data that needs to be allocated
  • Metadata GCThreshold: The Metaspace area is insufficient
  • FErgonomics: GC caused by JVM adaptive tuning
  • System: The system.gc () method is called

See before and after GC through logs

As you can see from the graph, the GC log format generally follows the following pattern: pre-GC memory footprint – > post-GC memory footprint (total memory size for this region)

[PSYoungGen: 5986K->696K (8704K) ] 5986K->704K (9216K)
Copy the code

  • In parentheses: young heap size before GC collection, size after GC collection, (total young heap size)

  • Parentheses: GC collects the size of the previous young generation and the old generation, and the size after the collection, (total size of the young generation and the old generation)

Note: The total memory capacity of the Minor GC heap = 9/10 young generation + old generation. The reason is that Survivor zone only calculates the FROM part, and the JVM defaults the ratio between Eden zone and Survivor zone in the young generation: Eden:S0:S1=8:1:1.

See GC time through log

There are three times in the GC log: User, SYS, and real

  • User: The time taken by the process to execute user-mode code (outside the core). This is the actual CPU time used to execute this process, not counting other processes and the time this process blocked. In the case of garbage collection, represents the total CPU time used by the GC thread to execute.
  • Sys: CPU time consumed by a process in kernel mode, that is, the CPU time spent executing system calls or waiting for system events in the kernel
  • Real: The clock time from start to finish of the program. This time includes the time slice used by other processes and the 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.

Because of multiple cores, real time is usually less than sys time+user time in GC events. If real > sys+user is used, your application may have the following problems: very heavy IO load or insufficient CPU.

5.4. GC log analysis tool

GCEasy

GCEasy is an online GC log analyzer that provides GC log analysis for memory leak detection, GC pause cause analysis, JVM configuration recommendations optimization, and more, most of which are free.

Official website: gceasy.io/

GCViewer

GCViewer is an offline GC log analyzer for visualizing Java VM options -verbose: DATA generated by GC and.NET -Xloggc:<file>. You can also calculate performance metrics related to garbage collection (throughput, accumulated pauses, longest pauses, and so on). This is useful when adjusting the garbage collection for a particular application by changing the generation size or setting the initial heap size.

Download the source code: github.com/chewiebug/G…

Run the download version: github.com/chewiebug/G…

GChisto

  • There is no place to download it from the official website, so you need to pull it down from SVN and compile it yourself
  • However, the tool seems to be poorly maintained, there are a lot of bugs

HPjmeter

  • The utility is powerful, but only the GC log generated by -verbose: gc-xloggc :gc.log can be opened. The gC.log generated by adding additional parameters cannot be opened
  • HPjmeter integrates with the previous HPjtune feature to analyze garbage collection log files generated on HP machines