对象优先在Eden分配
大多数情况下,对象在新生代Eden
区中分配。当Eden区没有足够空间进行分配时,虚拟机将发起一次Minor GC
。
HotSpot虚拟机提供了-XX:+PrintGCDetails
这个收集器日志参数,告诉虚拟机在发生垃圾收集行为时打印内存回收日志,并且在进程退出的时候输出当前的内存各区域分配情况。
例子
在代码清单3-7的testAllocation()
方法中,尝试分配三个2MB大小和一个4MB大小的对象,在运行时通过-Xms20M、-Xmx20M、-Xmn10M这三个参数限制了Java堆大小为20MB,不可扩展,其中
10MB分配给新生代,剩下的10MB分配给老年代。-XX:Survivor-Ratio=8
决定了新生代中Eden区与一个Survivor区的空间比例是8∶1,从输出的结果也清晰地看到“eden space 8192K(8M)、from space 1024K(1M)、tospace 1024K(1M)”的信息,新生代总可用空间为9216KB(9M)(Eden区+1个Survivor区的总容量)。
新生代总大小为10M,2个Survivor各为1M,Eden区8M,那么可用的新生代空间=1个Survivor+Eden区=9M,另一个Survivor为不可用区(用来当粘贴板了)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21/** * VM参数:-XX:+UseSerialGC * @author zzm */ public class TestSerialGCAllocation { private static final int _1MB = 1024 * 1024; /** * VM参数:-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 */ public static void testAllocation() { 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]; // 出现一次Minor GC } public static void main(String[] args) { testAllocation(); }
注:
-Xms20M 设置初始内存
-Xmx20M 设置最大内存
-Xmn10M 设置新生代内存
-verbose:gc 控制台输出精简的GC情况,是 -XX:+PrintGC的别名,意义不大,当日志详细参数时,会被覆盖。
-XX:+PrintGCDetails 在控制台输出详细的
-XX:+UseSerialGC 使用serial gc收集器
-XX:SurvivorRatio=8 设置新生代中Eden区与一个Survivor区的空间,由于Survivor实际存在2个,因此最终是8:1:1
JDK1.6执行
JDK1.6执行结果,与书上一致:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21[GC [DefNew: 6651K->148K(9216K), 0.0061143 secs] 6651K->6292K(19456K), 0.0061421 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] Heap def new generation total 9216K, used 4490K [0x03810000, 0x04210000, 0x04210000) eden space 8192K, 53% used [0x03810000, 0x03c4d7f8, 0x04010000) from space 1024K, 14% used [0x04110000, 0x04135348, 0x04210000) to space 1024K, 0% used [0x04010000, 0x04010000, 0x04110000) tenured generation total 10240K, used 6144K [0x04210000, 0x04c10000, 0x04c10000) the space 10240K, 60% used [0x04210000, 0x04810030, 0x04810200, 0x04c10000) compacting perm gen total 12288K, used 2103K [0x04c10000, 0x05810000, 0x08c10000) the space 12288K, 17% used [0x04c10000, 0x04e1dec0, 0x04e1e000, 0x05810000) No shared spaces configured.
其含义大概如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29[GC 表示Young GC [DefNew: 单线程Serial年轻代GC 6651K-> 年轻代垃圾回收前的大小 148K 年轻代回收后的大小 (9216K), 年轻代可用空间总大小 9M 0.0061143 secs] 回收花费的时间 6651K-> 整个堆回收前的大小 6292K 整个堆回收后的大小 几乎未回收到什么内存 (19456K), 堆可用空间总大小 19M 0.0061421 secs] [Times: user=0.00 用户耗时 sys=0.00, 系统耗时 real=0.01 secs] 实际耗时
分析原因:
执行testAllocation()中分配allocation4对象的语句时会发生一次Minor GC,这次回收的结果是新生代6651KB变为148KB,而总内存占用量则几乎没有减少(因为allocation1、2、3三个对象都是存活
的,虚拟机几乎没有找到可回收的对象)。
产生这次垃圾收集的原因是为allocation4分配内存时,发现il
Eden已经被占用了(6MB+148K),剩余空间已不足以分配allocation4所需的4MB内存
,因此发生Minor GC
。垃圾收集期间虚拟机又发现已有的三个2MB大小的对象全部无法放入Survivor
空间(Survivor
空间只有1MB大小),所以只好通过分配担保机制提前转移到老年代去。
这次收集结束后,4MB的allocation4对象顺利分配在Eden中。因此程序执行完的结果是Eden占用4MB(被allocation4占用),Survivor空闲,老年代被占用6MB(被allocation1、2、3占用)。通过GC日志可以证实这一点。
148K是什么内存?是我反推的,gc后Survivor遗留148K
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40Heap def new generation //新生代信息 total 9216K, //总可用大小 used 4490K //已占用大小 [0x03810000, 0x04210000, 0x04210000) eden space 8192K, //eden 区使用量 53% used //使用率 [0x03810000, 0x03c4d7f8, 0x04010000) from space 1024K, 14% used //其中一个Survivor区 [0x04110000, 0x04135348, 0x04210000) to space 1024K, 0% used //另一个Survivor区 [0x04010000, 0x04010000, 0x04110000) tenured generation //老年代信息 total 10240K, //总可用大小10M used 6144K //已占用的大小 6M,刚好是allocation1、2、3三个对象 [0x04210000, 0x04c10000, 0x04c10000) the space 10240K, //总大小10M 60% used //使用率60%=6M/10M [0x04210000, 0x04810030, 0x04810200, 0x04c10000) compacting perm gen //永久代,可以理解成方法区,非堆内存 total 12288K, used 2103K [0x04b60000, 0x05760000, 0x08b60000) the space 12288K, 17% used [0x04b60000, 0x04d6dec0, 0x04d6e000, 0x05760000)
注意:需要执行2次,才能稳定的结果和书上一致,否则为下面,不知道具体原因:
1
2[GC [DefNew: 6487K->147K(9216K), 0.0136419 secs] 6487K->6291K(19456K), 0.0136898 secs] [Times: user=0.00 sys=0.02, real=0.01 secs]
JDK1.7执行
JDK1.7执行结果:
1
2[GC[DefNew: 7128K->445K(9216K), 0.0068331 secs] 7128K->6589K(19456K), 0.0068977 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
可以看出初始内存7128K占用变多了一点
参考:
【GC分析】Java GC日志查看
GC日志详情分析
Java GC日志查看,GC日志时间分析 *
最后
以上就是超级母鸡最近收集整理的关于《深入理解java虚拟机v3》对象优先在Eden分配 > 代码单3-7 新生代Minor GC的全部内容,更多相关《深入理解java虚拟机v3》对象优先在Eden分配内容请搜索靠谱客的其他文章。
发表评论 取消回复