Java虚拟机学习

2. 大对象直接进入老年代

所谓大对象,就是指需要大量连续内存空间的Java对象,最典型的大对象就是那种很长的字符串及数组(byte[]数组就是典型的大对象)。大对象对虚拟机的内存分配来说就是一个坏消息(更加坏的情况就是遇到一群朝生夕死的短命大对象,写程序时应该避免),经常出现大对象容易导致内存还有不少空间时就提前触发垃圾收集以获取足够的连续空间来安置大对象。
虚拟机提供了一个-XX:PretenureSizeThreshold参数,令大于这个设置值的对象直接进入老年代中分配。这样避免在Eden区及两个Survivor区之间发生大量的内存拷贝。
/** * -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+PrintGCDetails * -XX:PretenureSizeThreshold=3145728 */
public static void testPretenureSizeThreshold(){
byte[] allocation;
allocation = new byte[4*_1MB];
}

运行结果:
Heap def new generation total 9216K, used 671K [0x046a0000, 0x050a0000, 0x050a0000) eden space 8192K, 8% used [0x046a0000, 0x04747e88, 0x04ea0000) from space 1024K, 0% used [0x04ea0000, 0x04ea0000, 0x04fa0000) to space 1024K, 0% used [0x04fa0000, 0x04fa0000, 0x050a0000) tenured generation total 10240K, used 4096K [0x050a0000, 0x05aa0000, 0x05aa0000) the space 10240K, 40% used [0x050a0000, 0x054a0010, 0x054a0200, 0x05aa0000) compacting perm gen total 12288K, used 2130K [0x05aa0000, 0x066a0000, 0x09aa0000) the space 12288K, 17% used [0x05aa0000, 0x05cb49b8, 0x05cb4a00, 0x066a0000)No shared spaces configured.


我们可以看到Eden空间几乎没有被利用,,而老年代10MB空间被使用40%,也就是4MB的allocation对象被直接分配到老年代中,这是因为PretenureSizeThreshold被设置为3MB,因此超过3MB的对象都会直接在老年代中进行分配。

楼主 collmakkaksm  发布于 2016-05-09 15:29:00 +0800 CST  
长期存活的对象将进入老年代

虚拟机采用了分代收集的思想来管理内存,那内存回收时就必须识别哪些对象应该放在新生代,哪些对象应该放在老年代中。为了做到这点,虚拟机给每个对象定义了一个对象年龄(Age)计数器。如果对象在Eden出生并经过第一次Minor GC后仍然存活,并且能被Survivor容纳的话,将被移动到Survivor空间中,并将对象年龄设为1。对象在Survivor区中没熬过一次Minor GC,年龄就增加1,当它的年龄增加到一定程度(默认为15)时,就会被晋升到老年代中。对象晋升到老年代的年龄阀值,可以通过参数-XX:MaxTenuringThreshold来设置。
/** * VM Args : -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+PrintGCDetails * -XX:MaxTenuringThreshold=1 */
public static void testTenuringThreshold(){
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]; }

楼主 collmakkaksm  发布于 2016-05-09 15:56:00 +0800 CST  
当-XX:MaxTenuringThreshold=1时,运行结果:
[GC [DefNewDesired survivor size 524288 bytes, new threshold 1 (max 1)- age 1: 420200 bytes, 420200 total: 4859K->410K(9216K), 0.0042347 secs] 4859K->4506K(19456K), 0.0042967 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] [GC [DefNewDesired survivor size 524288 bytes, new threshold 1 (max 1): 4506K->0K(9216K), 0.0008751 secs] 8602K->4506K(19456K), 0.0009284 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] Heap def new generation total 9216K, used 4178K [0x04540000, 0x04f40000, 0x04f40000) eden space 8192K, 51% used [0x04540000, 0x04954830, 0x04d40000) from space 1024K, 0% used [0x04d40000, 0x04d40000, 0x04e40000) to space 1024K, 0% used [0x04e40000, 0x04e40000, 0x04f40000) tenured generation total 10240K, used 4506K [0x04f40000, 0x05940000, 0x05940000) the space 10240K, 44% used [0x04f40000, 0x053a6978, 0x053a6a00, 0x05940000) compacting perm gen total 12288K, used 2137K [0x05940000, 0x06540000, 0x09940000) the space 12288K, 17% used [0x05940000, 0x05b56580, 0x05b56600, 0x06540000)No shared spaces configured.
当-XX:MaxTenuringThreshold=15时,运行结果:
[GC [DefNewDesired survivor size 524288 bytes, new threshold 15 (max 15)- age 1: 420200 bytes, 420200 total: 4859K->410K(9216K), 0.0069588 secs] 4859K->4506K(19456K), 0.0070540 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] [GC [DefNewDesired survivor size 524288 bytes, new threshold 15 (max 15)- age 2: 420056 bytes, 420056 total: 4506K->410K(9216K), 0.0012592 secs] 8602K->4506K(19456K), 0.0013433 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] Heap def new generation total 9216K, used 4588K [0x044e0000, 0x04ee0000, 0x04ee0000) eden space 8192K, 51% used [0x044e0000, 0x048f4830, 0x04ce0000) from space 1024K, 40% used [0x04ce0000, 0x04d468d8, 0x04de0000) to space 1024K, 0% used [0x04de0000, 0x04de0000, 0x04ee0000) tenured generation total 10240K, used 4096K [0x04ee0000, 0x058e0000, 0x058e0000) the space 10240K, 40% used [0x04ee0000, 0x052e0010, 0x052e0200, 0x058e0000) compacting perm gen total 12288K, used 2137K [0x058e0000, 0x064e0000, 0x098e0000) the space 12288K, 17% used [0x058e0000, 0x05af6580, 0x05af6600, 0x064e0000)No shared spaces configured.
此方法中allocation1对象需要256KB的内存空间,Survivor空间可以容纳MaxTenuringThreshold=1时,allocation1对象在第二次GC发生时进入老年代,新生代已使用的内存GC后会非常干净地变成0KB。而MaxTenuringThreshold=15时,第二次GC发生后,allocation1对象则还留在新生代Survivor空间,这时候新生代仍然有410KB的空间被占用。

楼主 collmakkaksm  发布于 2016-05-09 15:58:00 +0800 CST  
动态对象年龄判定
为了能更好地适应不同程序的内存状况,虚拟机并不总是要求对象的年龄必须达到MaxTenuringThreshold才能晋升到老年代,如果在Survivor空间中相同年龄所有对象大小的综合大于Survivor空间的一半,年龄大于或等于该年龄的对象就可以直接进入老年代,无须等到MaxTenuringThreshold中要求的年龄。

楼主 collmakkaksm  发布于 2016-05-09 15:58:00 +0800 CST  
空间分配担保
当发生Minor GC时,虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代的剩余空间大小,如果大于,则改为直接进行一次Full GC。如果小于,则查看HandlePromotionFailure设置是否允许担保失败;如果允许,那只会进行Minor GC;如果不允许,则也要改为进行一次Full GC。
新生代使用复制收集算法,但为了内存利用率,值使用其中一个Survivor空间来作为轮换备份,因此当出现大量对象在Minor GC后仍然存活的情况时(最极端就是内存回收后新生代中所有对象都存活),就需要老年代进行分配担保,让Survivor无法容纳的对象直接进入老年代。与生活中的贷款担保类似,老年代要进行这样的担保,前提是老年代本身还有容纳这些对象的剩余空间,一共有多少对象会活下去,在实际完成内存回收之前是无法明确知道的,所以只好取之前每一次回收晋升到老年代对象容量的平均大小值作为经验,与老年代的剩余空间进行对比,决定是否进行Full GC来让老年代腾出更多空间。
取平均值进行比较其实仍然是一种动态概率的手段,也就是说如果某次Minor GC存活后的对象突增,远远高于平均值时,依然会导致担保失败(Handle Promotion Failure)。如果出现HandlePromotionFailure失败,那就只好在失败后重新发起一次Full GC。虽然担保失败时绕的圈子是最大的,但大部分情况下都还是会将HandlePromotionFailure开关打开,避免Full GC过于频繁。

楼主 collmakkaksm  发布于 2016-05-09 15:59:00 +0800 CST  
http://pan.baidu.com/s/1nvMVYit
深入理解Java虚拟机分享,可以看看

楼主 collmakkaksm  发布于 2016-05-09 16:02:00 +0800 CST  
空间分配担保
当发生Minor GC时,虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代的剩余空间大小,如果大于,则改为直接进行一次Full GC。如果小于,则查看HandlePromotionFailure设置是否允许担保失败;如果允许,那只会进行Minor GC;如果不允许,则也要改为进行一次Full GC。
新生代使用复制收集算法,但为了内存利用率,值使用其中一个Survivor空间来作为轮换备份,因此当出现大量对象在Minor GC后仍然存活的情况时(最极端就是内存回收后新生代中所有对象都存活),就需要老年代进行分配担保,让Survivor无法容纳的对象直接进入老年代。与生活中的贷款担保类似,老年代要进行这样的担保,前提是老年代本身还有容纳这些对象的剩余空间,一共有多少对象会活下去,在实际完成内存回收之前是无法明确知道的,所以只好取之前每一次回收晋升到老年代对象容量的平均大小值作为经验,与老年代的剩余空间进行对比,决定是否进行Full GC来让老年代腾出更多空间。
取平均值进行比较其实仍然是一种动态概率的手段,也就是说如果某次Minor GC存活后的对象突增,远远高于平均值时,依然会导致担保失败(Handle Promotion Failure)。如果出现HandlePromotionFailure失败,那就只好在失败后重新发起一次Full GC。虽然担保失败时绕的圈子是最大的,但大部分情况下都还是会将HandlePromotionFailure开关打开,避免Full GC过于频繁。

楼主 collmakkaksm  发布于 2016-05-09 16:08:00 +0800 CST  
有什么疑问可以加我QQ:994546508

楼主 collmakkaksm  发布于 2017-11-08 14:40:00 +0800 CST  
有问题可以加我qq:994546508

楼主 collmakkaksm  发布于 2020-06-15 08:46:00 +0800 CST  

楼主:collmakkaksm

字数:12910

发表时间:2016-04-28 01:51:00 +0800 CST

更新时间:2021-02-23 17:47:55 +0800 CST

评论数:232条评论

帖子来源:百度贴吧  访问原帖

 

热门帖子

随机列表

大家在看