Java Virtual machine oom virtual machine stack and local method stack Overflow (4)

In the Java virtual machine specification, there are two exceptions to this area of the virtual machine stack :

(1) If the thread requests a stack depth greater than the virtual machine allows, the STACKOVERFLOWERROR exception will be thrown;
(2) If the virtual machine stack can be dynamically extended (most of the current Java Virtual machine can be dynamically extended, but the Java Virtual Machine specification also allows a fixed-length virtual machine stack), when the extension cannot request enough memory when the OutOfMemoryError exception is thrown.
(3) As with the virtual machine stack, the local method stack area throws Stackoverflowerror and OutOfMemoryError exceptions.

Second, the first picture in the previous article also showed that for the virtual machine stack and the local method stack if the multi-threaded case is likely to appear oom, below is a single-threaded case. Demo:

/** * Set VM Args:-xss128k * @author xuliugen * */ Public  class javavmstacksof {    Private intStacklength =1;//Repeated calls     Public void Stackleak() {stacklength++;    Stackleak (); } Public Static void Main(string[] args)throwsthrowable {Javavmstacksof Oom =NewJavavmstacksof ();Try{Oom.stackleak (); }Catch(Throwable e) {System.out.println ("Stack length:"+ oom.stacklength);ThrowE }    }}

To set up the VM Args:-xss128k (the previous one said: The set stack is 128k), the results are as follows:

stack length:40550in"main" java.lang.StackOverflowError    com.lc.oom.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:8)    后续很多异常省略。。。

The results show that under a single thread , whether the stack frame is too large or the VM stack capacity is too small, when memory cannot be allocated, the virtual machine throws a Stackoverflowerror exception, not an oom.

Third, if the test is not limited to single-threaded, through the continuous establishment of the thread is a memory overflow exception can be generated. You can create multiple threads for testing, but because Java threads are mapped to the operating system's kernel threads in the Windows platform's virtual machines, multithreaded code execution is risky and can cause the operating system to feign death. So...

But the result must be, multi-threaded case, will appear oom!

The principle is as follows:

Why is it that an oom is generated in the case of multithreading, so that there is no connection between the memory overflow exception and whether the stack space is large enough, or exactly, in this case, the larger the memory allocated to each thread's stack, the more likely it is to produce a memory overflow exception.

The reason is not difficult to understand, the operating system assigned to each process memory is limited, such as 32-bit Windows limit to 2GB. The virtual machine provides parameters to control the maximum value of both the Java heap and the memory of the method area. The remaining memory is 2GB (operating system limit) minus XMX (maximum heap capacity), minus maxpermsize (maximum method area capacity), the program counter consumes little memory and can be ignored. If the memory consumed by the virtual machine process itself is not counted, the remaining memory is "partitioned" by the virtual machine stack and the local method 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.

More simple to understand is: there is an operating system of 2G, we allocated to two threads, each 800M, also left 400M, so that there is a thread is not enough, it will be in the 400 application, so if the more left, the likelihood of an oom is smaller, if each allocation 950M, This leaves 100M, so the likelihood of an oom is even greater. If you add threads, the system Cheng Fei the memory for each line, so there is less memory left, so the likelihood of an oom may be greater, but it is relative.

What we should do when we encounter Oom:

If a memory overflow caused by multithreading has been established, it can only be exchanged for more threads by reducing the maximum heap and reducing the stack capacity , without reducing the number of threads or replacing 64-bit virtual machines. Without this experience, this method of "reducing memory" to solve memory overflow is more difficult to think of. This kind of pay Paul method, still is oneself tacit.

Java Virtual machine oom virtual machine stack and local method stack Overflow (4)