该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2011-01-15
请问LZ啥时候写第三章呢?
|
|
返回顶楼 | |
发表时间:2011-01-28
这种好贴,一般会收藏,谢谢
|
|
返回顶楼 | |
发表时间:2011-02-10
谢谢LZ 蛮受用的
期待JVM内存管理:深入JVM内存异常分析与调优 |
|
返回顶楼 | |
发表时间: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%,存放的是些什么呢? |
|
返回顶楼 | |
发表时间:2011-02-25
学习中,期待楼主更新
|
|
返回顶楼 | |
发表时间:2011-06-10
可惜木有g1
|
|
返回顶楼 | |
发表时间:2011-10-27
期待楼主第三章
|
|
返回顶楼 | |