Java Virtual machine 3: Memory overflow

1. Preface

In the previous article we introduced the Java memory area structure, this one, simulates the memory overflow several scenes, the following diagram is the overall guideline:

2.Java Heap Overflow

The only purpose of the Java heap is to store object instances , so long as the objects are created and objects are not recycled, the number of objects reaches the maximum heap capacity limit, resulting in a memory overflow exception. So the size of the heap is fixed and the heap cannot be expanded when the test is made. The test code is as follows:

1 package com.xrq.test; 2  3 import java.util.ArrayList; 4 import java.util.List; 5  6/** 7  * Test content: Heap Overflow 8  * 9  * Virtual machine parameters:-xms20m-x Mx20m-xx:+heapdumponoutofmemoryerror10  */11 public class HeapOverflowTest12 {$ public     static void main ( String[] args)     {         list
Run results
Java.lang.OutOfMemoryError:Java heap spacedumping heap to java_pid8876.hprof ... Heap dump file created [15782068 bytes in 0.217 secs]exception in thread "main" Java.lang.OutOfMemoryError:Java Heap Spac E at    java.util.Arrays.copyOf (arrays.java:2760) at    java.util.Arrays.copyOf (arrays.java:2734)    at Java.util.ArrayList.ensureCapacity (arraylist.java:167) at    Java.util.ArrayList.add (arraylist.java:351) At    Com.xrq.test.HeapOverflowTest.main (heapoverflowtest.java:18)
This anomaly is very common, but also very good to find, because all prompted the "Java heap space", positioning problems, according to the exception stack analysis is good, the line number is indicated.
 Solution : You can adjust the size of the heap or check the code to see if there are some objects that have long life cycles, long hold states, and long periods of time to reduce memory consumption during program runs.
In addition, due to memory leaksin the Java heap, there is a brief explanation of the difference between memory leaks and memory overflows : Leak
memory leak: refers to the allocated memory is not recycled back, due to the loss of control of the memory area, resulting in a waste of resources. There is no memory leak in Java, because garbage collector automatically reclaims garbage, but this is not absolutely, when we new object, and save its reference, but the back has been useless, and the garbage collector does not recycle it, this will cause memory leaks,
memory Overflow: means that the memory required by the program exceeds the upper limit of memory (including dynamic expansion) that the system can allocate.
3. Method area and run-time-constant pool overflow
The run-time constant pool is also part of the method area, so these two areas can be seen together. The outofmemoryerror of this area can be produced using the String.intern () method. This is a native method, which means that if a string object in the constant pool has a strings of string objects, it returns the strings in the pool, otherwise, the string contained in this string object is added to the constant pool, and a reference to this string object is returned. The test code is as follows:
1 package com.xrq.test; 2  3 import java.util.ArrayList; 4 import java.util.List; 5  6/** 7  * Test content: Constant pool Overflow (This example also shows that the run-time constant pool is part of the method area) 8< c3/>*  9  * Virtual machine parameters-XX:PERMSIZE=10M-XX:MAXPERMSIZE=10M10  */11 public class ConstantPoolOverflowTest12 {13 Public     static void Main (string[] args)         { list<string> list = new arraylist<string> ();         int i = 0;17 while         (true)             List.add (String.valueof (i++). Intern ());         }21     }22}
Run results
Exception in thread ' Reference Handler ' Exception in thread ' main ' java.lang.OutOfMemoryError:PermGen space at    JAVA.L Ang. String.intern (Native Method) at    Com.xrq.test.ConstantPoolOverflowTest.main (constantpooloverflowtest.java:19) Java.lang.OutOfMemoryError:PermGen space at    Java.lang.ref.reference$referencehandler.run (reference.java:123)
Previously, for the hotspot, the method zone = Permanent generation, where the OutOfMemoryError area is "PermGen space", that is, the permanent generation, which is actually the method area overflow. Note that there is no such exception under the JDK1.7, while the loop will go on, because after JDK1.7 overflow the permanent generation and uses the native memory to realize the planning of the method area .
4. Stack Overflow
The Java Virtual machine specification describes a stack overflow if a thread requests too deep a stack depth (in other words, the depth of the method call is too deep). So, as long as we write a method that calls us infinitely, there will naturally be a scene in which the method call is too deep. The test code is as follows
1 package com.xrq.test; 2  3/** 4  * Test content: Stack Overflow test (recursive call results in increasing stack depth) 5  *  6  * Virtual machine parameters:-xss128k 7 */  8 public class Stackoverflowtest 9 {Ten     private int stacklength = 1;11     public     void Stackleak ()         stacklength++;15         stackleak ();     }17 public     static void Main (string[] args) throws Throwable19     {         Stackoverflowtest StackOverflow = new Stackoverflowtest ();         try22         {             Stackoverflow.stackleak ();         }25         catch (Throwable e)-         {             System.out.println ("Stack length:" + stackoverflow.stacklength);             throw e;29         }     }31}
Operation Result:
Stack length:1006exception in thread ' main ' java.lang.StackOverflowError at    Com.xrq.test.StackOverflowTest.stackLeak (stackoverflowtest.java:14) at    Com.xrq.test.StackOverflowTest.stackLeak (stackoverflowtest.java:15) at    Com.xrq.test.StackOverflowTest.stackLeak (stackoverflowtest.java:15) at    Com.xrq.test.StackOverflowTest.stackLeak (stackoverflowtest.java:15) at    Com.xrq.test.StackOverflowTest.stackLeak (stackoverflowtest.java:15) at    Com.xrq.test.StackOverflowTest.stackLeak (stackoverflowtest.java:15)
...
Multithreading: Here you need to pay attention to the situation of multithreading, multi-threaded under the way of constantly creating threads, you can produce outofmemoryerror exceptions, because each thread has its own stack space, the larger the stack space, the more prone to the memory overflow exception. In fact, it is also very well understood that the operating system allocated to the process of memory is limited, such as 32-bit Windows limited to 2GB. The virtual machine provides parameters to control the Java heap and the method area of the two parts of the maximum memory, the remaining memory is 2gb-maximum heap capacity-the maximum method area capacity, the program counter is very small to ignore, the virtual machine process itself is not the cost, the rest of the memory is the stack. The larger the stack capacity each thread allocates, the less natural the number of threads can be established, and the easier it is to run out of memory when the thread is established, possibly causing the operating system to feign death. 
The OutOfMemoryErrorcaused by multithreading can only be exchanged for more threads by reducing the maximum heap and the stack capacity of each thread , without reducing the number of threads.
single thread :stackoverflowerror This exception, there is error stack can read, better positioning. And if using the virtual machine default parameters, the stack depth in most cases, to achieve 1000~2000 completely no problem, the normal method calls this depth should be completely enough.
Reprint Address: http://www.cnblogs.com/xrq730/p/4833713.html
http://blog.csdn.net/ns_code/article/details/17565503
Java Virtual machine 3: Memory overflow