This article introduces the java memory area from the following content
1. Runtime data area
1. Runtime data area
1. Threads and JVM threads
1.1, thread
The thread mentioned here refers to a thread entity in the process of program execution.
The JVM allows an application to execute multiple threads concurrently. Java threads in the Hotspot JVM have a direct mapping relationship with native operating system threads . An OS native thread is created when thread local storage, buffer allocation, synchronization objects, stacks, program counters, etc. are ready. The Java thread ends, and the native thread is recycled. The operating system is responsible for scheduling all threads and assigning them to any available CPU. When the native thread is initialized, the run() method of the Java thread is called. When run() returns, the uncaught exception is handled, and the native thread will confirm whether the JVM process is to be terminated due to its termination (eg this thread is the last non-daemon thread). When the thread ends, all resources of the native thread and the Java thread are released.
1.2, JVM thread
The background thread runs along with the main thread that triggers the public static void main(String[]) function and other threads created by the main thread. The system threads running in the background of the Hotspot JVM mainly include the following:
| VM thread | This thread waits for the JVM to reach a safepoint operation to occur. These operations must be performed in separate threads, because threads require the JVM to be at a safe point when heap modifications cannot be performed. The types of these operations are: stop-the-world garbage collection, thread stack dump, thread suspension, thread biased locking release. |
| Periodic task thread | This thread is responsible for timer events (aka interrupts), which are used to schedule the execution of periodic operations. |
| GC thread | These threads support different garbage collection activities in the JVM. |
| compiler thread | These threads dynamically compile bytecode into native platform-dependent machine code at runtime. |
| signal dispatch thread | This thread receives signals sent to the JVM and calls the appropriate JVM method for processing. |
2. Data area at runtime
Data area at runtime:
(1) Memory area shared by threads:
Heap (GC heap) Heap
Method Area (Non Heap) Method Area
(2) Thread-private memory area:
Program Counter Register
VM stack
Native Method stack
1. Program counter
Program counter: a small memory area, its role can be seen as a line number indicator of the bytecode executed by the current thread. In the conceptual model of the virtual machine, the job of the bytecode interpreter is to select the next bytecode instruction to be executed by changing the value of this counter. This counter is required for branching, looping, jumping, exception handling, and thread recovery functions. To be done.
The multi-threading of the JVM is implemented by switching threads in turn and allocating processor execution time. At any certain time, a single processor will only execute one thread instruction.
After the thread is switched, it can return to the correct execution position, so each thread needs an independent program counter, and each thread does not interfere with each other. Therefore, the program counter is a thread-private memory area.
If the thread executes a java method, this counter records the bytecode instruction address of the VM being executed; if the execution is a Native method, the value of this counter is Undefined, and this area is the only one in the Java VM specification. There is no region specified for any OutOfMemoryError.
2. Java VM stack
The virtual machine stack is private to the thread, and its declaration cycle is the same as that of the thread.
The virtual machine stack describes the memory model of java method execution, and a stack frame is created at the same time when each method is executed.
Stack frame: used to store the local variable table, operation stack, dynamic link, method exit information, and reference to the runtime constant pool of the current method of the class.
In the Java VM specification, there are two exceptions in this area:
(1) StackOverflowError: If the depth of the stack requested by the thread is greater than the depth allowed by the virtual machine, this exception will be thrown;
(2) OutOfMemoryError: The virtual machine stack can be dynamically expanded, and this exception will be thrown when the expansion cannot apply for enough memory;
3. Local method stack
Similar to the function of the java vm stack;
The virtual machine stack executes java methods (bytecode services) for the virtual machine, while the native method stack serves the native methods used by the virtual machine;
The native method stack also throws StackOverflowError and OutOfMemoryError exceptions.
4. Java heap
The largest area in VM memory management;
The Java heap is shared by all threads and is created when the virtual machine starts;
The only purpose of this area is to store object instances, and almost all object instances are allocated in this area;
The Java heap is the main area managed by the garbage collector, so this area is also not the GC heap.
5. Method area
Like the Java heap, it is a memory area shared by each thread, which is used to store data such as class information, constants, static variables, and code compiled by the just-in-time compiler that have been loaded by the virtual machine. The alias of this area is called Non Heap (non-heap), and the purpose is to distinguish it from the java heap.
5.1. Runtime constant pool
part of the method area;
In addition to the class version, field, method, interface and other information descriptions in the Class file, there is also a constant pool of information;
The constant pool in the Class file is used to store various literals and symbolic references generated by the compiler. This part of the content is stored in the runtime constant pool of the method area after the class is loaded.
Another important feature of the runtime constant pool compared to the constant pool of the Class file is that it is dynamic;
The java language does not require that constants must only be generated at compile time, that is to say, the constant pool in the class file does not enter the runtime constant pool of the method area when the class file is loaded, and the constants can also be put into the pool at runtime. Among them, this feature is mostly used in the intern method of the String class;
The runtime constant pool is part of the method area, and is naturally limited by the memory of the method area. When the constant pool cannot apply for memory, an OutOfMemoryError will be thrown.
This article is referenced from: http://www.importnew.com/17770.html
"In-depth understanding of Java virtual machine" Zhou Zhiming