论坛首页 Java企业应用论坛

JVM内存管理:深入垃圾收集器与内存分配策略

浏览 43736 次
该帖已经被评为精华帖
作者 正文
   发表时间:2011-01-15  
请问LZ啥时候写第三章呢?
0 请登录后投票
   发表时间:2011-01-28  
这种好贴,一般会收藏,谢谢
0 请登录后投票
   发表时间:2011-02-10  
谢谢LZ 蛮受用的
期待JVM内存管理:深入JVM内存异常分析与调优
0 请登录后投票
   发表时间:2011-02-11  
引用

规则一:通常情况下,对象在eden中分配。当eden无法分配时,触发一次Minor GC。

  执行testAllocation()方法后输出了GC日志以及内存分配状况。-Xms20M -Xmx20M -Xmn10M这3个参数确定了Java堆大小为20M,不可扩展,其中10M分配给新生代,剩下的10M即为老年代。-XX:SurvivorRatio=8决定了新生代中eden与survivor的空间比例是1:8,从输出的结果也清晰的看到“eden space 8192K、from space 1024K、to space 1024K”的信息,新生代总可用空间为9216K(eden+1个survivor)。

  我们也注意到在执行testAllocation()时出现了一次Minor GC,GC的结果是新生代6651K变为148K,而总占用内存则几乎没有减少(因为几乎没有可回收的对象)。这次GC是发生的原因是为allocation4分配内存的时候,eden已经被占用了6M,剩余空间已不足分配allocation4所需的4M内存,因此发生Minor GC。GC期间虚拟机发现已有的3个2M大小的对象全部无法放入survivor空间(survivor空间只有1M大小),所以直接转移到老年代去。GC后4M的allocation4对象分配在eden中。

清单2:testAllocation()方法输出结果

[GC [DefNew: 6651K->148K(9216K), 0.0070106 secs] 6651K->6292K(19456K), 0.0070426 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
def new generation   total 9216K, used 4326K [0x029d0000, 0x033d0000, 0x033d0000)
  eden space 8192K,  51% used [0x029d0000, 0x02de4828, 0x031d0000)
  from space 1024K,  14% used [0x032d0000, 0x032f5370, 0x033d0000)
  to   space 1024K,   0% used [0x031d0000, 0x031d0000, 0x032d0000)
tenured generation   total 10240K, used 6144K [0x033d0000, 0x03dd0000, 0x03dd0000)
   the space 10240K,  60% used [0x033d0000, 0x039d0030, 0x039d0200, 0x03dd0000)
compacting perm gen  total 12288K, used 2114K [0x03dd0000, 0x049d0000, 0x07dd0000)
   the space 12288K,  17% used [0x03dd0000, 0x03fe0998, 0x03fe0a00, 0x049d0000)
No shared spaces configured.

请问为什么from space里面还占用了14%,存放的是些什么呢?
0 请登录后投票
   发表时间:2011-02-25  
学习中,期待楼主更新
0 请登录后投票
   发表时间:2011-06-10  
可惜木有g1
0 请登录后投票
   发表时间:2011-10-27  
期待楼主第三章
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics