C-language friends know that the C compiler often divides the area of memory into data segments and code snippets, and data segments include heaps, stacks, and static data areas. So in the Java language, how is memory divided?
Since Java programs are executed by the JVM, we are talking about the partitioning of the Java memory area in fact the JVM memory area. Before discussing the JVM memory zoning, take a look at the process that the Java program executes:
As shown, first the Java source code file (. java suffix) is compiled by the Java compiler into a bytecode file (. class suffix), and then the class loader in the JVM loads the bytecode files for each class, and after loading, it is done by the JVM execution engine. Throughout the execution of the program, the JVM uses a space to store the data and related information that is needed during the execution of the program, which is generally referred to as the runtime data area (the run-time datacenter), which is what we often call JVM memory. So the memory management we often talk about in Java is about managing this space (how to allocate and reclaim memory space).
Now that we know what the JVM memory is, let's talk about how this space is going to divide the area.
I. What are the parts of the runtime data area?According to the Java Virtual Machine specification, the runtime data area typically includes these parts: program Counter Register, Java stack (VM stack), local method Stack (Native), method area (Method area), heap.
As shown, the runtime data area in the JVM should include these parts. Although it is stipulated in the JVM specification that the data area should include these parts when the program is run during execution, the different virtual machine vendors can have different implementations as to how the implementation is not specified.
Two. What data is stored in each part of the runtime data area?
Let's look at how each part of the runtime data area is used to store what data is in the process of executing the program.
1. Program counter
Program Counter Register, also known as PC Register. Must have learned assembly language friend to program counter this concept is not unfamiliar, in assembly language, the program counter refers to the register in the CPU, it is stored in the program is the current execution of the instruction address (also can be said to save the next instruction where the address of the storage unit), when the CPU needs to execute instructions, You need to get the address of the storage unit of the instruction that is currently required to execute from the program counter, and then obtain the instruction according to the obtained address, and after the instruction is obtained, the program counter automatically adds 1 or the address of the next instruction according to the transfer pointer, so it loops until all instructions are executed.
Although the program counters in the JVM are not the same as the CPU registers in the physical concept as the program counters in assembly language, the function of the program counter in the JVM is logically equivalent to the function of the program counter in assembly language, that is to say which instruction is executed.
Because in the JVM, multithreading is to get CPU execution time by rotating threads, so at any given moment, a CPU kernel only executes instructions in one thread, therefore, in order to be able to make each thread switch back to the program execution location before switching, Each thread needs to have its own independent program counter, and cannot be interfered with each other, otherwise it will affect the normal order of execution of the program. So, so to speak, the program counters are private to each thread.
In the JVM specification, if a thread executes a non-native method, the program counter holds the address of the instruction that is currently required to execute, and if the thread executes the native method, the value in the program counter is undefined.
Because the size of the space that is stored in the program counter does not change with the execution of the program, there is no memory overflow phenomenon (OutOfMemory) for program counters.
2.Java Stack
The Java stack, also known as the VM stack (Java vitual machine stack), is what we often call a stack, similar to a stack in a C-language data segment. In fact, theJava stack is the memory model that the Java method executes. Why do you say that? Let's explain why.
In the Java stack is a stack of frames, each stack frame corresponding to a called method, in the stack frame including the local variable table (local Variables), the operand stack (Operand stack), A reference to the run-time pool of the class to which the current method belongs (the concept of running a constant pool is discussed in the method area section), the Reference to runtime constant pool, the return address of the method, and some additional additional information. When a thread executes a method, it creates a corresponding stack frame and pushes the stack frame to be built. When the method finishes executing, the stack frame is stacked. Therefore, the stack frame corresponding to the method that the thread is currently executing must be at the top of the Java stack. In this case, you should understand why the use of recursive methods can easily lead to stack memory overflow phenomenon and why the space of the stack does not have to be managed by the programmer (in Java, of course, the programmer is basically not related to memory allocation and release of things, because Java has its own garbage collection mechanism), This part of the space allocation and release are automatically implemented by the system. For all programming languages, this part of the stack is opaque to programmers. Represents a model of a Java stack:
Local variable table, as the name implies, must not explain that we should understand its role. is used to store local variables in the method (including non-static variables declared in the method and function parameters). For a variable of the base data type, the value is stored directly, and for a variable of the reference type, a reference to the object is saved. The size of the local variable table can be determined by the compiler, so the size of the local variable table will not change during program execution .
Operand stack, must have learned the data structure of the stack of friends presumably to the expression evaluation problem is not unfamiliar, the most typical application of the stack is used to evaluate the expression. When you think about a thread executing a method, it is actually the process of executing the statement, and in the final analysis it is the process of calculating. So you can say that all the computational processes in the program are done with the help of the operand stack.
A reference to a run-time pool, because a constant in the class is likely to be used during the execution of the method, so a reference must be directed to the run-time.
method returns an address that must be saved in the stack frame when a method is executed to return to the place where it was previously called.
Because the methods that each thread is executing may be different, each thread will have its own Java stack that does not interfere with each other.
3. Local Method Stack
The local method stack works very much like the Java stack. The difference is simply that the Java stack is for the Java Method service, while the local method stack serves the local method (Native). in the JVM specification, the specific implementation method and data structure of local development are not enforced, and the virtual machine is free to implement it. The local method stack and the Java stack are directly merged into the hotsopt virtual machine.
4. Heap
In the C language, this part of the heap is the only area of memory that a programmer can manage. Programmers can use the malloc function and the free function to apply and release space on the heap. So what's it like in Java?
The heap in Java is used to store the object itself as well as an array (of course, the array references are stored in the Java stack). But unlike in the C language, in Java, programmers do not have to care about the issue of space release, Java garbage collection mechanism will be automatically processed. So this part of the space is also the main area of Java garbage collector management. In addition, the heap is shared by all threads, and there is only one heap in the JVM.
5. Method area
The method area is also a very important area in the JVM, which, like the heap, is a thread-shared area. in the method area, information is stored for each class (including the name of the class, method information, field information), static variables, constants, and compiler-compiled code.
In the class file, in addition to the description of the fields, methods, interfaces, and so on, there is a constant pool that stores the literal and symbolic references generated during compilation.
A very important part of the method area is the run-time pool, which is the runtime representation of the constant pool of each class or interface, which is created when classes and interfaces are loaded into the JVM. Of course, not the contents of the class file constant pool can enter the run-time pool, and the new constants can be placed in the run constant pool during runtime, such as The Intern method of string.
in the JVM specification, there is no mandatory requirement for the method area to implement garbage collection. Many people are accustomed to calling the method area "permanent generation" because the hotspot virtual machine implements the method area as a permanent generation, so that the JVM's garbage collector can manage this part of the area as if it were managed by the heap, eliminating the need to specifically design a garbage collection mechanism for this part. Since JDK7, however, the hotspot virtual machine has removed the run-time constant pool from the permanent generation.
The above is a personal opinion and opinion, if there is an incorrect wish to understand and welcome correction.
Memory Area division of the JVM