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

What this article shares with you is about the knowledge of JVM memory management that must be mastered. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

Java prides itself on its automatic memory management mechanism. Compared with C++ 's manual memory management, complex pointers, etc., Java programs are much more convenient to write.

However, this kind of memory request and release method, which is called and waved away, naturally has its price. In order to manage these fast memory request release operations, a pool must be introduced to delay the collection of these memory areas.

What we often call memory recycling is the operation for this pool. We call the above pool a heap, and we can temporarily think of it as a whole.

JVM memory layout

The data structure of Java program is very rich. Here are some examples:

Static member change

Dynamic member variable

Regional variable

Short and compact object declaration

Large and complex memory applications

Let's take a look at the memory layout of JVM. With the development of Java, memory layout is being adjusted all the time. For example, Java 8 and later have completely removed the persistent generation and replaced it with Metaspace. This also means that tuning parameters such as-XX:PermSize and-XX:MaxPermSize is no longer meaningful. But in general, the more important areas of memory are fixed.

The JVM memory area is divided as shown in the figure, from which we can see:

The data in the JVM heap is shared and is the largest memory area.

A module that can execute bytecode is called an execution engine.

How does the execution engine recover when threads switch? It depends on the program counter.

The memory partition of JVM is closely related to multithreading. Like the stack used at run time in our program, and the local method stack, their dimensions are threads.

Local memory contains a metadata area and some direct memory.

Virtual machine stack

The Java virtual machine stack is thread-based. Even if you have only one main () method, it runs as a thread. In the life cycle of a thread, the data involved in the calculation will be frequently put on and off the stack, and the life cycle of the stack is the same as that of the thread.

Each piece of data in the stack is the stack frame. When each Java method is called, a stack frame is created and placed on the stack. Once the corresponding call is completed, the stack is released. After all the stack frames are off the stack, the thread ends. Each stack frame contains four areas:

Local variable scale

Operand stack

Dynamic connection

Return address

Our application is done by constantly manipulating this memory space.

The local method stack is an area very similar to the virtual machine stack, and the object it serves is the native method. You can even think that the virtual machine stack and the local method stack are in the same area, which does not affect our understanding of JVM.

There is a special data type called returnAdress. Because this type exists only at the bytecode level, we usually deal with less. For JVM, a program is a bytecode instruction stored in the method area, and a value of type returnAddress is a pointer to a specific instruction memory address.

Here is a two-story stack. The first layer is the stack frame, which corresponds to the method; the second layer is the execution of the method, which corresponds to the Operand. Be careful not to get mixed up.

You can see that all bytecode instructions are actually abstracted into a pair of stack-in-and-out operations. The execution engine only needs to be executed foolishly in order to ensure its correctness.

Program counter

Since it is a thread, it means that it is unpredictable in obtaining the CPU time slice, and there needs to be a place to buffer the point where the thread is running, so that it can recover quickly when the CPU time slice is obtained.

A program counter is a small piece of memory space that acts as a line number indicator of the bytecode executed by the current thread. What is stored in this is the progress of the current thread execution. The following picture can deepen your understanding of this process.

As you can see, the program counter is also generated by the thread, which cooperates with the virtual machine stack to complete the calculation operation. The program counter also stores currently running processes, including executing instructions, jumps, branches, loops, exception handling, and so on.

We can take a look at the details in the program counter. The following figure shows the bytecode output using the javap command. You can see that there is a serial number in front of each opcode. These are the offset addresses in the red box in the picture, and you can think of them as the contents of the program counter.

Heap

The heap is the largest area of memory on the JVM, and almost all the objects we apply for are stored here. When we often talk about garbage collection, the object of operation is the heap.

Heap space is usually applied when the program starts, but it is not always used.

With the frequent creation of objects and more and more heap space, it is necessary to recycle objects that are no longer in use from time to time. In Java, this is called GC (Garbage Collection).

Due to the different sizes of objects, after running for a long time, the heap space will be filled with many small fragments, resulting in space waste. Therefore, it is not enough to just destroy the object, it also needs to be sorted out by heap space. The process is very complicated.

When an object is created, is it allocated on the heap or on the stack? This is related to two aspects: the type of the object and the location that exists in the Java class.

Java objects can be divided into basic data types and normal objects.

For normal objects, JVM first creates the object on the heap, and then uses its reference elsewhere. For example, save this reference in the local variable table of the virtual machine stack.

For basic data types (byte, short, int, long, float, double, char), there are two cases.

As we mentioned above, each thread has a virtual machine stack. When you declare an object of the basic data type in the method body, it is allocated directly on the stack. In other cases, it is allocated on the heap.

Note that content such as the int [] array is allocated on the heap. Arrays are not basic data types.

This is the basic memory allocation strategy of JVM. While the heap is shared by all threads, if it is accessed by multiple threads, it will involve data synchronization problems.

Meta-space

With regard to metaspace, let's start with a very high-frequency interview question: "Why is there a Metaspace area? what's wrong with it?"

At this point, you should recall the difference between classes and objects. An object is a living individual that can participate in the operation of a program; a class is more like a template that defines a series of properties and operations. Then you can imagine. Which area of the JVM is the A.class that we generated earlier?

If you want to answer this question, you have to mention the history of Java. Before Java 8, the information about these classes was kept in a memory called the Perm area. Earlier versions, and even the String.intern-related runtime quantity pool, are here. This area has a size limit and can easily cause JVM memory overflows, resulting in JVM crashes.

The Perm area has been completely abolished in Java 8 and replaced by Metaspace. The original Perm area is on the heap, but now the metaspace is on the non-heap, which is the background. For their comparison, you can take a look at this picture.

Then, the benefits of metaspace are also its disadvantages. The memory of the operating system can be used with non-heap, and there will be no memory overflow in the method area in JVM; however, unlimited use will cause the death of the operating system. Therefore, the parameter-XX:MaxMetaspaceSize is generally used to control the size.

The method zone, as a concept, still exists. Its physical storage container is Metaspace. Now, all you need to know is what is stored in this area, including class information, constant pools, method data, and method code.

Summary

Where are the string constants we often talk about?

Because of the constant pool, after Java 7, put on the heap, the string we created will be allocated on the heap.

What does it matter, heap, non-heap, and local memory?

We can look at a picture about their relationship. In my opinion, the heap is soft, loose and elastic, while the non-heap is cold and stiff, and the memory is very compact.

As we all know, when JVM is running, it will apply for large chunks of in-heap memory from the operating system to store data. However, out-of-heap memory, that is, the remaining memory of the operating system after the application, will also be partially controlled by JVM. More typical are some native keyword modification methods, as well as the application and processing of memory.

On Linux machines, using the top or ps command, you can see that the RSS segment (the actual memory footprint) is larger than the heap memory allocated to JVM in most cases.

If you apply for a host with 2GB memory, the only thing JVM can use is 1GB, which is a limitation.

The runtime area of JVM is the stack, while the storage area is the heap. In fact, many variables are already fixed during the compilation period.

The above is what the knowledge of JVM memory management must be mastered, and the editor believes that some of the knowledge points may be seen or used in our daily work. I hope you can learn more from this article. For more details, please 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.