Javaoom to parse the dump file instead of looking at the Exception Log log cause

Directory

• Oom Exception--intsmaze
• Correct posture dump file analysis--intsmaze
• The right Posture--intsmaze
• Dump lost print--intsmaze
• Which memory overflows will generate dump files--intsmaze

The application has an Oom exception, do you still look at the log to troubleshoot the problem (the way to locate the problem is a large probability of coincidence)? The correct troubleshooting is to do dump file analysis, do you know why?

Oom Exception--intsmaze

First of all, I encountered in the development of Oom anomaly is basically also by looking at the log log to locate the (many Oom exception is because of the dead loop or the amount of data returned by the query, no paging and so on, through the Exception log we can really quickly locate, but this is not the correct posture.) ), it just happens that the log printing exception stack information is the corresponding code problem.
Many blog also said, positioning oom abnormal through the analysis dump log, so deep doubt, why clearly look at log log can solve the non-to analyze dump log, the web also did not retrieve the satisfactory answer, asked around a lot of development, also just said dump performance analysis, Log logs for exception troubleshooting. In my several reflections, suddenly enlightened, hereby write down the reasons.

An Oom exception can cause the program to crash and the process to end.

Correct posture dump file analysis--intsmaze

Please look at the big screen:

public class OOMDump {    static class OOMIntsmaze {        public byte[] placeholder = new byte[64 * 1024];    }    public static void fillHeap(ArrayList<OOMIntsmaze> list, int num) throws Exception {        for (int i = 0; i < num; i++) {            list.add(new OOMIntsmaze());            System.out.println(i);        }    }    public static void main(String[] args) throws Exception {        ArrayList<OOMIntsmaze> list = new ArrayList<OOMIntsmaze>();        fillHeap(list,131);        Thread.sleep(20000000);    }}

We configured the JVM parameters as follows-xmx10m-xx:+heapdumponoutofmemoryerror-xx:heapdumppath=d://
When Fillheap (list,131), the program executes normally, and when Fillheap (list,132), the program reports an Oom exception:

130java.lang.OutOfMemoryError: Java heap spaceDumping heap to d://\java_pid10000.hprof ...Exception in thread "main" java.lang.OutOfMemoryError: Java heap space    at cn.intsmaze.dump.OOMDump$OOMIntsmaze.<init>(OOMDump.java:27)    at cn.intsmaze.dump.OOMDump.fillHeap(OOMDump.java:34)    at cn.intsmaze.dump.OOMDump.main(OOMDump.java:47)    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)    at java.lang.reflect.Method.invoke(Method.java:498)Heap dump file created [10195071 bytes in 0.017 secs]    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)

Through the Exception Log we can see that because the code
At Cn.intsmaze.dump.OOMDump.fillHeap (oomdump.java:34)
List.add (New Oomintsmaze ());
Cause of the problem, through the log is what you see, I immediately solved the problem, why should I look at the dump log? I'm sick.

Not actually, the year of the Sao. If the main method is as follows, execute

    public static void main(String[] args) throws Exception {        ArrayList<OOMIntsmaze> list = new ArrayList<OOMIntsmaze>();        fillHeap(list,131);        Map<String,OOMIntsmaze> map=new HashMap<String,OOMIntsmaze>();        map.put("LIUYANG",new OOMIntsmaze());        map.put("intsmaze",new OOMIntsmaze());        Thread.sleep(20000000);    }

This time we found through the Exception Log because Map.put ("Liuyang", New Oomintsmaze ()); led to find code found, map inside only inserted a data, no dead loop, how can cause oom abnormal, really live long see.

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space    at cn.intsmaze.dump.OOMDump$OOMIntsmaze.<init>(OOMDump.java:27)    at cn.intsmaze.dump.OOMDump.main(OOMDump.java:49)    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)    at java.lang.reflect.Method.invoke(Method.java:498)    at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)

Set 10M we can find that the list adds 132 elements When oom occurs, this time we add 131 elements to the list, and then perform a map add, found that the map adds an element to the error. The oom Exception Log at this time is positioned as a result of the map addition element.
But the real situation is not, because look at the code will also find that the map only added 2 elements, how can it be caused by him. The addition of the map is just when the JVM memory reaches the capacity limit.
So to find the fundamental problem is the capacity state of each object that needs to be analyzed by the dump file when Oom is parsed.
And in reality, the Code for Map.put () is not placed in the same way as the example above and the List.add () code, but in different packages and in different business processes. It's impossible to look at the log log to locate this time.
But why do you go to oom abnormal or by looking at the log log and location is correct. Just because to list.add this kind of cycle, has been executing, the basic approximate rate is he triggers.

The right Posture--intsmaze

So in order to prevent the development of the program ape, be sure to configure the JVM startup parameter heapdumponoutofmemoryerror.
Parameter-xx:+heapdumponoutofmemoryerror allows the virtual machine to dump the current memory heap dump snapshot for subsequent analysis when a memory overflow exception occurs

Dump lost print--intsmaze

Sometimes our application goes down and neither does the log routine, nor does the dump file, which is basically the Linux system that killed our application process.

View/var/log/messages File

The messages log is the core system log file. It contains boot messages at system startup and other status messages when the system is running. The following information will appear in the messages.

out of memory:kill process 8398(java) score 699 or sacrifice childkilled process 8398,UID 505,(java) total-vm:2572232kB,anno-rss:1431292kB,file-rss:908kB

Oom Killer is a protection process for Linux systems that is triggered when there is not enough memory space left in the Linux system to meet the system's normal operation. When Oomkiller executes, it finds the PID with the highest score value for all threads in the system and then kills it.
Here we can see that the Java process was actually killed by the Linux Oom killer.

Both our applications and logs can only record memory overflows that occur within the JVM. If the JVM sets a heap size that exceeds the amount of memory allowed by the operating system, the operating system will kill the process directly, in which case the JVM cannot log the operation.
Linux has an Oom rating for each process, which is scored in the/proc/pid/oom_score file. For example/proc/8398/oom_score, if you do not want to kill the process, change the Oom_adj content to-17.
More about the Oom Killer mechanism of Linux please Baidu search by yourself.

Most correct posture: first adjust the JVM's heap size so that the JVM's oom takes precedence over the operating system's Oom, then sets the run parameters and outputs the Heapdump file when oom occurs.

Which memory overflows will generate dump files--intsmaze

Please go on the bus: does the JVM generate dump 51366181 for various memory overflows?