Reprinted: https://blog.csdn.net/xuqu_volition/article/details/53786096
introduction
This article only focuses on some common virtual machine memory monitoring methods, as well as the occurrence of memory overflow in various parts of the JVM runtime data area and the corresponding solutions. Generally speaking, it is a general summary, which is relatively in-depth. The purpose is to make myself and others Beginners have a framework and conceptual understanding, and when encountering problems, there are traces to follow, and they will not be overwhelmed.
First, the virtual machine memory monitoring method
Common problems of virtual machines include: memory leaks, memory overflows, frequent GC performance degradation, etc. The reasons for these problems can be analyzed by the following virtual machine memory monitoring methods. The specific implementation may need to be flexibly selected. Even more means to jointly analyze.
For example, the GC log can analyze which GCs frequently cause performance degradation and whether memory leaks occur. The jstat tool is similar to the GC log, and can also view the GC situation and analyze whether a memory leak occurs. After judging that a memory leak has occurred, you can use the combination of the jmap tool and MAT and other analysis tools to view the virtual machine memory snapshot to analyze the cause of the memory leak. The memory overflow snapshot can analyze the cause of the memory overflow and so on.
GC logging
Record each time the JVM performs GC. By observing the GC log, you can see the frequency of GC and which areas of memory are reclaimed by each GC. Adjust JVM-related settings based on this information, which can reduce Minor GC. The frequency and the number of Full GCs can also determine whether there is a memory leak.
The following are common GC log output parameters:
u -verbose.gc: Displays the operation content of GC. Turn it on to display when the busiest and most idle collection behavior occurs, the amount of memory before and after collection, the time it takes to collect, and more.
u -XX:+printGCdetails: Learn more about changes in GC.
u -XX:+PrintGCTimeStamps: Get the time when garbage collection occurred, measured in seconds since the JVM started.
u -XX:+PrintHeapAtGC: Get more detailed information about the heap.
u -Xloggc:[file]: output GC information to a separate file
jstat: Virtual Machine Statistics Monitoring Tool
Real-time monitoring of class loading, memory usage of each part, GC, JIT compilation, etc. when the virtual machine is running.
Example: Query the garbage collection status of process 2211 every 250ms, query 50 times
Step 1: jps lists all running jvm instances on the machine and obtains the pid of jvm
Step 2: jstat monitors the gc situation in real time, jstat –gc 2211 250 50
Other parameters include:
-class monitors the number of class loads, unloads, total space, and time spent in class loading
The monitoring content of -gccapacity is the same as that of -gc. The output mainly focuses on the maximum and minimum space used by each area of the heap.
-gcutil monitoring is the same as -gc, the output mainly focuses on the percentage of the total space used by each area of the heap
-gcnew monitors the new generation GC situation
-gcold monitors old generation GC situation
jmap: virtual machine memory mapping tool
The jmap tool allows the running JVM to generate a Dump file. When there is a problem with the JVM memory, a snapshot can be generated through jmap to analyze the entire heap. It mainly goes through two steps:
Step 1: jps lists all running jvm instances on the machine and obtains the pid of jvm
Step 2: Use the jmap command to export the specified JVM snapshot as a dump file
jmap -dump:format=b,file=path/heap.bin PID
After obtaining the dump file of the JVM snapshot, it can be analyzed by the MAT tool.
The MAT (MemoryAnalyzer Tool) tool is a plug-in of eclipse, which is very convenient to use, especially when analyzing dump files with large memory, you can intuitively see the memory size, number of class instances, The object reference relationship, the use of OQL object query, and the related information of object GC Roots can be easily found. The most attractive thing is that it can quickly generate a memory leak report for developers, which is convenient for locating and analyzing problems.
In addition, jmap can also query the finalize execution queue, java heap and persistent generation details, such as space usage, which collector is currently in use, etc.
out-of-memory snapshot generation
By setting JVM parameters, a dump file can be automatically generated when an OutOfMemoryError (OOM) memory overflow occurs in the virtual machine. By analyzing the dump file and viewing the memory usage, the cause of the memory overflow can be found:
-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=/path/to/heap/dump
After obtaining the dump file of the JVM snapshot, it can be analyzed by the MAT tool.
2. Runtime data area memory overflow
The JVM runtime data area is divided into the following parts:
The method area and heap are shared by all worker threads, while the stack, program counter and local method stack are thread-private.
Note: The picture is transferred from the Internet
1. Program Counter
Role: point to the address of the next bytecode instruction that needs to be executed in the current thread
Out of memory: does not happen
2. Virtual machine stack
Function: It consists of stack frames, each stack frame represents a method call, which includes three parts: storage variable table, operand stack and method exit. After the method is executed, the stack frame will be popped up.
Out of memory: StackOverflowError and OutOfMemoryError.
Overflow reason:
StackOverflowError: If the depth of the requested stack is greater than the depth allowed by the virtual machine, this exception will be thrown. If the default parameters of the virtual machine are used, there is generally no problem with the depth of 1000 to 2000.
OutOfMemoryError: Because the heap memory and method area capacity are removed, the remaining memory is divided between the virtual machine stack and the local method stack. If the remaining memory is not enough to run more worker threads, or not enough to expand the virtual machine stack At that time, an OutOfMemoryError exception will be thrown.
Solution:
For StackOverflowError:
1. First, the stack overflow will output exception information. According to the information, check whether the corresponding method call has an infinite call, or the stack frame is too large and other code logic problems, which can be solved by modifying the code logic;
2. If you really need a larger stack capacity, you can check and adjust the stack capacity: -Xss16m.
For OutOfMemoryError:
1. First check whether too many threads are created and reduce the number of threads
2. It can be solved by "reducing the maximum heap size" or "reducing the stack size".
3. Native method stack
Function: The only difference from the virtual machine stack is that the virtual machine stack executes java methods, while the local method stack executes local C/C++ methods
Out of memory: StackOverflowError and OutOfMemoryError
Overflow reason: the same as the virtual machine stack
Solution: same as virtual machine stack
4. Heap
Role: shared by all threads, storing object instances
Out of memory: OutOfMemoryError: Java heap space
Overflow reason: there is not enough memory in the heap to complete the instance allocation and cannot continue to expand
Solution:
1. Memory leak check: First, use "memory overflow snapshot + MAT and other analysis tools" to analyze whether there is a memory leak. When checking, you can suspect points such as collections, third-party libraries such as the use of database connections, and new keywords.
2. If there is no memory leak, then it is a memory overflow, but all objects still need to survive. At this time, you can only adjust the large heap memory: -Xms and -Xmx.
5. Method area
Role: shared by all threads, storing loaded class information, constants, static variables and just-in-time compiled code
Out of memory: OutOfMemoryError: PermGen space
Overflow reason: There is not enough memory in the method area to complete the memory allocation to store the newly loaded class information at runtime
Solution:
1. Memory leak check: Check whether too many class files (jar files) are loaded, or the same class file (jar file) is loaded multiple times
2. Increase the method area size by -XX:PermSize=64M -XX:MaxPermSize=128M
6. Runtime constant pool
Role: part of the method area, storing constants
Out of memory: OutOfMemoryError: PermGen space
Overflow reason: There is not enough memory in the method area to complete the memory allocation and store the constants newly created at runtime, such as the intern() method of the String class. Its function is to return its reference if the constant pool already contains the same string, otherwise Adds the string contained by this String object to the constant pool.
Solution:
1. Memory leak check: Check if too many constants are created
2. Increase the method area size by -XX:PermSize=64M -XX:MaxPermSize=128M
7. Direct memory
Function: It does not belong to the JVM runtime data area, nor is it the memory area defined in the virtual machine specification. The NIO introduced by JDK1.4 includes the channel Channel and the buffer buffer. The application obtains data from the channel through the kernel buffer of the OS first. , and then copied to Buffer, because it is time-consuming, so Buffer provides a way to directly operate the operating system buffer, namely ByteBuffer.allocateDirector(size), this method returns the DirectByteBuffer application to point to the buffer associated with the underlying storage space, That is, direct memory (native memory), or off-heap memory.
Out of memory: OutOfMemoryError
Overflow reason: memory required by JVM + direct memory > machine physical memory (or operating system level limit), cannot be dynamically expanded
Judgment method: Memory leak check: For example, the memory usage is high, and the machine performance drops sharply, but there are few GCs found through GC information or jstat, and no abnormality is found after the snapshot analysis through jmap, and the program directly or indirectly uses When it comes to NIO, then and may be a direct memory leak.
Solution: Analyze NIO-related program logic to solve.