1) What is OOM？OOM, the full name "Out Of Memory", translated into Chinese, means "use of memory", from. Let's take a look at the official description about it: Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector. This error will be thrown when the JVM does not have enough memory to allocate space for the object and the garbage collector has no space to recycle.
2) Why OOM?
Why is there no memory? There are only two reasons:
1) There is less allocation: For example, the virtual machine itself can use too little memory (usually specified by the VM parameters at startup).
2) Too many applications are used and not released after use, which is wasted. This will cause memory leakage or memory overflow.
Memory leak: The memory used by the application is not released, causing the virtual machine to be unable to use the memory again. At this time, this memory is leaked because the applicant no longer uses it and cannot be allocated by the virtual machine to others for use.
Memory overflow: The memory applied for exceeds the memory size that the JVM can provide, and it is called overflow at this time.
In the days when there was no automatic garbage collection, such as C and C++, we had to be responsible for the memory application and release operations. If we applied for memory and forgot to release it after use, for example, the new in C++ but no delete, then memory leakage may occur. Occasional memory leaks may not cause problems, while large amounts of memory leaks may cause memory overflow.
In the Java language, due to the existence of a garbage automatic recycling mechanism, we generally do not need to actively release the memory occupied by unused objects, which means that in theory, there will be no "memory leakage". However, if the encoding is improper, for example, putting the reference of an object into a global map, although the method is over, the garbage collector will recycle memory based on the reference of the object, resulting in the object being unable to be recycled in time. If this situation occurs more often, it will cause memory overflow, such as the cache mechanism that is often used in the system. Memory leaks in Java, unlike those in C++ who forget to delete, are often logically leaked.
3) Types of OOM
JVM memory model:
According to the JVM specification, the JAVA virtual machine manages the following memory areas when it is running:
- Program counter: the line number indicator of the bytecode executed by the current thread, thread private
- JAVA virtual machine stack: a memory model for Java methods to execute. The execution of each Java method corresponds to the operation of entering and exiting a stack frame.
- Local method stack: similar to "JAVA virtual machine stack", but provides a memory environment for the operation of native methods.
- JAVA heap: where object memory is allocated, the main area of memory garbage collection, and all threads share. It can be divided into the new generation and the old generation.
- Method area: used to store class information, constants, static variables, code compiled by the instant compiler and other data. "Permanent Generation" in Hotspot.
- Runtime constant pool: part of the method area, storing constant information, such as various literals, symbolic references, etc.
- Direct memory: It is not part of the JVM runtime data area, but directly accessible memory, such as NIO, which will be used.
According to the JVM specification, except that the program counter does not throw OOM, various memory areas may throw OOM.
There are three most common OOM situations:
- : Java heap space ------>java heap memory overflow, this situation is the most common, generally due to memory leakage or improper heap size setting. For memory leakage, memory monitoring software needs to be used to find the leaked code in the program, and the heap size can be modified by virtual machine parameters -Xms, -Xmx, etc.
- : PermGen space ----->java permanent overflow, that is, overflow in the method area, which generally occurs in a large number of Class or jsp pages, or reflective mechanisms such as cglib are adopted, because the above situation will generate a large amount of Class information stored in the method area. This situation can be solved by changing the size of the method area, using a form similar to -XX:PermSize=64m -XX:MaxPermSize=256m. In addition, too many constants, especially strings, can also cause method area overflow.
- ------> Not throwing OOM error, but it is also a relatively common Java memory overflow. The JAVA virtual machine stack overflow is generally caused by the existence of dead loops or deep recursive calls in the program. This overflow will occur if the stack size is set too small. The stack size can be set through the virtual machine parameter -Xss.
4）OOM analysis--heapdump
To dump the memory image of the heap, you can use the following two methods:
- Set JVM parameters -XX: +HeapDumpOnOutOfMemoryError, and set automatically dump heap information when OOM occurs. However, this method requires JDK5 or above.
- Use the jmap command that comes with JDK. "jmap -dump:format=b,file= <pid>" where pid can be obtained through jps.
After dumping the heap memory information, the files that dump need to be analyzed to find the reason for OOM. Commonly used tools are:
- mat: eclipse memory analyzer, a memory analysis tool based on eclipse RCP. For details, please refer to: /mat/, recommended.
- jhat: JDK comes with java heap analyze tool, which can display objects in the heap in the form of html, including the number, size, etc., and supports the object query language OQL. After analyzing related applications, you can access the analysis results through http://localhost:7000. It is not recommended to use because during the actual inspection process, you usually dump the file in the production environment first and then pull it to your own development machine to analyze. Therefore, it is better to use advanced analysis tools such as the previous mat to be efficient.
This link:/alert-zh/An example using mat analysis is provided in this article.
Note: Because the JVM specification does not define the format of the dump file, the dump files generated by different virtual machines are not the same. When analyzing, different analysis tools need to be used for the output of different virtual machines (of course, some tools can be compatible with multiple virtual machines formats). IBM HeapAnalyzer is also a commonly used tool for analyzing heaps.
This is the end of this article about the reasons and solutions of Java OOM. For more related Java OOM content, please search for my previous articles or continue browsing the related articles below. I hope everyone will support me in the future!