Original address: https://www.cnblogs.com/paddix/p/5309550.html
One, JVM memory model
According to the JVM specification, JVM memory is divided into five parts: virtual machine stack, heap, method area, program counter, local method stack.
1, virtual machine stack: Each thread has a private stack, created with the creation of the thread. There is a stack of what is called "stack frame", each method will create a stack frame, the stack frame contains a local variable table (basic data type and object reference), operand stack, method of export information. The size of the stack can be fixed or dynamically expanded. When the stack call depth is greater than the scope allowed by the JVM, it throws a stackoverflowerror error, but the depth range is not a constant value, and we can test this result by using the following procedure:
Stack Overflow test Source:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19-20 |
package com.paddx.test.memory; Public class stackerrormock { private static int index = 1; public void call () { index++; call ();    &NBSP} public static void main (String[] args) { stackerrormock mock = new stackerrormock (); try { mock.call (); }catch (Throwable e) { system.out.println ("Stack deep:" +index); e.printstacktrace (); }  }} |
Code Snippet 1
Run three times, you can see the depth of each stack is not the same, the output is as follows.
As for the value in the red box is how to come out, you need to go deep into the JVM's source code to explore, not to elaborate.
Virtual machine Stack In addition to the above error, there is another error, that is, when the application is not available, will throw outofmemoryerror. Here's a little detail to note that catch captures Throwable rather than Exception. Because Stackoverflowerror and Outofmemoryerro