I. Garbage collection Log Description
[Gc[defnew:7307k->494k (9216K), 0.0043710 secs] 7307k->6638k (19456K), 0.0044894 secs] [times:user=0.02 sys=0.00, real=0.01 secs]
1, the log development "[GC" explains the garbage collection of the pause type, if there is full, this GC is Stop-the-world.
2. The next "[Defnew" indicates the area where the GC occurs, and the area name shown here is closely related to the GC collector used. For example, "Default New Generation" in the serial collector, so "[defnew" is displayed. If it is a parnew collector, "[parnew" is displayed. If it is a parallel scavenge collector, the "Psyounggen" is displayed.
3. The "7307k->494k (9216K)" inside the square brackets behind it means that the area has used capacity (the total capacity of the memory area) since the zone was->GC before the GC. The meaning of "7307k->6638k (19456K)" Outside the square brackets is that the Java heap has used capacity (the total Java heap capacity) before the GC has used capacity->GC.
4. Then, "0.0044894 secs" indicates the time, in seconds, that the GC in this memory area occupies.
Ii. priority of objects in Eden allocation
Objects are usually allocated in the new generation of Eden, and when there is not enough space in the Eden area, the virtual opportunity initiates a minor GC. There are also major GC, full GC corresponding to the minor GC.
Minor GC: Refers to the garbage collection action occurring in the Cenozoic, very frequently. Faster.
Major GC: Refers to the GC, which occurs in the old age, Major GC, often accompanied by a minor GC, while minor GC will also cause Major GC, generally referred to as GC in the GC log, infrequent.
Full GC: Refers to a GC that occurs in the old and new generation, slower and requires stop the world.
Test code:
/*** The virtual machine parameter is "-verbose:gc-xx:+printgcdetails-xms20m-xmx20m-xmn10m-xx:survivorratio=8", namely 10M Cenozoic, 10M old age, 10M New generation 8M of Eden area, two survivor area 1 m
*-XMS is the minimum heap capacity, the-XMX is the maximum capacity of the heap,-XMN is the Cenozoic capacity, survivorratio=8 for the Eden and survivor (from, to) ratio 8:1:1*/ Public classtestallocation {Private Static Final int_1MB = 1024 * 1024; Public Static voidTest () {byte[] allocation1,allocation2,allocation3,allocation4; Allocation1=New byte[2 *_1MB]; Allocation2=New byte[2 *_1MB]; Allocation3=New byte[2 *_1MB]; Allocation4=New byte[4 * _1MB];//one minor GC appears } Public Static voidMain (string[] args) {test (); }}
Test results:
[Gc[defnew:7307k->494k (9216K), 0.0043710 secs]7307k->6638k (19456K), 0.0044894 secs] [times:user=0.02 sys=0.00, real=0.01secs] Heap defNewGeneration Total 9216K, used 4920K [0x04800000, 0x05200000, 0x05200000) Eden Space 8192K, 54% used[0x04800000, 0x04c52770, 0x05000000) from space 1024K, 48% used[0x05100000, 0x0517b970, 0x05200000) to Space 1024K, 0% used[0x05000000, 0x05000000, 0x05100000) tenured generation total 10240K, used 6144K [0x05200000, 0x05c00000, 0x05c00000) The space 10240K, 60% used[0x05200000, 0x05800030, 0x05800200, 0x05c00000) Compacting Perm gen Total 12288K, used 1672K [0x05c00000, 0x06800000, 0x09c00000) The space 12288K,13% used [0x05c00000, 0x05da22f0, 0x05da2400, 0x06800000)
Description
The GC pre-Cenozoic took up 7M, then came a 4m,eden and from only 2M is not enough allocated, triggering a minor GC. But the GC after the memory is still not enough, because Application1, Application2, Application3 Three references also exist, the other piece of 1M survivor is not enough to put down this total of three objects 6M, then this time minor The effect of GC is actually to transfer the 6 m content into the old age by assigning a guarantee mechanism. Then a 4M, because at this time minor GC after the Cenozoic only used 494K, enough to allocate, so 4M smoothly into the new generation.
Three, the big object enters the old age directly
Large objects are Java objects that require a large amount of contiguous memory space, the most typical large object is that long string and arrays, large objects on the allocation of virtual machines is a bad news (more than the encounter of large objects more pregnant with a group of "facing the birth of the" short-lived large objects, writing procedures should be avoided). Often large objects tend to cause memory to have a lot of space to trigger the garbage collector to reclaim in advance to get enough contiguous space to accommodate them.
The virtual machine provides the-xx:pretenuresizethreadshold parameter to set the threshold value of a large object, exceeding the threshold of the object directly into the old age. This is done to avoid a large amount of memory duplication between the Eden Zone and the two survivor zones (the new generation uses a replication algorithm to collect).
Test code (more than 3M directly allocated into the old age):
/***-verbose:gc-xms20m-xmx20m-xmn10m-xx:+printgcdetails-xx:survivorratio=8 *-xx:pretenuresizethreadshold= 3145728*/ Public classTestpretenuresizethreadshold {Private Static Final int_1MB = 1024 * 1024; Public Static voidMain (string[] args) {byte[] application =New byte[4 *_1MB]; }}
Test results:
Heap defNewGeneration Total 9216K, used 1327K [0x04600000, 0x05000000, 0x05000000) Eden Space 8192K,16% used [0x04600000, 0x0474bf18, 0x04e00000) from Space 1024K,0% used [0x04e00000, 0x04e00000, 0x04f00000) to space 1024K,0% used [0x04f00000, 0x04f00000, 0x05000000) tenured generation total 10240K, used 4096K [0x05000000, 0x05a00000, 0x05a00000) The space 10240K, 40% used[0x05000000, 0x05400010, 0x05400200, 0x05a00000) Compacting Perm gen Total 12288K, used 1670K [0x05a00000, 0x06600000, 0x09a00000) The space 12288K,13% used [0x05a00000, 0x05ba1a50, 0X05BA1C00, 0x06600000)
Iv. long-term survival of the object into the old age
The virtual machine defines an age counter for each object, and if the object survives after Eden is born and passes the first minor GC and can be accommodated by survivor, the object age is incremented by 1. Objects in the Survivor area each time minor GC, the age is added 1. When the age exceeds a certain threshold (the default is 15), it enters the old age. Thresholds can be set by-xx:maxtenuringthreshold.
Test code:
/***-verbose:gc-xms20m-xmx20m-xmn10m-xx:+printgcdetails-xx:survivorratio=8 *-XX:MAXTENURINGTHRESHOLD=1-XX:+PRI Nttenuringdistribution*/ Public classTesttenuringthreshold {Private Static Final int_1MB = 1024 * 1024; Public Static voidMain (string[] args) {byte[] allocation1,allocation2,allocation3; Allocation1=New byte[_1MB/4]; Allocation2=New byte[4 *_1MB]; Allocation3=New byte[4 *_1MB]; Allocation3=NULL; Allocation3=New byte[4 *_1MB]; }}
Test results:
[gc[defnewdesired survivor Size524288 bytes,NewThreshold 1 (max 1)-Age 1:768272 Bytes, 768272total:5515k->750k (9216K), 0.0050436 secs] 5515k->4846k (19456K), 0.0051715 secs] [times:user=0.00 sys=0.00, real=0.01secs] [Gc[defnewdesired survivor Size524288 bytes,NewThreshold 1 (max 1)-Age 1:256 Bytes, 256total:5094k->0k (9216K), 0.0015457 secs] 9190k->4845k (19456K), 0.0016256 secs] [times:user=0.00 sys=0.00, real=0.00secs] Heap defNewGeneration Total 9216K, used 4178K [0x04400000, 0x04e00000, 0x04e00000) Eden Space 8192K,51% used [0x04400000, 0x04814828, 0x04c00000) from Space 1024K,0% used [0x04c00000, 0x04c00100, 0x04d00000) to space 1024K,0% used [0x04d00000, 0x04d00000, 0x04e00000) tenured generation total 10240K, used 4845K [0x04e00000, 0x05800000, 0x05800000) The space 10240K,47% used [0x04e00000, 0x052bb6e8, 0x052bb800, 0x05800000) Compacting Perm gen Total 12288K, used 1672K [0x05800000, 0x06400000, 0x09800000) The space 12288K,13% used [0x05800000, 0x059a2248, 0x059a2400, 0x06400000)
Note: The minor GC occurred two times, the first time when assigning to Allocation3 will appear a minor GC, the survivor region can not accommodate allocation2, but to accommodate Allocation1, So Allocation1 will enter the survivor area and age at 1, reaching the threshold, which will be promoted to the old age in the next GC, while Allocation2 will enter the old age through the guarantee mechanism. The second occurrence of GC is the second time to allocate space for Allocation3, at this time, the age of Allocation1 plus 1, promotion to the old age, this GC can also clear out the original Allocation3 occupy 4MB space, will allocation3 allocated in the Eden area. Therefore, the final result is Allocation1, allocation2 in the old age, Allocation3 in the Eden area.
Five, dynamic object age judgement
The virtual machine does not require that the object must reach the age threshold before it can enter the old era. When the sum of all the same age objects in the survivor space is greater than half the size of survivor space, objects older than or equal to that age can enter the old age directly.
Test code:
/***-verbose:gc-xms20m-xmx20m-xmn10m-xx:+printgcdetails-xx:survivorratio=8 *-XX:MAXTENURINGTHRESHOLD=15-XX:+PR Inttenuringdistribution*/ Public classTestTenuringThreshold2 {Private Static Final int_1MB = 1024 * 1024; Public Static voidMain (string[] args) {byte[] allocation1,allocation2,allocation3,allocation4; Allocation1=New byte[_1MB/4]; //Application1+application2 is more than half survivor spaceAllocation2 =New byte[_1MB/4]; Allocation3=New byte[4 *_1MB]; Allocation4=New byte[4 *_1MB]; Allocation4=NULL; Allocation4=New byte[4 *_1MB]; }}
Test results:
[gc[defnewdesired survivor Size524288 bytes,NewThreshold 1 (Max 15)-Age 1:1030592 Bytes, 1030592total:5771k->1006k (9216K), 0.0042280 secs] 5771k->5102k (19456K), 0.0043710 secs] [times:user=0.00 sys=0.00, real=0.00secs] [Gc[defnewdesired survivor Size524288 bytes,NewThreshold (Max 15)-Age 1:256 Bytes, 256total:5350k->0k (9216K), 0.0016450 secs] 9446k->5102k (19456K), 0.0017286 secs] [times:user=0.00 sys=0.00, real=0.00secs] Heap defNewGeneration Total 9216K, used 4178K [0x04400000, 0x04e00000, 0x04e00000) Eden Space 8192K,51% used [0x04400000, 0x04814828, 0x04c00000) from Space 1024K,0% used [0x04c00000, 0x04c00100, 0x04d00000) to space 1024K,0% used [0x04d00000, 0x04d00000, 0x04e00000) tenured generation total 10240K, used 5101K [0x04e00000, 0x05800000, 0x05800000) The space 10240K,49% used [0x04e00000, 0x052fb798, 0x052fb800, 0x05800000) Compacting Perm gen Total 12288K, used 1672K [0x05800000, 0x06400000, 0x09800000) The space 12288K,13% used [0x05800000, 0x059a2260, 0x059a2400, 0x06400000)
Results: two times minor GC occurred, the first time in allocating memory to Allocation4, at this time Allocation1, Allocation2 will enter the Survivor Zone, and allocation3 through the guarantee mechanism will enter the old age. The second occurrence in allocating memory to Allocation4, at this time, the Survivor area Allocation1, Allocation2 reached the survivor area capacity of half, will enter the old age, This GC can clean up the original 4MB space of Allocation4 and assign Allocation4 to the Eden area. Finally, Allocation1, Allocation2, Allocation3 in the old age, Allocation4 in the Eden District.
VI. Allocation of space guarantees
Before the minor GC occurs, the virtual opportunity first checks whether the largest contiguous space in the old age is greater than the sum of all object sizes in the Cenozoic. If this is true, the minor GC is safe. Otherwise, the virtual machine needs to look at the value of the handlepromotionfailure to see if the guarantee fails to run, and if so, the virtual machine continues to check that the largest available contiguous space in the old age is greater than the average size of the previous promotion to the old age object, and if it is greater than, attempt to minor GC , if less than or handlepromotionfailure set does not run the adventure, then this time will be changed to a full GC, the above is the JDK Update 24 before the policy, after the policy changed, As long as the continuous space of the old age is greater than the total size of the new generation of objects or the average size of successive promotions will be minor GC, otherwise full GC will be performed.
Risk is that after a minor GC after a large number of objects survive, and the Cenozoic survivor area is very small, can not put these large number of surviving objects, so the old age to allocate security, the survivor area cannot accommodate the object directly into the old age.
The specific flowchart is as follows:
In-depth understanding of Java Virtual Machines notes (6) Memory allocation and recovery strategy