Shulou(Shulou.com)06/02 Report--

How to understand the JVM memory model, I believe that many inexperienced people do not know what to do. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Memory area

The Java virtual machine divides the memory it manages into several different data regions during the execution of the Java program. The Java virtual machine specification divides the memory managed by JVM into the following runtime data areas: program counter, Java virtual machine stack, local method stack, Java stack, and method area. The data types stored in each data area are described in detail below.

Write the picture description here.

Program counter (Program Counter Register)

A small piece of memory space, which is the line number indicator of the subcode executed by the current thread. When the bytecode interpreter works, the bytecode interpreter selects the next bytecode instruction to be executed by changing the value of the counter. Branch, jump, loop and other basic functions rely on it. Each thread has a separate program counter, and the counters between threads do not affect each other, so this area is private to the thread.

When a thread is executing a Java method, the counter records the address of the virtual machine byte instruction being executed, and the value of the counter is empty when the thread is executing the Native method (calling the local operating system method). In addition, this memory region is the only one that does not have any OOM (memory overflow: OutOfMemoryError) cases in the Java virtual machine specification.

Java virtual machine stack (Java Virtual Machine Stacks)

This area is also thread private, and its life cycle is the same as that of threads. The virtual machine stack describes the memory model of Java method execution: when each method is executed, a frame stack is created, which is a data structure used to support method calls and method execution by the virtual machine. For the execution engine, in the active thread, only the stack frame at the top of the stack is valid, which is called the current stack, and the method associated with this stack frame is called the current method. All bytecodes run by the execution engine operate only on the current stack frame. Stack frames are used to store local variables, Operand stacks, dynamic links, method return addresses, and some additional information. When compiling program code, how much memory needs to be allocated in the stack frame is not affected by the program run-time variable data, but only depends on the specific virtual machine implementation. In the Java virtual machine specification, two exceptions are specified for this area:

If the stack depth requested by the thread is greater than the depth allowed by the virtual machine, a StackOverflowError exception is thrown. If the virtual machine cannot apply for sufficient memory space when dynamically expanding the stack, an OutOfMemory exception is thrown.

There is some overlap in these two cases: when stack space can no longer be allocated, whether the memory is too small or the stack space used is too large is essentially just two descriptions of the same thing. In essence, it is only two descriptions of the same thing. In single-threaded operations, no matter because the stack frame is too large or the virtual machine stack space is too small, when the stack space can not be allocated, the virtual machine will throw a StackOverflowError exception, but will not get an OutOfMemoryError exception. In a multithreaded environment, an OutOfMemory exception is thrown.

The function and data structure of each part of the information stored in the stack frame are described in detail below.

A local variable table is a set of variable value storage space for storing method parameters and local variables defined within the method. The types of data stored are various basic data types, object references (reference) and returnAddress types that can be known at compile time (it points to the address of a bytecode instruction). The memory space needed by the local variable table is allocated during compilation, that is, when the Java program is compiled into a Class file, the maximum capacity of the local variable table is determined. When entering a method, how much local variable space the method needs to allocate in the stack is completely determined, and the size of the local variable table will not be changed during the operation of the method. The function and data structure of each part of the information stored in the stack frame are described in detail below.

1. The capacity of the local variable scale takes the variable slot (Slot) as the minimum unit. The virtual machine specification does not specify the amount of memory a Slot should occupy (allowing it to vary depending on the processor, operating system, or virtual machine), and a Slot can hold a data type of less than 32 bits: boolean, byte, char, short, int, float, reference, and returnAddresss. Reference is the reference type of the object, and returnAddress serves the byte instruction, which executes the address of a bytecode instruction. For 64-bit data types (long and double), the virtual machine allocates two contiguous Slot spaces in a high-order way.

The virtual machine uses the local variable table by index positioning. The index value ranges from 0 to the maximum number of Slot in the local variable table. For variables of 32-bit data type, index n represents the nth Slot, and for 64-bit data, index n represents the n th and n + 1 Slot.

When the method is executed, the virtual machine uses the local variable table to complete the process of transferring the parameter value to the list of parameter variables. if it is an instance method (not static), the Slot of the 0th index in the local variable table is used to pass the reference of the object instance to which the method belongs by default, and the implied parameter can be accessed through the keyword "this" in the method. The rest of the parameters are arranged in the order of the parameter table, occupying the local variable Slot starting from 1. After the parameter table is assigned, the remaining Slot is allocated according to the order and scope of the variables defined within the method body.

The Slot in the local variable table is reusable, and the scope of the variable defined in the method body does not necessarily cover the whole method body. If the value of the current bytecode PC counter has exceeded the scope of a variable, then the corresponding Slot of this variable can be handed over to other variables. This design is not only designed to save space, in some cases the reuse of Slot will directly affect the garbage collection behavior of the system.

2. Operand stack

Operand stack is often called Operand stack, and the maximum depth of Operand stack is determined at compile time. The stack capacity of 32-bit data types is 1, and the stack capacity of data types is 2. When a method starts to execute, its operation stack is empty, and during the execution of the method, various bytecode instructions (such as addition operation, assignment metacomputation, etc.) will write and extract contents to the operation stack, that is, stack-in and out-stack operations.

The interpretation execution engine of the Java virtual machine is called "stack-based execution engine", in which the "stack" is the Operand stack. So we also say that the Java virtual machine is stack-based, unlike the Android virtual machine, the Android virtual machine is register-based.

The main advantage of stack-based instruction set is strong portability, and the main disadvantage is that the execution speed is relatively slow; and because the register is provided directly by hardware, the main advantage of register-based instruction set is fast execution speed. the main disadvantage is poor portability.

3. Dynamic connection

Each stack frame contains a reference to the method to which the stack frame belongs in the runtime constant pool (in the method area, described later). This reference is held to support dynamic connections during method calls. There are a large number of symbolic references in the constant pool of the Class file, and the method invocation instructions in the bytecode take the symbolic references pointing to the method in the constant pool as parameters. Some of these symbolic references are converted to direct references (such as final, static fields, and so on) during the class loading phase or the first time they are used, called static parsing, and the other part is converted to direct references during each run, which is called dynamic connection.

4. Method return address

When a method is executed, there are two ways to exit the method: the execution engine encounters a bytecode instruction returned by any method or encounters an exception, and the exception is not handled in the method body. No matter which exit method is used, after the method exits, the program needs to return to the location where the method was called before the program can continue execution. When the method returns, you may need to save some information in the stack frame to help restore the execution state of its upper-level method. Generally speaking, when the method exits normally, the value of the caller's PC counter can be used as the return address, which is likely to be saved in the stack frame, but when the method exits abnormally, the return address is determined by the exception handler, and this part of the information is generally not saved in the stack frame.

The process of exiting a method is actually equivalent to outbound the current stack frame, so the operations that may be performed when exiting are: restoring the local variable table and Operand stack of the upper method, if there is a return value, pressing it into the Operand stack of the caller stack frame, adjusting the value of the PC counter to point to an instruction after the method call instruction.

Local method stack (Native Method Stacks)

This area is very similar to the role of the virtual machine stack, except that the virtual machine stack performs Java method services for the virtual machine, while the local method stack serves the native operating system (Native) methods used.

Java heap (Java Heap)

Java Heap is the largest piece of memory managed by the Java virtual machine, and it is a memory area shared by all threads. Almost all object instances and arrays allocate memory in this class. Java Heap is the main area managed by the garbage collector, so it is often called the "GC heap".

According to the Java virtual machine, the Java heap can be in physically discontiguous memory space, as long as it is logically contiguous. If there is no memory to allocate in the heap and the heap cannot be expanded, an OutOfMemory will be thrown.

Method area (Method Area)

The method area is also a memory area shared by each thread, which is used to store class information, constants, static variables, code compiled by the real-time compiler and other data that have been loaded by the virtual machine. The method area is also known as "permanent generation". But only for Sun HotSpot, there is no concept of permanent generation in JRocket and IBMJ9 virtual machines. The Java virtual machine specification describes the method area as a logical part of the Java heap, and like Java Heap, it does not require contiguous memory and can choose to be fixed or scalable. In addition, the virtual machine specification allows the area to choose not to implement garbage collection. Relatively speaking, garbage collection behavior is relatively rare in this area. The main goal of memory recovery in this area is the collection of discarded constants and useless classes. Runtime pool is a part of the method area, Class file in addition to the class version, fields, methods, interfaces and other description information, there is also a constant pool (Class file constant pool), used to store the compiler generated by a variety of literals and symbol references, this part of the content will be loaded in the method area after the storage of the runtime pool. Running constant pool relative to the Class file constant pool another important feature is dynamic, Java language does not require that constants must only be generated in the compilation time, that is, not pre-built into the Class file of the constant pool content can enter the method area run constant pool, during the run may also put new constants into the pool, this feature is often used by developers is the String class intern () method.

According to the Java virtual machine specification, an OutOfMemoryError exception will be thrown when the method zone cannot meet the memory allocation requirements.

Direct memory (Direct Memory)

Direct memory is not part of the data area when the virtual machine is running memory, nor is it the memory area defined in the Java virtual machine specification. It allocates memory directly from the operating system, so it is not limited by the size of the Java heap, but it is limited by the total memory size of the machine and the processor address space, so it may also lead to OutOfMemoryError exceptions. A new NIO mechanism is introduced in Java1.4, which is a new Istroke O mode based on channels and buffers. Direct memory can be allocated directly from the operating system, that is, memory is allocated outside the heap. This can improve performance in some scenarios because it avoids copying data back and forth in the Native heap and Java heap.

Memory overflow

Here is a simple test method for memory overflow in memory area.

Write the picture description here.

It is important to note here that in the case of multithreading, the larger the memory allocated to each thread's stack, the more likely it is to produce a memory overflow. The operating system allocates limited memory for each process, and the virtual machine provides parameters to control the maximum memory of the Java heap and method area, ignoring the memory consumed by the program counter (very small) and the memory consumed by the process itself, and the remaining memory is given to the virtual machine stack and the local method stack. The larger the stack capacity allocated to each thread, the less the number of threads that can be built. Therefore, if the memory overflow is caused by too many threads, if the number of threads cannot be reduced, more threads can only be obtained by reducing the maximum heap and the stack capacity of each thread. In addition, since memory leaks (Memory Leak) can also occur in the Java heap, here is a brief description of the difference between memory leaks and memory spills:

Memory leak means that the allocated memory is not reclaimed, resulting in a waste of resources due to the loss of control over the memory area. Generally speaking, memory leaks do not occur in Java, because there is a garbage collector that collects garbage automatically, but this is not absolute. When we new an object and save its reference, but it has not been used since then, and the garbage collector will not collect it, it will cause a memory leak.

Memory overflow means that the memory needed by the program exceeds the upper limit of the memory that the system can allocate (including dynamic expansion).

Object instantiation analysis

The most common example of analyzing memory allocation is object instantiation:

Object obj = new Object ()

The execution of this code involves the three most important memory areas: the java stack, the Java heap, and the method area. Assuming that the statement appears in the method body and is used by Java that is not familiar with the JVM virtual machine, you should also know that obj will be saved as data of reference type (reference) in the local variable table of the Java stack, and the instantiated object of that reference will be saved in the Java heap, but you may not know that the Java heap must also contain address information (such as object type, parent class, implemented interface, method, etc.) that can find data of this object type. These types of data are saved in the method area.

In addition, because the reference type only specifies a reference to the object in the Java virtual machine specification, and does not define how the reference should be located and the specific location of the object in the Java heap, the object access methods implemented by different virtual machines will be different, and there are two mainstream access methods: using handle pool and directly using pointer.

Access through the handle pool is as follows:

Write the picture description here.

Access through a direct pointer is as follows:

These two kinds of object access methods have their own advantages. The biggest advantage of using handle access method is that the stable handle address is stored in reference. When the object is moved (it is a very common behavior to move objects when garbage collection), only the instance data pointer in the handle will be changed, but reference itself does not need to be modified. The biggest advantage of using direct pointer access is high speed, which saves the time overhead of pointer positioning. At present, the HotSpot virtual machine used by Java by default uses the second way to access objects.

After reading the above, have you mastered how to understand the JVM memory model? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.