JVM exploration-Memory Management (1)

 

The first article in this series is expected to have two or three cases at the end of this series.

Java is different from C and C ++. Java does not need coder for manual memory management, and all of this is handed over to JVM for automatic memory management, to some extent, this reduces the coder encoding workload. Is it necessary for us to understand the JVM memory management mechanism? The answer is no; because Java will also cause memory leakage and memory overflow like C and C ++, although there will be fewer such accidents, but once it happens and you don't know about its memory management mechanism, it will be very tricky. Another reason is that Java runs on the JVM, without JVM parameters, the execution performance of the program may be affected. To achieve the optimal performance of the JVM in a specific application, we must understand the internal mechanism of JVM; not to mention the introduction of JVM Exploration Series-memory management

According to the Java Virtual Machine specification, when a Java virtual machine executes a Java program, the memory it manages is divided into several areas, that is, the run-time data zone (run-time data areas ); these regions have different functions and lifecycles. They are mainly divided into two categories: one is created with the startup of the JVM process and destroyed with the demise of the JVM process; one is created with the creation of threads and destroyed with the destruction of threads. The memory areas stipulated in Java Virtual Machine specifications are as follows:

 

 

The two regions of the red border are shared by all threads (the JVM process is created when it is started, and the process is destroyed when it disappears)

The other three zones are isolated by threads (the threads are created and destroyed upon thread destruction)

 

Run-Time areas can be divided into: Method Area, heap, java stack, and Native method stacks) and PC register;

 

1. PC register)

The PC register (PC register) stores the address of the currently running commands (bytecode instructions). Each thread that is private to a thread has an independent register; if the Java method is being executed, the address of the bytecode instruction is stored. If the native method is executed, the value is null (undefined ).

2. Java Virtual Machine stacks ),

Java Virtual Machine Stack: the unique life cycle of a thread is the same as that of a thread. Java Virtual Machine stack is used to store stack frames. A stack frame is created during Java method execution) stores information such as the local variable table, operand stack, dynamic link, and method exit. The method starts to execute the stack frame into the Java Virtual Machine stack. After the method is executed, the stack is output. (Java VM specification stipulates that the Java VM stack will throw two types of exceptions: stackoverlowerror and outofmemoryerror. The first is that the stack thread request stack capacity exceeds the maximum capacity allowed by the Java VM, the second is not allocated enough memory ).

3. Heap)

In the Java virtual machine, the heap is shared by all thread locks. It is created when the Java Virtual Machine is started and used to store object instances and Array Memory allocation,

4. native method Stack)

It is used to execute the native method. Some virtual machines combine it with the Java Virtual Machine stack (such as hotspot) and throw two types of exceptions: stackoverlowerror and outofmemoryerror.

5. Method Zone)

The method area is the same as the Java heap. All threads are shared when the virtual machine is started; stores the class information loaded by the virtual machine, the runtime volume pool, fields, method data, and the bytecode content after the real-time compiler compilation. The stored content is basically from the class file; different virtual machines have different implementation methods. In the hotspot virtual machine, the method area can be called the permanent generation, and the GC collection Assembly recycles the method area. When the method area cannot meet the memory allocation, the Java Virtual Machine will throw an outofmemoryerror.

5.1 runtime constant pool)

The runtime constant pool, a part of the method area, and the runtime expression of the class or interface constant pool, stores the literal volume and symbolic reference generated after compilation (reference of methods and fields ); A constant can be added during running, the intern () of the string class. This is the case with the method. An outofmemoryerror error is thrown when the memory cannot be applied.

 

After introducing the regions of JVM memory, let's look at the following code:

Public class model {

Private Static int I = 1;

Public Model (){

}

}

After model = new model () is instantiated, I will store it in the runtime constant pool of method aeras, the reference of the instantiated model will be stored in the local variable table of the Java VM stack, and the instance (instance data) corresponding to the new model () will be stored in the Java heap) the constructor model () will also be stored in the method area.

 

The personal blog updates the website at the same time: http: // www. solinx. co

JVM exploration-Memory Management (1)