Java Virtual machine 4: Memory overflow

Http://www.cnblogs.com/xrq730/p/4833713.html

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

 Packagecom.xrq.test;Importjava.util.ArrayList;Importjava.util.List;/*** Test content: Heap Overflow * * Virtual machine parameters:-xms20m-xmx20m-xx:+heapdumponoutofmemoryerror*/ Public classheapoverflowtest{ Public Static voidMain (string[] args) {List<HeapOverflowTest> list =NewArraylist();  while(true) {List.add (Newheapoverflowtest ()); }    }}

Run results

Java.lang.OutOfMemoryError:Java heap spacedumping heap to java_pid8876.hprof ... Heap dump file created [15782068 bytes in 0.217"main" Java.lang.OutOfMemoryError:Java heap Space    A T 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 resize the heap or check the code to see if there are some objects that have long life cycles, long holding states, and less memory consumption during the program run for long periods of time.

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

 Packagecom.xrq.test;/*** Test content: Stack Overflow test (recursive call causes stack depth to increase) * * Virtual machine parameters:-xss128k*/ Public classstackoverflowtest{Private intStacklength = 1;  Public voidStackleak () {stacklength++;    Stackleak (); }         Public Static voidMain (string[] args)throwsthrowable {stackoverflowtest StackOverflow=Newstackoverflowtest (); Try{stackoverflow.stackleak (); }        Catch(Throwable e) {System.out.println ("Stack Length:" +stackoverflow.stacklength); Throwe; }            }}

Run results

Stack length:1006"main" Java.lang.StackOverflowError at    com.xrq.test.StackOverflowTest.stackLeak (Stackoverflowtest.java:) at    com.xrq.test.StackOverflowTest.stackLeak (Stackoverflowtest.java: at    com.xrq.test.StackOverflowTest.stackLeak (Stackoverflowtest.java:+) at    Com.xrq.test.StackOverflowTest.stackLeak (Stackoverflowtest.java:) at    Com.xrq.test.StackOverflowTest.stackLeak (Stackoverflowtest.java:) at    Com.xrq.test.StackOverflowTest.stackLeak (Stackoverflowtest.java:...)

The back is all the same, ignoring. OutOfMemoryError can be generated by constantly creating threads, because each thread has its own stack space. However, this is a dangerous operation, because the Windows platform, Java thread is directly mapped to the operating system kernel thread, if write a dead loop infinite thread generation, it may cause the operating system of suspended animation.

The above infinite thread-generating scenario, from another point of view, is that the larger the allocated memory space for each thread's stack, the more likely it is to generate a memory overflow. 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.

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. However, if the outofmemoryerror caused by multithreading has been established, it can only be exchanged for more threads by reducing the maximum heap capacity and reducing the stack capacity without reducing the number of threads or replacing the 64-bit virtual machine.

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

 Packagecom.xrq.test;Importjava.util.ArrayList;Importjava.util.List;/*** Test content: Constant pool Overflow (This example also shows that the run-time constant pool is part of the method area) * Virtual machine parameter-xx:permsize=10m-xx:maxpermsize=10m*/ Public classconstantpooloverflowtest{ Public Static voidMain (string[] args) {List<String> list =NewArraylist<string>(); inti = 0;  while(true) {List.add (string.valueof (i++). Intern ()); }    }}

Run results

Exception in thread ' Reference Handler ' Exception in thread ' main ' java.lang.OutOfMemoryError:PermGen space at    ja Va.lang.String.intern (Native Method) at    Com.xrq.test.ConstantPoolOverflowTest.main ( Constantpooloverflowtest.java: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 .

Java Virtual machine 4: Memory overflow