Shulou(Shulou.com)06/02 Report--

How to solve the problem of jvm memory overflow java.lang.OutOfMemoryError: GC overhead limit exceeded, aiming at this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

Error log message java.lang.OutOfMemoryError: GC overhead limit exceeded2020-06-16 10 http-nio-8083-exec-91 ERROR o.a.c.core.ContainerBase.[ tomcat] .localhost-Exception Processing ErrorPage [errorCode=0, location=/error] org.springframework.web.util.NestedServletException: Handler processing failed Nested exception is java.lang.OutOfMemoryError: GC overhead limit exceeded at org.springframework.web.servlet.DispatcherServlet.doDispatch (DispatcherServlet.java:1061) at org.springframework.web.servlet.DispatcherServlet.doService (DispatcherServlet.java:942) at org.springframework.web.servlet.FrameworkServlet.processRequest (FrameworkServlet.java:1005) at org.springframework.web.servlet.FrameworkServlet.doGet (FrameworkServlet.java:897) at javax.servlet.http.HttpServlet.service (HttpServlet . Java: 634) at org.springframework.web.servlet.FrameworkServlet.service (FrameworkServlet.java:882) at javax.servlet.http.HttpServlet.service (HttpServlet.java:741) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:231) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:166) at org.apache.catalina.core.ApplicationDispatcher.invoke (ApplicationDispatcher.java:712) At org.apache.catalina.core.ApplicationDispatcher.processRequest (ApplicationDispatcher.java:461) at org.apache.catalina.core.ApplicationDispatcher.doForward (ApplicationDispatcher.java:384) at org.apache.catalina.core.ApplicationDispatcher.forward (ApplicationDispatcher.java:312) at org.apache.catalina.core.StandardHostValve.custom (StandardHostValve.java:394) at org.apache.catalina.core.StandardHostValve.status (StandardHostValve.java:253) at org. Apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:175) at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:92) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:74) at org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:343) at org.apache.coyote.http11.Http11Processor.service (Http11Processor.java:367) at org.apache.coyote.AbstractProcessorLight .process (AbstractProcessorLight.java:65) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process (AbstractProtocol.java:868) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun (NioEndpoint.java:1639) at org.apache.tomcat.util.net.SocketProcessorBase.run (SocketProcessorBase.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java: 624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run (TaskThread.java:61) at java.lang.Thread.run (Thread.java:748) Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded problem cause

Use the ps command to find out the pid on which the jar is running, and then look at the details of the java heap and find that the memory is 99%.

Reason 1: the initial memory configuration is indeed too small

Reason 2: related code logic problems lead to memory overflow

Jmap-heap PID

Problem solving

For the time being, increase the Heap Size:

-Xmx4000m-Xms4000m

After adjustment:

Summary

Focus on checking the logic of the code. If it is the code, increasing heap memory can only delay the generation of java.lang.OutOfMemoryError, which will eventually lead to memory overflow.

JVM parameter

JVM startup parameters are divided into three categories:

Standard parameters (-), all JVM implementations must implement the functionality of these parameters and be backward compatible

Non-standard parameters (- X) refer to some of the underlying configuration parameters of JVM, which are available by default in general development and do not require any configuration. However, in the production environment, all jvm implementations are not guaranteed, so in order to improve performance, it is often necessary to adjust these parameters in order to achieve the best performance of the system. In addition, these parameters are not guaranteed to be backward compatible, that is, "if there is any change, it will not be notified in the subsequent version of JDK" (this is the original phrase on the official website).

Non-Stable parameter (- XX). This kind of parameter is unstable in jvm and is not suitable for daily use. It may be cancelled without notice later, so it needs to be used with caution.

Three main domains of JVM memory

Three main domains: the new domain, the old domain, and the permanent domain.

All new objects generated by JVM are placed in the new domain. Once the object goes through a certain number of garbage collection cycles, it enters the old domain. The persistent domain is used to store JVM's own reflection objects, such as class and method objects, and GC (Garbage Collection) does not clean up the permanent domain while the main program is running (the main reason). The new domain and the old domain belong to the heap, and the permanent domain is a separate domain and is not considered to be part of the heap.

The role of the main parameters

-Xms: sets the initial size of jvm memory

-Xmx: sets the maximum value of jvm memory

-Xmn: set the size of the new domain (this seems to be valid only for jdk1.4 and has since been abandoned)

-Xss: sets the stack size of each thread (that is, decreasing this value generates more threads under the same physical memory)

-XX:NewRatio: sets the ratio of the new domain to the old domain. For example,-XX:NewRatio = 4 means the ratio of the new domain to the old domain is 1:4.

-XX:NewSize: sets the initial value of the new domain

-XX:MaxNewSize: sets the maximum value of the new domain

-XX:PermSize: sets the initial value of the permanent field

-XX:MaxPermSize: sets the maximum value of the permanent domain

-XX:SurvivorRatio=n: sets the ratio of Eden zones to two Survivor zones in the new domain. (the Eden area is mainly used to store newborn objects, while the two Survivor zones are used to store objects that survive each garbage collection.)

This is the answer to the question about how to solve the problem of jvm memory overflow java.lang.OutOfMemoryError: GC overhead limit exceeded. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.