First, let's introduce what GC is:
The Java GC (Garbage Collection, Garbage Collection, Garbage Collection) mechanism is one of the main differences between Java and C++/C. As a Java developer, you generally do not need to write special memory recycling and garbage cleaning code, and it is not necessary to deal with the problems of memory leaks and overflows. , and you don't need to be as wary as a C programmer. This is because in the Java virtual machine, there is an automatic memory management and garbage cleaning mechanism. In a nutshell, this mechanism marks the memory in the JVM (Java Virtual Machine), and determines which memory needs to be reclaimed. According to a certain reclamation strategy, the memory is automatically reclaimed, and the memory in the JVM is guaranteed to never stop (Nerver Stop). space to prevent memory leaks and overflow problems.
Before the emergence of the Java language, there was a GC mechanism, such as the Lisp language), and the Java GC mechanism has been perfected and can almost automatically do most of the things for us. However, if we are engaged in the development of larger application software and there has been a need for memory optimization, we must study the Java GC mechanism.
How we get GC logs:
One is to use the command to dynamically view,
17997 is the so-called pid, the id of the application process.
It is also possible to set intervals to print at a fixed time:
The gc condition of 1262 is output every 2000ms, a total of 20 times.
One is to set relevant parameters in the container to print the GC log.
The parameters of the JVM's GC log are set as follows:
----- XX:+PrintGC Output GC log
------XX:+PrintGCDetails Output the detailed log of GC
------XX:+PrintGCTimeStamps output timestamp of GC
------XX:+PrintGCDateStamps output timestamp of GC
------XX:+PrintHeapAtGC Print out heap information before and after GC
------Xloggc:../logs/gc.log The output path of the log file
Next, let's analyze the gc log Young GC recovery log:
2016-07-05T10:43:18.093+0800: 25.395: [GC [PSYoungGen: 274931K->10738K(274944K)] 371093K->147186K(450048K), 0.0668480 secs] [Times: user=0.17 sys=0.08, real=0.07 secs]
Full GC recycling log:
10738K->0K(274944K)] [ParOldGen: 136447K->140379K(302592K)] 147186K->140379K(577536K) [PSPermGen: 85411K->85376K(171008K)], 0.6763541 secs] [Times: user=1.75 sys=0.02, real=0.68 secs]
According to the above log analysis, PSYoungGen, ParOldGen, and PSPermGen belong to the Parallel collector. Among them, PSYoungGen represents the memory change of the young generation before and after gc reclamation; ParOldGen represents the memory change of the old generation before and after gc reclamation; PSPermGen represents the memory change of the permanent area before and after gc reclamation. Young gc mainly recycles memory frequently for the young generation and takes a short time; full gc returns the entire heap memory to the city, which takes a long time, so generally try to reduce the number of full gc as much as possible
Analyze the composition of the gc log through two figures:
Young GC log:
Full GC log:
