directory

[TOC]

preface

In the use of Java process, we will find the Java memory is their release, not like C, C + + code, every memory together need a programmer to maintain, but in such a convenient at the same time may also appear many problems, such as memory, the memory leak is cleared, so today’s article, Moon takes you through the virtual machine memory management mountain by walking you through what the Java memory area really looks like and what each component does.

The body of the

Let’s start with a picture:

This picture is a Java virtual during a data graph, dark area representative is threads share area, in the process of running the Java program will take his memory management is divided into a number of different data area, each data area that is responsible for the function is different, they also have different create it and destroy it, This article will start from this diagram and expand one by one, clearly telling you the function of each module.

1. Program counter

Like the traffic lights that control urban traffic, the program counter is the backbone of the entire system. In the JVM, it is an indicator of program control flow, and the program counter is used for loops, jumps, exception handling, thread recovery, and so on. The program counter is private to the thread, thread and its life cycle is consistent, we know that N the number of core CPU at the same time, most have N threads run at the same time, in the process of our real use may create a lot of threads, the JVM multithreading is by changing thread turns assignment handler execution time. Since thread switching is involved, each thread must have a separate program counter.

2. Vm stack

The virtual machine stack, which describes the thread-memory model, also known as the thread stack, is also private to each thread and has the same life cycle as the thread. At each method execution, the JVM synchronously creates a stack frame to store information about local variables, operand stacks, dynamic joins, method exits, and so on. The life cycle of a method carries out the entire process of a stack frame from loading to unloading. The list of local variables is probably the most common. It contains Java’s 8 basic data types (byte, short, char, int, float, long, double, Boolean), object references (reference type, not the object itself, Is a reference to an object) and the returnAddress type (an address pointing to a bytecode instruction). Local variable tables are stored in local variable slots. Long and double occupy two slots and the rest occupy only one, but the size of each slot is determined by the JVM itself.

3. Local method stack

It is easy to understand the concept of local method stack. As we know, Java uses a lot of C code to realize it at the bottom level, and there are native methods on the C-side that represent local method services, for which the local method stack serves.

4. The heap

The heap is arguably the largest area of memory in the JVM, and it is shared by all threads. Whether you are a beginner or an experienced developer, you will have heard of the heap at some point, since almost all objects are allocated in the heap.

    Let’s look at what the heap looks like in terms of allocating memory, right:In fact, this is the most realistic heap, and some of you might think I’m wrong, there should be Cenozoic, old age, permanent generation, Eden, Servivor, and so on. This statement is logically correct, but it’s not a standard, it’s just a design concept for some garbage collector that needs to work with both new and old collectors.

In other words, tlabs are allocated in the heap space and are private to the thread. Objects will be stored in the TLAB that is private to the thread. In this way, thread allocation efficiency can be improved.

5. Methods area

The method area is also the area shared by all threads, which stores type information, constants, static variables, and so on that are loaded by the JVM. The runtime constant pool is the part of the method area where literal and symbolic references generated at compile time are stored.

6. Direct memory

This data is not part of the JVM runtime data area, and niO uses direct memory, or out-of-heap memory, which is usually used in conjunction with virtual references. For resource release, information about out-of-heap memory is stored in a queue, and the GC cleans up this space.

Out-of-heap memory Advantage In I/O operations, when network I/OS are sent using sockets, data copy from the heap memory to the out-of-heap memory is saved, so the performance is higher. Those of you who have read Netty’s source code should know that Netty uses an out-of-heap memory pool to implement zero-copy technology. For disk I/O, you can also use memory mapping to improve performance. Also, more importantly, there is almost no need to worry about the annoying GC problem of heap memory. But since it’s memory. It’s also limited by the total native memory,

conclusion

Today, I talked with you about how Java memory area is, and this part is a relatively standardized embodiment, without any knowledge about garbage collection or the specific implementation logic of JVM. We know that this is a basic architecture, and the default JVM we use in development is hotspot. It is the VIRTUAL machine with SunJDK and OpenJDK, but also the most widely used Java virtual machine, they are based on THE JVM specification to develop, so after understanding the specification to learn other in-depth implementation, do not learn each knowledge point disorder.

In the next article I will talk about object creation and memory layout of objects.

I’ll see you next time. I’m Moon