Java service and MEMORY OOM How can I quickly locate the fault?

A friend recently asked: “There is a Java service that has OOM(Out Of Memory) problems. It has been located for a long time and cannot be fixed. Do you have any good ideas?” I have written about OOM’s problems before. Here I summarize some relatively common solutions, hoping to help students with Java technology stack.

OOM occurs in a Java service (assume PID=10765). The most common reasons are as follows:

 It is possible that the memory allocation is too small and normal business uses a lot of memory

 An object is frequently applied for but not released, and the memory leaks continuously

 The system resources are exhausted due to frequent application for a certain resource. For example, you keep creating threads and initiating network connections

Voiceover: No more than “insufficient resources”, “too many application resources”, “resource exhaustion” several reasons.

To be more specific, use the following tools.



Jmap-heap 10765 can be used to check the size and usage of the new generation and old generation of heap memory, and see if the memory itself is too small.

Second, find the memory consumption object method: jmap – histo: live 10765 | more



As shown in the figure above, the command displays information about the living objects in a table, sorted by memory usage:

 instance number

 Memory usage

 the name of the class

Is that intuitive? For instances/classes with large number of instances and large memory footprint, the relevant code should be reviewed accordingly. In the preceding figure, RingBufferLogEvent occupies the largest amount of memory, occupying 18 MB of memory.

If you find that a class of objects takes up a lot of memory (for example, several gigabytes), it is likely that too many class objects have been created and have not been released. For example,  Close () or dispose() is not used to release resources after the resource application is complete.  Consumers consume slowly (or stop consuming), and the producers keep sending tasks to the queue. As a result, too many tasks accumulate in the queue. Alternatively, memory can be dumped for analysis.

Three, confirm whether it is resource exhaustion tool:

 pstree

 netstat

Check the number of threads created by the process and the number of network connections. If resources are exhausted, OOM may appear. Here’s another way to do it

 /proc/katex parse error: Unexpected character: ‘’ at position 10: {PID}/fd ̲/proc/{PID}/task

You can view handle details and thread counts respectively. For example, the PID of the SSHD process on an online server is 9339

 ll/proc / 9339 / fd

 ll/proc / 9339 / task



As shown in the figure above, SSHD occupies four handles

0 -> Standard input

1 -> Standard output

2 -> Standard error output

3 -> Socket

SSHD has only one main thread PID of 9339, and no multithreading.

ll /proc/katex parse error: Unexpected character: ‘’ at position 18:… ID} / fd | wc -l  ̲ ll/proc / {PID} / task | wc -l (pstree effect equivalent – p | wc -l) can know the process handle to open the number and the number of threads.