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

This article shows you how to understand the JVM memory model, the content is concise and easy to understand, can definitely brighten your eyes, through the detailed introduction of this article, I hope you can get something.

If we want to understand the JVM memory model, we first need to know what JVM is. JVM, whose full name is Java Virtual Machine, or Java virtual machine, is used to run the compiled bytecode file of the Java program.

The three most common types of JVM are:

HotSpot of 1.Sun is the most widely used Java virtual machine at present.

JRockit of 2.BEA was later acquired by Oracle.

J9VM of 3.IBM Company.

We know that the slogan of Java is: "Write once, run anywhere", that is, write once, run everywhere. Why can you do this? in fact, it depends on JVM. On different operating systems, as long as the corresponding virtual machine is installed, then the same code can be transplanted at will.

When the Java code is written, a .Java file is generated, which is compiled into a .class file by the Java compiler, then the class information is loaded into JVM through Class Loader, and finally JVM invokes the operating system. In this way, as long as the JVM executes the .class file correctly, you can achieve cross-platform.

The following is a diagram of the memory model of JVM:

File

Program counter:

A program counter is a small piece of memory that can be seen as a line number indicator of the bytecode executed by the current thread, that is, the line number of the bytecode executed by the current thread. When the bytecode interpreter works, it selects the next bytecode instruction to be executed by changing the value of the counter. As a result, it can complete the functions of branch, loop, jump, thread recovery, exception handling and so on.

Program counters are private to threads (that is, each thread has a program counter), and program counters between threads do not interfere with each other. The life cycle of the program counter follows the life cycle of the thread. If the thread dies, the program counter will also die.

If a thread is executing a Java method, the program counter records the address of the bytecode instruction being executed; if the native local method is being executed, the program counter records Undefined.

Stack

Refers to the Java virtual machine stack, which is also thread private, so the life cycle is the same as the thread. Whenever a thread is created, a private Java virtual machine stack is created. Local variables and method parameters are saved in the Java stack, which is closely related to the call and return of the Java method.

When each method is executed, a stack frame is created to store local variables, Operand stacks, dynamic links, method exits, and so on. From the call to the execution of each method, it corresponds to the process of a stack frame from the stack to the stack in the virtual machine stack.

Local method stack

The local method stack is very similar to the Java virtual machine stack, except that the Java virtual machine stack is used for Java method calls, while the local method stack is used for Native local method calls.

Heap

The Java heap is an area of memory shared by all threads and is created when the virtual machine starts. For most applications, the Java heap is the largest block of memory managed by JVM, where almost all object instances and arrays are stored.

The Java heap is also the main area managed by the garbage collector. The reactor can be divided into Cenozoic, old age and permanent era, and the Cenozoic can be subdivided into Eden region, From region and To region. When there is no memory to allocate in the heap, an OOM exception is thrown.

Method area

The method zone, like the Java heap, is a memory area shared by all threads. Used to store data such as class information, constants, static variables, code compiled by just-in-time compiler, which have been loaded by the virtual machine. Before JDK8, HotSpot used "permanent generation" to implement the method zone, and other virtual machines (such as JRockit, J9VM) did not have the concept of permanent generation. In this way, the method area can be managed by HotSpot's garbage collector like the Java heap and does not need to be processed separately.

Because we can set the permanent generation size through-XX:MaxPermSize, there is a risk of memory overflow if we use permanent generation to implement the method area. Therefore, in JDk8, the permanent generation is eliminated and metaspace is used instead. In other words, the metaspace is used to implement the method area.

The essence of meta-space is similar to that of permanent generation, which is the realization of the legal area in the JVM specification. The biggest difference between metaspace and permanent generation is that the permanent generation is part of the heap, and the new generation, the old age address is continuous. The metaspace is not in the virtual machine, but belongs to Native Memeory (local memory). Therefore, by default, the size of metaspace is limited only by local memory.

Running constant pool

First of all, you need to know the difference between a constant pool and a running constant pool.

The constant pool, which refers to the constant pool of class files, is part of the class file. After the java file is compiled into a class file, it contains not only the version, field, method, interface and other description information of the class, but also information called the class file constant pool. It is used to store all kinds of literals and symbol references generated during compilation.

File

The run-time pool is part of the method area. When the class is loaded into memory, JVM stores the contents (literals and symbolic references) from the class file constant pool into the runtime pool.

Java does not require that constants can only be generated at compile time, but new constants can be generated and put into the pool at run time.

Direct memory

Java's NIO library allows Java programs to use direct memory. Direct memory is a piece of memory space applied for directly from the system outside the Java heap (direct memory does not belong to the virtual machine runtime data area). Therefore, the size of direct memory is not limited by virtual machines, but only by native memory. Access to direct memory is usually faster than access to the heap.

The above content is how to understand the JVM memory model, have you learned the knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

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.