JVM exploration-Memory Management (1), jvm exploration Memory Management

JVM exploration-Memory Management (1), jvm exploration Memory Management

 

The first article in this series is expected to have two or three cases at the end of this series.

Java is different from C and C ++. Java does not need Coder for manual memory management, and all of this is handed over to JVM for automatic memory management, to some extent, this reduces the Coder encoding workload. Is it necessary for us to understand the JVM memory management mechanism? The answer is no; because Java will also cause memory leakage and memory overflow like C and C ++, although there will be fewer such accidents, but once it happens and you don't know about its memory management mechanism, it will be very tricky. Another reason is that Java runs on the JVM, without JVM parameters, the execution performance of the program may be affected. To achieve the optimal performance of the JVM in a specific application, we must understand the internal mechanism of JVM; not to mention the introduction of JVM Exploration Series-memory management

According to the Java Virtual Machine specification, when a Java virtual machine executes a Java program, the memory it manages is divided into several Areas, that is, the Run-Time Data zone (Run-Time Data Areas ); these regions have different functions and lifecycles. They are mainly divided into two categories: one is created with the startup of the JVM process and destroyed with the demise of the JVM process; one is created with the creation of threads and destroyed with the destruction of threads. The memory areas stipulated in Java Virtual Machine specifications are as follows:

 

 

The two regions of the red border are shared by all threads (the JVM process is created when it is started, and the process is destroyed when it disappears)

The other three zones are isolated by threads (the threads are created and destroyed upon thread destruction)

 

Run-time Areas can be divided into: Method Area, Heap, Java stack, and Native method Stacks) and PC Register;

 

1. PC Register)

The PC Register (PC Register) stores the address of the currently running commands (bytecode instructions). Each thread that is private to a thread has an independent Register; if the Java method is being executed, the address of the bytecode instruction is stored. If the Native method is executed, the value is null (undefined ).

2. Java Virtual Machine Stacks)

Java Virtual Machine Stack: the unique life cycle of a thread is the same as that of a thread. Java Virtual Machine Stack is used to store Stack frames. A Stack Frame is created during Java method execution) stores information such as the local variable table, operand Stack, dynamic link, and method exit. The method starts to execute the Stack Frame into the Java Virtual Machine Stack. After the method is executed, the Stack is output. (Java VM specification stipulates that the Java VM stack will throw two types of exceptions: StackOverlowError and OutOfMemoryError. The first is that the stack thread request stack capacity exceeds the maximum capacity allowed by the Java VM, the second is not allocated enough memory ).

3. Heap)

In the Java virtual machine, the heap is shared by all thread locks. It is created when the Java Virtual Machine is started and used to store object instances and Array Memory allocation,

4. Native Method stack)

It is used to execute the Native method. Some virtual machines combine it with the Java Virtual Machine stack (such as HotSpot) and throw two types of exceptions: StackOverlowError and OutOfMemoryError.

5. Method Zone)

The method area is the same as the Java heap. All threads are shared when the virtual machine is started; stores the class information loaded by the virtual machine, the runtime volume pool, fields, method data, and the bytecode content after the real-time compiler compilation. The stored content is basically from the class file; different virtual machines have different implementation methods. In the HotSpot virtual machine, the method area can be called the permanent generation, and the GC collection Assembly recycles the method area. When the method area cannot meet the memory allocation, the Java Virtual Machine will throw an OutOfMemoryError.

5.1 Runtime Constant Pool)

The runtime constant pool, a part of the method area, and the runtime expression of the class or interface constant pool, stores the literal volume and symbolic reference generated after compilation (reference of methods and fields ); A constant can be added during running, the intern () of the String class. This is the case with the method. An OutOfMemoryError error is thrown when the memory cannot be applied.

 

After introducing the regions of JVM memory, let's look at the following code:

Public class Model {

Private static int I = 1;

Public Model (){

}

}

After Model model = new Model () is instantiated, I will store it in the Runtime Constant Pool of Method Aeras, the reference of the instantiated model will be stored in the local variable table of the Java VM stack, and the instance (instance data) corresponding to the new Model () will be stored in the Java Heap) the constructor Model () will also be stored in the method area.

 

The personal blog updates the website at the same time: Http: // www. solinx. co

How to manage jvm memory

Typical settings:
• Java-Xmx3550m-Xms3550m-Xmn2g-Xss128k
-Xmx3550m: sets the maximum available JVM memory to 3550 MB.
-Xms3550m: Set JVM to enable the memory to be 3550 MB. This value can be set to the same as-Xmx to avoid JVM re-allocating memory after each garbage collection.
-Xmn2g: Set the young generation to 2 GB. Total heap size = size of the young generation + size of the old generation + size of the persistent generation. The permanent generation usually has a fixed size of 64 m. Therefore, increasing the size of the young generation will reduce the size of the old generation. This value has a great impact on the system performance. Sun officially recommends 3/8 of the total heap configuration.
-Xss128k: Set the stack size of each thread. After JDK 256, the size of each thread stack is 1 MB, and the size of each previous thread stack is K. The memory size required for more application threads is adjusted. Reduce this value to generate more threads in the same physical memory. However, the operating system still has a limit on the number of threads in a process. It cannot be generated infinitely. The experience is between 3000 and ~ About 5000.
• Java-Xmx3550m-Xms3550m-Xss128k-XX: NewRatio = 4-XX: Export vorratio = 4-XX: MaxPermSize = 16 m-XX: MaxTenuringThreshold = 0
-XX: NewRatio = 4: Set the ratio of the young generation (including Eden and two region vor regions) to the old generation (excluding the permanent generation ). If this parameter is set to 4, the ratio of the young generation to the old generation is, and the young generation accounts for 1/5 of the entire stack.
-XX: Region vorratio = 4: Set the ratio of Eden to region vor in the young generation. If this parameter is set to 4, the ratio of two vor zones to One Eden zone is, and one vor zone accounts for 1/6 of the young generation.
-XX: MaxPermSize = 16 m: sets the persistent generation size to 16 m.
-XX: MaxTenuringThreshold = 0: sets the maximum age of spam. If it is set to 0, the young generation object directly enters the old generation without going through the VOR area. For applications with many older generations, the efficiency can be improved. If this value is set to a greater value, the young generation object will be copied multiple times in the same vor area, which can increase the survival time of the young generation object, added an overview of being recycled in the young generation.

How to manage java JVM virtual memory

JVM memory management: goes deep into the garbage collector and memory allocation policies
There is a wall between Java and C ++ that is surrounded by the dynamic memory allocation and garbage collection technology. The people who look at it want to go in, but the people inside the wall want to come up with it.
Overview: when talking about Garbage Collection (GC), most people regard this technology as a companion product of the Java language. In fact, GC history is far older than Java. The Lisp, which was born in 1960 by MIT, is the first language that truly uses the dynamic memory allocation and garbage collection technology. When Lisp is still in the embryo, people are thinking about three things GC needs to do: What memory needs to be recycled? When will it be recycled? How to recycle it?
Call back the time from October 11 to the present and return to the familiar Java language. The first chapter of this article introduces each part of the Java memory runtime region, where the program counters, VM stacks, and local method stacks are generated with threads and destroyed with threads; frames in the stack are methodically launched into the stack as the method enters and exits; the amount of memory allocated in each frame is basically known when the Class file is generated (it may be optimized by JIT dynamic late compilation, but it can be considered as known during the compilation period ), therefore, the memory allocation and recovery in these regions are highly deterministic, so there is no need to consider the issue of recovery too much in these regions. The Java heap and the method area (including the runtime frequent pool) are different. We must wait until the program is actually running to know which objects will be created, the allocation and recovery of this part of memory are dynamic. The "Memory" Allocation and recovery we will discuss later only refer to this part of memory.
Reference Counting)
The original idea is that many textbooks use the following algorithm to determine whether an object is alive: Add a reference counter to the object. When there is a place to reference it, add 1 to the counter. When the reference fails, the counter minus 1. Objects whose counter is 0 at any time cannot be used again.
Objectively speaking, the reference counting algorithm is easy to implement and highly efficient in determination. In most cases, it is a good algorithm, but the reference counting algorithm cannot solve the problem of object circular reference. For example, the objects A and B have fields B and a, respectively. B = B and B. a = A. In addition, the two objects have no reference. In fact, the two objects cannot be accessed again, but the reference counting algorithm cannot recycle them.
Root search algorithm (GC Roots Tracing)
In actual production languages (Java, C #, and even the previously mentioned Lisp), the root search algorithm is used to determine whether an object is alive. The basic idea of the algorithm is to perform a downward search through a series of points called "GC Roots" as the starting point. When an object is connected to GC Roots, there is no Reference Chain, it proves that this object is unavailable. In Java, GC Roots includes:
1. Reference in VM stack (local variable in frame)
2. Static reference in the Method Area
3. References in JNI (the Native method in general)
Survival or death?