Java virtual machines are garbage collected in the way of memory recycling, C/s can control memory release through code, prevent memory leaks, set different garbage collection methods and parameters will affect the effect of garbage collection, and this to the stability of the system and the support capacity of the single machine.
The JVM instruction set does not provide a garbage collection release operation, so it is not possible to free up memory directly, but to dedicate a garbage collector to complete the garbage collection work.
Different garbage collector products have different recycling strategies, first look at the layout of memory in the Oracle Hotspot JVM, 3.2
As can be seen, there are three major areas of young/tenured/perm, which we often call the new generation/old age/lasting generation.
In general, new objects are assigned to the next generation (young) Eden area and may also be assigned directly to the old generation (Perm), where the surviving objects of the Eden area are copied to the empty Survior area when the generation of garbage collection is carried out, and in the coming generation of garbage collection, The surviving objects in the Eden area and the surviving objects in this survivor area are copied to another survivor area, and the current survivor area is emptied. After many generations of garbage collection, but also the survival of the object was moved to the old age, and the old age will be based on a certain time garbage collection.
In the hotspot, for the new generation of GC mode:
Serial gc:serial Copying
Parallel gc:parnew
Parallel Recovery Gc:parallel Scavenge
The following GC methods are available for the old age:
Serial gc:serial MSC
Parallel Ms Gc:parallel MSC
Parallel gc:compacting Gc-parallel Compacting
Concurrent GC-CMS
In Sun's Java6 update14, the garbage first (G1) collector was introduced, and the goal of G1 was to replace the CMS.
Java garbage collection and heap memory layout