automatic memory management in the Java system solves two major problems: allocating memory to objects and reclaiming memory allocated to objects. in general, objects are allocated on the heap (but may also be broken down into scalar types and indirectly allocated on the stack after being compiled by JIT (Java-just-in-time compilation), and the object is primarily allocated to the Eden Zone in the Cenozoic, and if the local thread allocation buffer is started, it will be prioritized by thread Tlab. It can also be assigned directly in the old age by configuring the-xx:pretenuresizethreshold parameter.
English Poetry:Max Tenuring occupies threshole threshold
Object Limited allocation in Eden areain most cases, objects are allocated in the new generation of Eden, and when the Eden area is low on memory, a minor GC is performed.
(Young generation GC)
You can configure the-xx:printgcdetails parameter to tell the virtual machine to print the memory recycle log when the garbage collection behavior occurs, and to output the distribution of the current memory regions when the process exits.
configuration Parameters-xms20m,-xmx20m and-xmn10m set the Java heap size to 20M, and not extensible, while setting up the Cenozoic 10M, the remaining 10M allocated to the old age.
Configuration Parameters-xx:survivorratio=8 Setting the Eden area in the Cenozoic with a survivor space size is 8:1.
Minor GC: The new generation of GC, occurs in the new generation of garbage collection action, because the new generation of objects have the face of the death characteristics, so Minor GC is very frequent.
Major gc/full GC: The old GC, the garbage collection action that occurred in the old age, is usually preceded by at least one minor GC before the full GC is sent. The full GC is 10 times times slower than the minor GC.
Large objects go straight into the old age The large object referred to here refers to Java objects that require a large amount of contiguous memory space, typically a particularly long string and array. Frequent large objects can cause memory to have a lot of spare time to trigger GC actions ahead of time to get enough contiguous space.
The short -lived large objects of the Asao are allocated in the new generation of Eden, which causes too many GC operations from the Eden, from Survivor through to Survivor two regions. You should avoid generating such objects in your development.
Configuring the-xx:pretenuresizethreshold parameter allows objects larger than this threshold to be allocated directly into the old age, thus avoiding the copying of objects in Eden and two survivor intervals. Note: The new generation uses a replication algorithm to reclaim memory.
long-lived objects will enter the old age. The virtual machine uses the idea of the generational collector to manage the memory, the generational algorithm is: The new generation of objects are facing to die, using a copy algorithm, Eden\from Survivor to the Survivor region of the copy is still alive object; object markers in the old age-cleanup and tagging-sorting To avoid a large number of live copies of large objects back and forth.
So when the object is copied from the Eden, from Survivor region, how does it decide whether the object should be put into the to Survivor or the old age? The virtual machine defines an age calculator for each object, which is moved to the survivor area and the object age is set to 1 if the object survives once minor GC and can be accommodated to survivor. Object in Survivor each time minor GC, the age increases one year old, when his age reaches a certain ages (by default 15 years old), will be promoted to the old age. Configuration parameters-xx:maxtenuringthreshold=8 setting objects promotion to the old age range at age 8.
Dynamic Determination of object age if the sum of all objects of the same age in the Sruvivor interval is greater than half of the survivor space, objects older than or equal to that age will go directly to the old age without waiting for the-xx:maxtenuringthreshole setting.
space allocation guarantee when sending minor GC, the average size of each promotion to the old age is greater than the remaining space size of the old age before the virtual opportunity is detected. If greater than, the direct full GC is changed; If it is less than, then see if the Handlepromotionfailure setting allows the warranty to fail, if allowed, the minor GC will be performed, and if a handlepromotionfailure failure occurs, the full GC will be restarted after the failure; If not, the full GC is also changed to one time.
The new generation uses a replication algorithm to reclaim memory, and for memory utilization, only one of the survivor is used as a rotational backup, so when survivor's space is not enough to store MINORGC surviving objects, the old age is needed for distribution guarantees. The premise is that the old age needs to have enough space to store MINORGC surviving objects, altogether how many objects will survive, before the actual completion of the collection is not clear. So we can only take the average size value of the previous recovery to the old age object capacity as an empirical value, if the experience value is greater than the old age of space, you need to do a full GC.
since it is the average, there will be a case where the actual value is greater than the old age space, then there will be a guarantee failure, and if a guarantee fails, a full GC will be performed after the failure.
Although the guarantee fails and then the full GC is around a large circle, most will also open the handlpromotionfailure switch to prevent the full GC from being too frequent.
garbage collector Stop The world! the other threads must be paused when the GC begins to work.
Parallel: Multiple garbage collection threads work in parallel, but the user thread is still paused at this point. Concurrency: The user thread and the garbage collection thread execute concurrently, but not necessarily in parallel, and may be alternately executed. The user thread continues to run, and the garbage collection thread runs on the other CPU.
JVM GC's two-object assignment
