Table of contents
Many people divide JAVA memory into heap memory (Heap) and stack memory (Stack) . This division method reflects to a certain extent that these two areas are the memory areas that Java engineers are most concerned about. However, this division method is not completely correct . Java's memory area division is actually far more complicated than this. When the Java virtual machine executes a Java program, it will divide the memory it manages into different data areas . As shown below
After a HelloWorld.java program is compiled into a HelloWorld.class file, it is loaded into the memory of the JVM by the class loader ClassLoader. The memory in the JVM can be divided into several different data areas: program counter , virtual machine stack , local method stack , heap and method area .
1. Program counter
Java programs are multi-threaded, and the CPU can distribute the actual fragments of execution among multiple threads.
Function : When a thread is suspended by the CPU , it is necessary to record the position where the current code has been executed, so that when the CPU re-executes the thread, it will know which line of instructions to start executing.
The program counter is a small memory space in the virtual machine, mainly used to record the execution position of the current thread.
A few notes on the program counter :
1. The Java Virtual Machine Specification does not specify any OutOfMemoryError situation for the program counter area.
2. The program counter is a thread-private data area. Each thread has a private program counter inside. Its life cycle is created with the creation of the thread and dies with the end of the thread.
3. When a thread is executing a Java method, this counter records the address of the virtual machine bytecode instruction being executed. If a Native method is being executed, the counter value is empty.
2. Virtual machine stack
The virtual machine stack is also thread-private and synchronized with the thread's life cycle. In the Java virtual machine specification, two exceptions are specified for this area: 1) StackOverflowError: thrown when the thread request stack depth exceeds the depth allowed by the virtual machine stack; 2) OutOfMemoryError: when the Java virtual machine dynamically expands to the point where it cannot Thrown when enough memory is requested.
The JVM is executed by a stack-based interpreter , and the "stack" here refers to the virtual machine stack. DVM is implemented based on a register interpreter . The original intention of the virtual machine stack was to describe the memory model of Java method execution. When each method is executed, the JVM will create a stack frame in the virtual machine .
stack frame
Stack frame is a data structure used to support method calling and method execution by the virtual machine. When each thread executes a method, it will create a stack frame for this method. A thread contains multiple stack frames (multiple methods), and the contents of each stack frame include: local variable table, operand stack, dynamic connection and return address.
Local variable table: It is the storage space for variable values. The parameters passed when calling the method and the local variables created in the method memory are stored in the local variable table. When Java is compiled into a class file, the maximum capacity of the local variable table that the method needs to allocate will be determined in the max_locals data item in the Code attribute table of the method.
The program is compiled into a class file and decompiled into bytecode instructions using javap -v.
The "locals = 3" inside means that the length of the local variable table is 3, and the parameters k, local variables i and j are stored respectively.
Operand stack: Often called the operation stack, it is a LIFO stack. The maximum depth of the operand stack is also written into the max_stacks data item in the Code attribute table of the method during compilation. The elements in the stack can be any Java data type, including long and double. When a method just starts executing, the operand stack of this method is empty. During the execution of the method, various bytecode instructions will be pushed into and popped out of the operand stack.
Dynamic linking: The main purpose is to support dynamic linking (Dynamic Linking) during method calling. In a class file, if a method wants to call other methods, it needs to convert the symbolic references of these methods into direct references in the memory address where they are located, and the symbolic references are stored in the method area. In the Java virtual machine stack, each stack frame contains a symbolic reference pointing to the method to which the stack belongs in the runtime constant pool (each stack frame contains a symbolic reference --> the method to which the stack belongs).
Return address: When a method starts executing, there are only two ways to exit the method: 1) Normal exit: refers to the code in the method completing normally, or encountering a bytecode instruction (such as return) returned by any method and exiting No exception is thrown; 2) It means that an exception is encountered during the execution of the method, and this exception is not handled within the method body, causing the method to exit.
The return address in the virtual machine stack is used to help the current method restore its upper method execution status. When exiting normally, the caller's PC count value can be used as the put-back address, and this count value may be saved in the stack frame; when exiting abnormally, the put-back address is determined through the exception handler table, and this information is generally not saved in the stack frame . .
3. Local method stack
The local method stack is at the same level as the virtual machine stack and is for native methods. If JNI is involved in development, you may have more contact with the local method stack. In some virtual machine implementations, the two have been combined into one (such as HotSpot).
4. Java Heap
It is the largest piece of memory managed by the JVM. The only purpose of this area is to store object instances .
It is the main area managed by the Java garbage collector (GC), sometimes also called the "GC heap".
Is a memory area shared by all threads. If the objects allocated in this area are accessed by multiple threads, thread safety issues need to be considered.
According to the storage time of objects, the memory in the heap can be divided into the new generation and the old generation . The new generation is divided into Eden and Survivor areas. Different areas store objects with different life cycles, so that different garbage collection algorithms can be used according to different areas.
5. Method area
The method area is a runtime data area specified in the JVM specification. Main storage: class information (version, fields, methods, interfaces) that has been loaded by the JVM; constants; static variables; code compiled by the just-in-time compiler; data. This area is a memory area shared by various threads.
Method area and permanent area:
The method area is something at the specification level , which stipulates what data should be stored in this area; the permanent area or metaspace is a different implementation of the method area, and is something at the implementation level .
