Java common error handling methods and JVM memory structure

OutOfMemoryError in the development process is commonplace, encountered this error, novice programmers know from two aspects to solve: one is to troubleshoot whether the program has a bug causing a memory leak, and the second is to adjust the JVM startup parameters to increase memory. OutOfMemoryError There are several cases, each time you encounter this error, observe the outofmemoryerror behind the message, you can find the difference, such as:

Java.lang.OutOfMemoryError:Java Heap Space
Java.lang.OutOfMemoryError:unable to create new native thread
Java.lang.OutOfMemoryError:PermGen Space
java.lang.OutOfMemoryError:Requested array size exceeds VM limit

Although all called outofmemoryerror, but the cause behind each error is not the same, the solution also depends on the situation, can not be generalize. Only in-depth understanding of the JVM's memory structure and careful analysis of the error message, it is possible to do the remedy, Shoudaobingchu.

JVM specification

The JVM specification defines several areas of the Java runtime's memory (see here): the JVM stack (Java Virtual machine Stacks), heap, methods area (method zone), Chang (Runtime Constant Pool), the local method stack (Native method Stacks), but the memory layout and address space for each block area are not explicitly defined, leaving the JVM vendors the space to play.

HotSpot JVM

The sun's own hotspot JVM implements a relatively clear description of the heap memory structure. According to the implementation of the Hotspot JVM, heap memory is divided into 3 generations: young Generation, Old (tenured) Generation, Permanent Generation. It is well known that GC (garbage collection) is the three generation of heap memory. Young is used to allocate new Java objects, which are then divided into three parts: Eden space and two survivor space (called From and to), which are used to store objects that survived the GC process, The permanent is used to store metadata such as class classes loaded by the JVM. See the Hotspot Memory Management whitepaper for details. The layout diagram of the heap is as follows:

Based on this information, we can derive the corresponding relationship between the memory partition of the JVM specification and the memory area in the hotspot implementation: The heap of the JVM specification corresponds to the young and old Generation, and the method area and constant pool correspond to permanent Generation. The hotspot implementation is not detailed for stack memory, but the hotspot white paper mentions that the Java line stacks is represented by the stack and threading model of the host operating system, and the Java method and the native method share the same stack. Therefore, it can be considered that the JVM stack and the local method stack are one thing in a hotspot.

Operating system

Because a JVM process is first an operating system process, it follows the rules of the operating system process address space. The 32-bit system has an address space of 4G, which represents up to 4GB of virtual memory. In a Linux system, a high-address 1G space (that is, 0XC0000000~0XFFFFFFFF) is occupied by the system kernel, with a low address of 3G space (i.e. 0x00000000~ 0xBFFFFFFF) is used by the user program (apparently the JVM process is running in this 3G address space). This 3G address space from low to high and divided into multiple segments; theText segment is used to store the program binary code; theData segment is used to hold static variables initialized at compile time, andBSS segments are used to hold uninitialized static variables ; heap, the data structure used for dynamic memory allocation, the memory requested by the malloc function in C is allocated from here, and the object from Java's new instantiation is also from this assignment. Unlike the previous three segments, the heap space is variable, and its upper bound is increased by a low address to a high address. Memory Map Area , the loaded dynamic link library is located in this area , stack is the stack space, the execution of the thread is to occupy the stack memory, the stack space is also variable, but it is through the nether from high address to low address to the growth of the move. See here for details. This is illustrated below:

The JVM itself is written by native code, so the JVM process also has memory segments such as Text/data/bss/heap/memorymapping/stack. The Java language heap should be built on the heap of the operating system process, and the Java language stack should also be built on the OS process stack. Combining the memory area of the hotspot with the address space of the operating system process, you can get an overview of the following illustrations:

The memory of a Java thread is in the stack (stack) space of the JVM or operating system, unlike the object--that is, in the heap (heap). This is where many novice programmers are apt to misunderstand. Note that the term "memory for Java threads" does not refer to the memory of the Java.lang.Thread object, theJava.lang.Thread object itself is allocated in the heap, and when the start () method is called, the JVM creates an execution unit. The native thread of the operating system is eventually created, and the execution unit or native thread is using stack memory space .

Through the above foreshadowing, it can be learned that the memory of the JVM process is roughly divided into heap space and stack space two parts. Heap is divided into young, old, permanent three generations. Stack is divided into Java method stack and native method stack (do not differentiate), in the stack memory area, you can create multiple lines stacks, each line stacks occupy a small portion of the stack area of memory, the line stacks is a LIFO data structure, each call a method, will create a frame at the top of the stack, When the method returns, the corresponding frame is removed from the top of the stack (by moving the top pointer of the stack). Overflow errors can occur in each part of the memory. Back to the beginning of the OutOfMemoryError, the following describes the cause of the error and the resolution (each outofmemoryerror may be a program bug, so the workaround does not include troubleshooting the bug).

Java.lang.OutOfMemoryError:Java Heap Space
Cause: heap memory overflow means that there is not enough memory for young and old generation.
Workaround: Adjust the java boot parameter-xms-xmx to increase heap memory.

Java.lang.OutOfMemoryError:unable to create new native thread
Cause: Stack space is not enough to create additional threads, either too many threads are created, or the stack space is indeed small.
Workaround: Because the JVM does not provide parameters to set the total stack space size, but can set the size of a single line stacks, and the system's user space is a total of 3G, in addition to text/data/bss/memorymapping several paragraphs, heap and stack space is limited, It is the one that has been eliminated. Therefore, there are two ways to solve this error: 1. Reduce the size of a single thread stack by-XSS startup parameters, so that more threads can be opened (not too small, too small to appear stackoverflowerror), 2. Reduce the heap size by-xms-xmx two parameters, Give the memory to the stack (provided that the heap space is sufficient).

Java.lang.OutOfMemoryError:PermGen Space
Cause: Permanent generation space is insufficient to load additional classes.
Workaround: Adjust-xx:permsize=-xx:maxpermsize= two parameters to increase PermGen memory. In general, these two parameters do not set manually, as long as the settings-xmx large enough, the JVM will choose the appropriate PermGen size.

java.lang.OutOfMemoryError:Requested array size exceeds VM limit
Cause: This error is relatively rare (try new one with a length of 100 million), also due to insufficient heap space. If a new array of this size is needed, the logic of the program is mostly unreasonable.
FIX: Modify the program logic. Or, you can increase heap memory by-XMX.

when the GC spends a lot of time, but only a small amount of memory is recycled, OutOfMemoryError is also reported, and I've only met one or two times. When using the-XX:+USEPARALLELGC or-XX:+USECONCMARKSWEEPGC collector, an error is given in the above case, as described in the hotspot GC turning documentation:
The parallel (concurrent) collector would throw an outofmemoryerror if too much time be being spent in garbage collection:i F more than 98% of the total time was spent in garbage collection and less than 2% of the heap are recovered, an OutOfMemory Error would be thrown.
For this problem, one needs to do GC turning, and the other is to optimize the program logic.

Java.lang.StackOverflowError
Cause: This is also a memory overflow error, that is, the overflow of the line stacks, either the method call hierarchy too many (such as there is an infinite recursive call), or the line stacks is too small.
Solution: Optimize program design, reduce method call level, adjust-XSS parameter to increase thread stack size.

This article turns from

http://blog.csdn.net/xiaoyufu007/article/details/6429657

Java common error handling methods and JVM memory structure