The Java VIRTUAL machine divides the heap into chunks based on the lifetime of the object, typically new generation, old generation, and (in the case of the HotSpot VIRTUAL machine) permanent generation. This is the MEMORY generation strategy of the JVM.
Why do we divide generations?
Heap memory is the largest area of memory managed by the virtual machine, and it is also the most frequently garbage collected area. All object instances of our program are stored in the heap memory. The purpose of generational heap memory is to improve the efficiency of object memory allocation and garbage collection. Imagine if the heap memory without division, all of the newly created object and a long life cycle together, with the execution of the program, the heap memory need frequent garbage collection, and recycling every time want to iterate through all the objects, traverse the object the time cost is huge, will seriously affect our efficiency of GC, it’s terrible.
With memory generational, the situation is different, the newly created object will allocate memory in the Cenozoic, after many recovery still survive object in old age, static properties, such as the class information in the permanent generation, the object in the Cenozoic survival time is short, only need to frequent the GC in the Cenozoic area, old s objects in the life cycle is long, The frequency of memory collection is relatively low, so there is no need to recycle frequently. The recycling effect is too poor in the permanent generation. Garbage collection is generally not carried out, and appropriate garbage collection algorithms can be adopted according to the characteristics of different generations. Generational collection greatly improves collection efficiency. These are the benefits of memory generational collection.
Memory generation
The Java VIRTUAL machine divides the heap into new generation, old generation, and persistent generation. The concept of persistent generation is unique to the HotSpot VIRTUAL machine. It implements the method area in the way of persistent generation, and other virtual machine implementations do not have this concept. In JDK 1.7 HotSpot has started to “de-perpetuate”, removing the string constant pool from the permanent generation. The permanent generation mainly stores constants, class information, static variables and other data, which has little relation with garbage recycling. The new generation and the old generation are the main areas of garbage recycling. The memory generation diagram is as follows:
Young Generation
The newly generated objects are preferentially stored in the new generation, and the new generation objects die overnight and have a very low survival rate. In the new generation, the conventional application of a garbage collection can generally recover 70% to 95% of the space, with high recycling efficiency.
HotSpot divides the new generation into three sections, one large Eden space and two small Survivor Spaces, with a default ratio of 8:1:1. The reason for this is because HotSpot uses a copy algorithm to recycle the new generation. The ratio is set to make full use of memory and reduce waste. Newly generated objects are allocated in Eden (except for large objects, which go directly to the old age). When Eden does not have enough space to allocate, the virtual machine will initiate a Minor GC.
When GC starts, objects only exist in the Eden zone and From Survivor zone; the To Survivor zone is empty (as a reserved zone). During GC, all surviving objects in Eden are copied To To Survivor. In From Survivor, surviving objects go where they are based on their age, which reaches an age threshold (default: 15). Each time objects in the new generation survive a garbage collection cycle, their age is increased by 1. Objects whose GC generation ages are stored in the header of the object are moved To the old age, and objects that do not reach the threshold are copied To Survivor zones. Then clear the Eden zone and From Survivor zone. All the surviving objects of the new generation are in the To Survivor zone. Then, the From Survivor and To Survivor zones swap roles, so the new To Survivor zone is the From Survivor zone cleared by the last GC, and the new From Survivor zone is the To Survivor zone cleared by the last GC, so anyway, Either way, the To Survivor zone is guaranteed To be empty after a GC round. When GC does not have enough space To store the surviving objects collected by the previous generation in the Survivor area, it needs To rely on the old generation for allocation guarantee To store these objects in the old generation.
Old age
Objects that survive multiple GCS in the new generation (depending on the virtual machine configuration threshold) will enter the old generation. The life cycle of objects in the old age is longer, the survival rate is higher, the frequency of GC in the old age is relatively low, and the recovery speed is slower.
Permanent
The persistent generation stores data such as class information, constants, static variables, code compiled by the just-in-time compiler, and so on. For this area, the Java Virtual Machine specification states that garbage collection can be eliminated, and in general, no garbage collection.
The difference between Minor and Full GC
Minor GC: Minor GC refers to GC that occurs in the new generation. Since Java objects in the new generation tend to die overnight, Minor GC is very frequent and tends to be collected quickly. Minor GC is triggered when Eden space is insufficient to allocate memory for an object.
Full GC (Major GC) : A Full GC is a GC that occurs in an older generation, and a Full GC is usually accompanied by at least one Minor GC, such as a failed allocation guarantee. A Full GC is typically 10 times slower than a Minor GC. Full GC is triggered when the old generation is out of memory or when the system.gc () method is explicitly called.
Three things to watch ❤️
If you find this article helpful, I’d like to invite you to do three small favors for me:
-
Like, forward, have your “like and comment”, is the motivation of my creation.
-
Follow the public account “Java rotten pigskin” and share original knowledge from time to time.
-
Also look forward to the follow-up article ing🚀
-
[666] Scan the code to obtain the learning materials package
Author: Wind program ape
Source: www.cnblogs.com/fangfuhai/p…