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

This article mainly introduces "how to understand the memory overflow problem in Java". In the daily operation, I believe many people have doubts about how to understand the memory overflow problem in Java. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubt of "how to understand the memory overflow problem in Java"! Next, please follow the editor to study!

First, the cause of memory overflow

Memory overflow means that there is not enough memory. There are many reasons for memory overflow. The common ones are as follows:

1. The amount of data loaded in memory is too large, such as fetching too much data from the database at one time.

2. There is a reference to the object in the collection class, which is not cleared after use, so that the JVM cannot be recycled.

3. There is an endless loop in the code or an object entity whose loop produces too much repetition.

4. BUG in the third-party software used

5. The memory value of startup parameters is too small.

Of course, in reality, there are too many reasons for memory overflow. Let's classify these reasons:

The above figure is based on java7, from which we can get the following information: the java virtual machine divides the memory into five modules.

(1) Program counter: the program counter is private to the thread, and its main function is to select the next bytecode instruction to be executed by changing the value of the counter. Since each thread has one, the counters of these threads do not affect each other. And no exception will be thrown.

(2) Virtual machine stack and local method stack: virtual machine stack describes the memory model of java method execution, and each method creates a stack frame to store local variable table, Operand stack, dynamic connection, method exit and other information. The difference between the local method stack and the virtual machine stack is that the virtual machine stack performs java method services for the virtual machine, while the local method stack provides native method services for the virtual machine.

In single-threaded operations, no matter because the stack frame is too large or the virtual machine stack space is too small, when the stack space can not be allocated, the virtual machine will throw a StackOverflowError exception, but will not get an OutOfMemoryError exception. In a multithreaded environment, an OutOfMemoryError exception is thrown.

(3) java heap and method area: the java heap area mainly stores object instances and arrays, and the method area stores class information, constants, static variables and so on. The run-time pool is also part of the method area. These two areas are shared by threads and only OutOfMemoryError is thrown.

I don't know if you have seen the classic interview scene in bilibili. When answering the memory running data area structure of java, the above function is on the one hand, if you add the memory overflow question when answering, it is a great addition.

Second, memory overflow instance

1. Heap overflow

Since the heap holds instance objects, let's create instance objects wirelessly. The stacking area will be full sooner or later.

Public class HeapOOM {static class User {} public static void main (String [] args) {List list = new ArrayList (); while (true) {list.add (new User ());}} / * Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded at com.fdd.test.HeapOOM.main (HeapOOM.java:11) * /

Because I set up the heap memory in advance, infinite creation will throw an exception.

2. Virtual machine stack and local method stack overflow

Two exceptions are described in the Java virtual machine specification:

If the stack depth requested by the thread is greater than the maximum allowed by the virtual machine lock, a StackOverflowError exception is thrown.

If the virtual machine cannot apply for sufficient memory space when expanding the stack, an OutOfMemoryError exception is thrown.

In the first, we only need to use the method recursive call to simulate:

Public class StackOutOfMemoryError {public static void main (String [] args) {test ();} private static void go () {System.out.println ("StackOverflowError exception"); test () } / * Exception in thread "main" java.lang.StackOverflowError at sun.nio.cs.ext.DoubleByte$Encoder.encodeLoop (DoubleByte.java:617) at java.nio.charset.CharsetEncoder.encode (CharsetEncoder.java:579) at sun.nio.cs.StreamEncoder.implWrite (StreamEncoder.java:271) at sun.nio.cs.StreamEncoder.write (StreamEncoder.java:125) at java.io.OutputStreamWriter.write (OutputStreamWriter.java:207) at java.io.BufferedWriter.flushBuffer (BufferedWriter .java: 129) at java.io.PrintStream.write (PrintStream.java:526) at java.io.PrintStream.print (PrintStream.java:597) at java.io.PrintStream.println (PrintStream.java:736) at com.fdd.test.StackOutOfMemoryError.go (StackOutOfMemoryError.java:11) at com.fdd.test.StackOutOfMemoryError.go (StackOutOfMemoryError.java:13) * /

The second can also call the impersonation recursively, but it is called directly by the class.

Public class JavaVMStackSOF {private int stackLength = 1; public void stackLeak () {stackLength++; stackLeak ();} public static void main (String [] args) {JavaVMStackSOF oom = new JavaVMStackSOF (); oom.stackLeak () }} / * Exception in thread "main" java.lang.StackOverflowError at com.lindaxuan.outofmemory.JavaVMStackSOF.stackLeak (JavaVMStackSOF.java:18) at com.lindaxuan.outofmemory.JavaVMStackSOF.stackLeak (JavaVMStackSOF.java:19) at com.lindaxuan.outofmemory.JavaVMStackSOF.stackLeak (JavaVMStackSOF.java:19) at com.lindaxuan.outofmemory.JavaVMStackSOF.stackLeak (JavaVMStackSOF.java:19) at com.lindaxuan.outofmemory.JavaVMStackSOF.stackLeak (JavaVMStackSOF.java:19) at com.lindaxuan .outofroomy.JavaVMStackSOF.stackLeak (JavaVMStackSOF.java:19) at com.lindaxuan.outofmemory.JavaVMStackSOF.stackLeak (JavaVMStackSOF.java:19) at com.lindaxuan.outofmemory.JavaVMStackSOF.stackLeak (JavaVMStackSOF.java:19) at com.lindaxuan.outofmemory.JavaVMStackSOF.stackLeak (JavaVMStackSOF.java:19). * /

3. Method zone and runtime constant pool overflow

Public class JavaMethodAreaOOM {public static void main (String [] args) {while (true) {Enhancer enhancer = new Enhancer (); enhancer.setSuperclass (User.class); enhancer.setUseCache (false) Enhancer.setCallback (new MethodInterceptor () {public Object intercept (Object obj, Method method, Object [] args, MethodProxy proxy) throws Throwable {return proxy.invokeSuper (obj, args);}}); enhancer.create () } static class User {}} / * Exception in thread "main" Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main" * /

4. Native direct memory overflow

The DirectMemory capacity can be specified by-XX: MaxDirectMemorySize, which, if not specified, is by default the same as the Java heap maximum (specified by-Xmx).

Public class DirectMemoryOOM {private static final int _ 1MB = 1024 * 1024; public static void main (String [] args) throws Exception {Field unsafeField = Unsafe.class.getDeclaredFields () [0]; unsafeField.setAccessible (true); Unsafe unsafe = (Unsafe) unsafeField.get (null); while (true) {unsafe.allocateMemory (_ 1MB);}

Several examples are introduced above, so how to troubleshoot this kind of problem?

Third, memory overflow troubleshooting

In fact, the most important thing to troubleshoot is to check the code, and memory overflows are often the problem of the code. Of course, there are a few points to pay attention to:

(1) the amount of data loaded in memory is too large, such as fetching too much data from the database at one time.

(2) there is a reference to the object in the collection class, which is not cleared after use, so that JVM cannot be recycled.

(3) there is an endless loop or an object entity that produces too much repetition in the code.

(4) BUG in the third-party software used

(5) the memory value of startup parameters is too small.

In the end, it was solved.

The first step is to modify the JVM startup parameters to directly increase memory.

Step two, check the error log

The third step is to walk through and analyze the code to find out where the memory overflow may occur.

In general, the probability of code errors will be higher, of course, different scenarios and different errors are always complex and diverse.

At this point, the study on "how to understand the memory overflow in Java" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.