Java Heap Memory

Heap Memory

The heap in Java is the largest memory space managed by the JVM and is primarily used to store instance objects of various classes.
In Java, the heap is divided into two different areas: the New Generation (young), the old generation (older). The New Generation (young) is divided into three regions: Eden, from Survivor, to Survivor.
The purpose of this partitioning is to enable the JVM to better manage the objects in the heap memory, including the allocation of memory and recycling.
The memory model of the heap is roughly:



You can see: heap size = new Generation + old age. The size of the heap can be specified by parameter –xms,-xmx.
I am using JDK1.6, the following JVM default values are subject to this version.
By default, the ratio of the new generation (young) to the older (old) is 1:2 (this value can be specified by the parameter –xx:newratio), that is, the heap space size of the Cenozoic (young) = 1/3.
The old age = 2/3 heap space size. Among them, the new generation (young) is subdivided into Eden and two Survivor regions, the two Survivor regions are named from and to, respectively, as a distinction.
By default, Edem:from:to = 8:1: 1 (can be set by parameter –xx:survivorratio), i.e., the Cenozoic space size of Eden = 8/10, from = to = 1/10 for the Cenozoic space size.
The JVM only uses Eden and one of its Survivor areas to serve objects at a time, so whenever there is always a Survivor area that is idle.
As a result, the new generation actually available memory space is 9/10 (i.e. 90%) of the Cenozoic space.

GC Heap

The heap in Java is also the primary area where GC collects garbage. The GC is divided into two types: Minor GC, full GC (or Major GC).
Minor GC is a garbage collection action occurring in the Cenozoic, using a replication algorithm.
The new generation is almost everywhere where all Java objects are born, that is, the memory that the Java object applies to and where it is stored. Most of the objects in Java are usually not long-lived, with the nature of being born and going out.
When an object is judged to be "dead," the GC has the responsibility to reclaim the memory space of that part of the object. The Cenozoic is a frequent area where GC collects garbage.
When the object is in Eden (including a Survivor area, which is assumed to be from the region) after birth, after a Minor GC, if the object is still alive and can be accommodated by another Survivor area
(This is assumed to be from the from zone, where the to zone, that is, the to zone has enough memory space to store the objects that exist in the Eden and from zones), the copy algorithm is used to copy these still surviving objects into another Survivor area (i.e. to region) , then cleans up the used Eden and Survivor areas (that is, the from zone), and sets the age of these objects to 1, after which the object's age + 1 per Minor GC in the Survivor area, when the object's age reaches a certain value (the default is 15 years old, can be set by parameter-xx:maxtenuringthreshold), these objects will become the old age.
But this is not certain, for some larger objects (that is, the need to allocate a larger contiguous memory space) is directly into the old age.
The full GC is a garbage collection action that takes place in the old age, using the tag-purge algorithm.
In the real life, people in the old age usually "die early" than the new generation of people. The old age in the heap memory is different from this, and the objects in the old age are almost all in the Survivor region, they are not so easy to "die". As a result, the number of full GC occurrences will not be as frequent as Minor GC, and it will take longer to do a full GC than one Minor GC at a time.
In addition, the tag-purge algorithm generates a lot of memory fragmentation (i.e., discontinuous memory space) when it collects garbage, and then, when it needs to allocate memory space for large objects, it triggers a GC collection action in advance if sufficient contiguous memory space cannot be found.

GC Logpublic static void Main (string[] args) {
Object obj = new Object ();
System.GC ();
System.out.println ();
obj = new Object ();
obj = new Object ();
System.GC ();
System.out.println ();
}

Set the JVM parameter to-xx:+printgcdetails, which allows the console to display GC-related log information, execute the above code, and the following is the result of one of the executions.





The full GC information is similar to the information in the Minor GC, where it is not a single painting.
From the full GC information, the new generation of usable memory size is about 18M, then the new generation is actually allocated a memory space of about 20M (why 20M?). Please continue to see below ...). The memory size of the old age is approximately 42M, and the available memory size of the heap is approximately 60M. Can be calculated: 18432K (Cenozoic free space) + 42112K (old age space) = 60544K (free space on heap)
The new generation accounts for about 1/3 of the heap size, and the old age accounts for about 2/3 of the heap size. It can be seen that the GC is more optimistic about the recovery of the new generation, and the recovery of the old and the method areas is not obvious or less than the new generation.
And here the full GC takes 22.89 times times as much time as the Minor GC.

JVM parameter Options

JVM Configurable parameter options can be found in the information given on the official Oracle website: http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
Here are just a few of the common and easy-to-master configuration options:

-xms	The initial heap size. such as:-xms256m
-xmx	The maximum heap size. such as:-xmx512m
-xmn	Cenozoic size. Usually 1/3 or 1/4 of XMX. New generation = Eden + 2 Survivor space. Actual free space = Eden + 1 Survivor, or 90%
-xss	jdk1.5+ each thread stack size is 1M, generally, if the stack is not very deep, 1M is absolutely enough.
-xx:newratio	The new generation and the old age ratio, such as –xx:newratio=2, the Cenozoic accounted for the entire heap space 1/3, the old age accounted for 2/3
-xx:survivorratio	The ratio of Eden to Survivor in the Cenozoic. The default value is 8. That is, Eden accounts for 8/10 of the Cenozoic space, and another two Survivor 1/10.
-xx:permsize	Initial size of the permanent generation (method area)
-xx:maxpermsize	Maximum value for a permanent generation (method area)
-xx:+printgcdetails	Print GC Information
-xx:+heapdumponoutofmemoryerror	Causes the virtual machine to dump the current memory heap dump snapshot in case of a memory overflow for analysis

1/**
2-xms60m
3-xmx60m
4-xmn20m
5-xx:newratio=2 (If Xms = Xmx, and the XMN is set, the configuration is not required)
6-xx:survivorratio=8
7-xx:permsize=30m
8-xx:maxpermsize=30m
9-xx:+printgcdetails
10*/
11PublicStaticvoid Main (string[] args) {
12New Test (). Dotest ();
13}
14
15Publicvoid Dotest () {
Integer M =New Integer (1024 * 1024 * 1);//Unit, trillion (M)
17 byte[] bytes =NewByte[1 * M];//Request a 1M size memory space
18bytes =Null//Unlink a reference chain
19System.GC ();//Notify GC to collect garbage
20System.out.println ();
bytes =new byte[1 * m];  // re-apply  1M  size memory space
Span style= "color: #008080;" >22     bytes =  new byte[1 * m];  // re-apply  1M  size memory space
Span style= "color: #008080;" >23     system.gc ();
24     system.out.println ();
25 }

Set the JVM-related parameter items according to the information commented in the code above, and execute the program, the following is the result of completing the console printing at one time:

[GC [psyounggen:1351k, 288K (18432K)] 1351K, 288K (59392K), 0.0012389 secs] [times:user=0.00 sys=0.00, real=0.00 secs]
[Full GC (System) [psyounggen:288k, 0K (18432K)] [psoldgen:0k, 160K (40960K)] 288K, 160K (59392 K) [pspermgen:2942k, 2942K (30720K)], 0.0057649 secs] [times:user=0.00 sys=0.00, real=0.01 secs]

[GC [psyounggen:2703k, 1056K (18432K)] 2863K, 1216K (59392K), 0.0008206 secs] [times:user=0.00 sys=0.00, real=0.00 secs]
[Full GC (System) [psyounggen:1056k, 0K (18432K)] [psoldgen:160k, 1184K (40960K)] 1216K--1184K (59392K) [pspermgen:2951k, 2951K (30720K)], 0.0052445 secs] [times:user=0.02 sys=0.00, real=0.01 secs]

Heap
Psyounggen total 18432K, used 327K [0x00000000fec00000, 0x0000000100000000, 0x0000000100000000)
Eden Space 16384K, 2% used [0x00000000fec00000,0x00000000fec51f58,0x00000000ffc00000)
From space 2048K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x0000000100000000)
To space 2048K, 0% used [0x00000000ffc00000,0x00000000ffc00000,0x00000000ffe00000)
Psoldgen total 40960K, used 1184K [0x00000000fc400000, 0x00000000fec00000, 0x00000000fec00000)
Object Space 40960K, 2% used [0x00000000fc400000,0x00000000fc5281f8,0x00000000fec00000)
Pspermgen total 30720K, used 2959K [0x00000000fa600000, 0x00000000fc400000, 0x00000000fc400000)
Object Space 30720K, 9% used [0x00000000fa600000,0x00000000fa8e3ce0,0x00000000fc400000)

From the printing results can be seen, the new generation of memory space in the heap is 18432K (about 18M), Eden's memory space is 16384K (about 16M), from/to survivor memory space is 2048K (about 2M).
The Xmn configured here is 20M, which specifies the new generation of memory space for 20M, but from the printed heap information, the new generation is only 18M it? Where did the other 2M go?
Don't worry, it's like that. New generation = Eden + from + to = 2 + 2 = 20M, the new generation of memory space is indeed allocated according to the XMN parameter.
and Survivorratio = 8 is specified here, so the Cenozoic space of Eden = 8/10 = 8/10 * = 16M. Cenozoic space from = to = 1/10 = 1/10 * = 2M.
The new generation of total 18432K in the heap information comes in this way: Eden + 1 survivor = 16384K + 2048K = 18432K, which is about 18M.
Because the JVM uses only the new generation of Eden and a survivor, the actual amount of available memory space for the new generation is 90% of the specified size.
As a result, it is known that the new generation of memory space refers to the total amount of memory space available to the Cenozoic, rather than the entire Cenozoic space.
In addition, we can see that the memory space of the old age is 40960K (about 40M), heap size = Cenozoic + old age. So here, the old age = heap Size-Cenozoic = 60-20 = 40M.
Finally, PermSize = 30m,permgen is also specified as the permanent generation (method area), and it also has a name called non-heap, which is used primarily to store class file information, constants, static variables, etc. loaded by the JVM.

Take a nap and go back to the Dotest () method, you can see that the code in the 17th, 21, 22, respectively, the three rows of a 1M size of memory space, and in the 19 and 23 of the two lines, respectively, explicitly called System.GC (). The information printed from the console, each time the System.GC (), is the first Minor GC, and then the full GC.
Minor GC Collection analysis triggered by line 19th:
From information psyounggen:1351k-288K, you can know that the memory space allocated in the 17th behavior bytes has been reclaimed.
The factor that causes GC to reclaim this 1 m memory space is bytes = null on line 18th; Bytes Null indicates that the 1M size of the previously requested memory space now has no reference variable in use of it,
And in memory it is in a non-reachable state (that is, no reference chain is connected to GC Roots). Then, when the Minor GC occurs, the GC will reclaim this portion of the memory space.
Full GC collection analysis triggered by line 19th:
When Minor GC, the information displayed psyounggen:1351k-288K, and then look at the full GC in the display of psyounggen:288k-0K, it can be seen that the full GC, the new generation of memory usage into
0K (0K, 0 K, does anyone think it's OK in English? OK. I admitted that when I first saw it, I thought it was English OK, and was deliberately printed on the console 0K and OK to confirm. Finally found that the O in English than the Arabic numerals of 0 to plump and fat some. Now the impression is still more profound. It seems like.. I'm off the topic ~ ~)
Just speaking of full GC, the new generation of memory usage from 288K to 0 K, then this 288K exactly where? Are they all garbage collected by GC? No, of course not. I also deliberately new in the main method, an instance of the test class, where the instance of the test class is a small object, it should be allocated to the new generation of memory, is still calling this instance of the Dotest method, the GC is not possible to reclaim it at this time.
Then look down to the full GC information, will find a very interesting phenomenon, psoldgen:0k, 160K, you can see, the full GC, the old age of memory use from 0 K to 160K, presumably you have guessed what is going on. When the full GC is in progress, the default is to empty the Cenozoic (Younggen) as far as possible, so when System.GC () is adjusted, the surviving objects in the Cenozoic (Younggen) advance into the old age.
Minor GC Collection analysis triggered by line 23rd:
From the information psyounggen:2703k-1056K, you can know that in line 21st, an array of size 1M is recycled by GC. In line 22nd, an array of size 1M is also referenced by the bytes reference variable, so it is temporarily not reclaimed by GC.
Full GC collection analysis triggered by line 23rd:
In Minor GC, information displays psyounggen:1056k, 0K, 1056k,full GC, psyounggen:2703k-I, and psoldgen:160k-118 4 K, it can be known that the New Generation (Younggen) of the surviving objects in advance into the old age.

Java Heap Memory