JVM memory mechanism

Notes on JVM memory mechanism

 
 

 

Heap)
In the runtime data area, the memory of all class instances and arrays is allocated here. Created when the Java Virtual Machine is started. The object heap memory is recycled by the automatic memory management system called the garbage collector.
Composition
News Generation (Young Generation is the Eden + From Space + To Space in the figure)
Eden stores new objects
Movie vor Space: two objects that survive each garbage collection
The Old Generation (Tenured Generation is the Old Space in the figure) mainly stores the surviving objects with a long life cycle in the application.
Non-heap memory
JVM has a method area shared by all threads. The method area is non-heap memory. It stores the structure of each class, such as the runtime data pool, field and method data, and Code of methods and constructor methods. It is created when the Java Virtual Machine is started.
In addition to the method area, Java Virtual Machine implementation may need to be used for internal processing or optimization of memory, which is also non-heap memory. For example, the JIT compiler requires memory to store the locally converted code from the Java virtual machine code to achieve high performance.
Composition
Permanent Generation (the Permanent Space in the figure) Stores JVM reflection objects, such as class objects and method objects.
Native heap

GC Policy

Heap
JVM adopts a generational collection policy to scan and recycle young objects at a high frequency. This is called minor collection, the check frequency for old objects (old generation) is much lower, which is called major collection. In this way, you do not need to check all objects in the memory every GC.

When a URL is accessed, the memory application process is as follows:
A. JVM will try to initialize A memory area for the relevant Java object in Eden
B. When the Eden space is sufficient, the memory application is completed. Otherwise, go to the next step.
C. JVM tries to release all inactive objects in Eden (which belongs to 1 or more advanced garbage collection). If the Eden space is not enough to put new objects, try to put some active objects in Eden into the same vor Area
D. The primary vor area is used as the intermediate swap area of Eden and OLD. When the OLD area has sufficient space, objects in the primary vor area will be moved to the Old area. Otherwise, objects in the primary vor area will be retained.
E. When there is not enough space in the OLD area, JVM will perform full garbage collection in the OLD area (Level 0)
F. after full garbage collection, if the primary VOR and OLD areas still cannot store some objects copied from Eden, the JVM cannot create a memory area for the new object in the Eden area, "out of memory error" appears"

Aging Process of objects
The memory of young generation is composed of an Eden (Eden, interesting) and two pair vor spaces (semi-Space in document 1.4. The memory of the newly created object is allocated from eden. There will always be two idle vor spaces that are used as the destination Space for copying collection. The Minor collection process is to copy the eden and the live objects in the consumer vor space to the idle consumer vor space. The so-called movie vor, that is, after the birth of most objects in the Garden of Eden, it cannot survive a GC. After the object has undergone a certain number of minor collections in young generation, it will be moved to old generation as tenuring. (Is it true that the old object tenuring is used only when the primary vor space is insufficient? The description is not found in the current information)
If the remaining memory space is insufficient, GC is triggered. If the eden space is insufficient, minor collection is required. If the old generation space is insufficient, major collection is required. If the permanent generation space is insufficient, full GC is triggered.

 

Non-heap memory

GC (Garbage Collection) does not clean up the PermGen space during the main program running period. Therefore, if your application has many classes, the PermGen space error may occur.

 

 

JVM default settings

Heap (the sum of News Generation and Old Generaion) settings

The initial allocated memory is specified by-Xms. By default, it is 1/64 of the physical memory but less than 1 GB.

The maximum allocated memory is specified by-Xmx. By default, it is 1/4 of the physical memory but less than 1 GB.

By default, when the free heap memory is less than 40%, the JVM will increase the heap until the maximum limit of-Xmx can be specified by-XX: MinHeapFreeRatio =.
By default, when the free heap memory is greater than 70%, the JVM will reduce the minimum heap limit to-Xms, which can be specified by-XX: MaxHeapFreeRatio =.

Generally, the server sets-Xms and-Xmx to be equal to each other to avoid adjusting the heap size after each GC. Therefore, the above two parameters are useless.

-Xmn: Set the heap size of young generation.

-XX: MinHeapFreeRatio and-XX: MaxHeapFreeRatio set the percentage of idle memory to the total memory. These two parameters will affect the GC frequency and the time consumed by a single GC. -XX: NewRatio determines the ratio of young to oldgeneration. The larger the Young generation space, the lower the minor collection frequency, but the smaller the oldgeneration space may increase the majorcollection frequency. -XX: NewSize and-XX: MaxNewSize specify the default and maximum values of younggeneration.

 

Non-heap memory settings

The default value is 64 MB.

-XX: PermSize sets the minimum allocation space,-XX: MaxPermSize sets the maximum allocation space. Generally, these two values are set to the same to reduce the time for applying for memory space.

 

 

Causes of memory overflow

Old Generation Overflow
This memory overflow is one of the most common causes, which may be caused:
1) The set memory parameter is too small (MS/mx, NewSize/MaxNewSize)

Solution:

For java jvm parameter settings in a 1 GB memory environment, refer:

-Server-Xms800m-Xmx800m-XX: PermSize = 64 M-XX: MaxNewSize = 256 m-XX: MaxPermSize = 128 m-Djava. awt. headless = true

2) program Problems
A single program continues to process memory consumption, such as string processing thousands of times. StringBuffer is recommended for string processing. At this time, no memory overflow error will be reported, but the system will continue to collect garbage and cannot process other requests. Related Programs can obtain the error through ThreadDump.

The memory applied by a single program is too large. Some programs will apply for dozens or even hundreds of megabytes of memory. At this time, the JVM will also experience memory overflow due to the inability to apply for resources. First, find the relevant functions, then hand it to the programmer for modification. To find the relevant program, you must search for it in the Apache log.
After a Java object is used up, the referenced object is not destroyed, so that the JVM considers it to be an active object and does not recycle it. In this way, it occupies a large amount of memory and cannot be released. As there is no memory analysis tool on the market that has little impact on the system, it can only be located with programmers.

 

 

Permanent Generation Overflow
Usually, overflow is caused by a large number of classes loaded in the Perm segment, such as the dynamic generation class of spring.

Current solution:
1) Increase the PermSize. Generally, MB can meet the requirements.
2) If you have no choice, you can only add the servlet Path to the CLASSPATH. However, this is generally not recommended.

C Heap Overflow
The system has no restrictions on C Heap. Therefore, when a problem occurs in C Heap, the memory occupied by Java processes will continue to grow until all available system memory is occupied.