[Mass production] JVM memory area division
Java Visual Machine memory area division
“ Fragmented time, elaborate local knowledge. ”
Reasons for learning:
Although, compared to C and C++ languages, JAVA does not require programmers to manually allocate memory and release memory for generated (new) objects. This work can be handed over to the JVM to handle, so as to avoid programmers forgetting The dying object releases the memory and causes the risk of memory leak and memory overflow. However, limited by hardware and software configuration and code logic, JAVA will automatically manage memory allocation and release by JVM, and memory leaks and overflows may also occur. Therefore, we must understand how the JVM manages and releases memory in order to deal with memory leaks and overflows.
This time only discuss some of the knowledge in the automatic allocation of JVM memory: the division of JVM memory area, the release of memory (that is, garbage collection), and the details of memory allocation will be described later.
Knowledge reserve:
Each process in the operating system has a memory area managed by itself. Similarly, JVM also belongs to a process, and JVM also has a memory area (set as memory area D) that belongs to its own management. All java programs running on the JVM process use this memory area D. We can call D the runtime data area D.
Start of feature film:
The JVM divides the runtime data area D into several partitions as shown below:
Program counter：
Similar to the program counter of the operating system process, but the program counter here refers to the program counter of the thread in the java program running on the JVM, which is used to place the line number of the thread currently executing the bytecode instruction, and each thread has an exclusive The program counter. The thread counter part is the only area where OutOfMemoryError will not exist.
Java virtual machine stack：
Thread isolation, each time a method is called during the execution of a Java thread, a stack frame (Stack Frame) is created in the Java virtual machine stack. The stack frame stores local variable tables, operand stacks, dynamic connections, and method exits. And other information. After a method is called, the stack frame of the method is popped. Therefore, the constant call of the method means the constant push to the stack. The existence of the Java virtual machine stack helps the thread that owns it to remember which processes the calling method has gone through, thereby ensuring the correctness of the logic.
It is worth noting that each virtual machine has a stack depth limit for the virtual machine stack, and the method calls in the thread exceed this depth will throw a StackOverFlowError exception; if the Java virtual machine capacity allows expansion, when the stack depth does not exceed the limit However, when the stack capacity has exceeded the limit and the capacity needs to be expanded, an OutOfMemory exception will be thrown if sufficient memory is not available.
Native method stack：
The function of the native method stack and the java virtual machine stack is similar. The difference is that the native method service is the native method call, and the java virtual machine stack service is the java method call; the native method is often referred to as the local method, and other methods are used. Language implementation method.
Java heap：
Shared among threads, java heap is the largest piece of virtual machine management memory. The sole purpose of this memory area is to store object instances. "Almost all" object instances in Java allocate memory here. The Java heap is an area of memory managed by the garbage collector. You can set the area size and whether to allow expansion, and there is an OutOfMemory exception.
Method area：
Shared between threads, used to store data such as type information (still class information) that has been loaded by the virtual machine, constants, static variables, and code cache compiled by the just-in-time compiler. This part is often called "non-heap" to distinguish heap memory. This area also needs garbage collection (mainly for constant pool collection and type unloading), but the frequency of recycling is much smaller. And there are also OutOfMemory exceptions.
The concept of direct memory
Direct memory is not part of the data area when the virtual machine is running. However, this part is also frequently used, and may also cause OutOfMemory abnormalities. This part of the memory also occupies a part of the JVM's memory area. Don't miss this part when setting virtual machine parameters.
references:
"In-depth understanding of the Java Virtual Machine: JVM advanced features and best practices (Third Edition)"
Run chapter II, section 2.2 data area
of: Zhou Zhiming
ISBN: 9787111641247
tail:
The above knowledge points are integrated into your own understanding. If you have any questions or deficiencies, please feel free to discuss in the comment section or private message.