JVM内存分配

1、对象优先在Eden区分配

大多数情况下,对象在新生代Eden区中分配。当Eden区没有足够空间进行分配时,虚拟机将发起一次Minor GC。

 来看代码例子:

package com.zhuguang.allen;

import com.zhuguang.allen.tools.AddressPrint;

/**
 * @ClassName TestAllocation$
 * @Description TODO
 * @Author
 * @date 2019/6/11 17:13
 * @Version 1.0
 **/
public class TestAllocation {

    //private static final int _1MB=1024*1024 ;
    /**
     *VM参数:-verbose:gc-Xms20M-Xmx20M-Xmn10M-XX:+PrintGCDetails  -XX:+UseSerialGC
     -XX:SurvivorRatio=8
     */
    public static void testAllocation (){
        byte[] allocation1,allocation2,allocation3,allocation4;
        allocation1=new byte[2*1024*1024];
        allocation2=new byte[2*1024*1024];
        allocation3=new byte[2*1024*1024];
        allocation4=new byte[4*1024*1024];//出现一次Minor GC
        try {
            System.out.println("allocation1:"+AddressPrint.addressOf(allocation1));
            System.out.println("allocation2:"+ AddressPrint.addressOf(allocation2));
            System.out.println("allocation3:"+AddressPrint.addressOf(allocation3));
            System.out.println("allocation4:"+AddressPrint.addressOf(allocation4));
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    public static void main(String[] args){
        TestAllocation.testAllocation();
    }
}

执行TestAllocation类,VM参数为:-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC,执行结果为:

发现Eden区空间充足,所有3个对象全在Eden区内分配,由此可见 虚拟机在普通对象分配时,优先在新生代Eden区分配,当空间不足时会在老年代分配。

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

所谓的大对象是指,需要大量连续内存空间的Java对象,最典型的大对象就是那种很长的字符串以及数组(例如:new byte[2*1024*1024]2M数组就是典型的大对象)。大对象对虚拟机的内存分配来说就是一个坏消息(替Java虚拟机抱怨一句,比遇到一个大对象更加坏的消息就是遇到一群“朝生夕灭”的“短命大对象”,写程序的时候应当避免)。经常出现大对象的害处:

1、导致内存有空间,提前进行垃圾回收来放他们

2、如果回收时大对象进行大量的内存复制

执行TestPretenureSizeThreshold方法

package com.zhuguang.allen;


import com.zhuguang.allen.tools.AddressPrint;

/**
 * @ClassName TestPretenureSizeThreshold$
 * @Description TODO
 * @Author 
 * @date 2019/6/18 16:04
 * @Version 1.0
 **/
public class TestPretenureSizeThreshold {
    private static final int _1MB=1024*1024;
    /**
     *VM参数:-verbose:gc-Xms20M-Xmx20M-Xmn10M-XX:+PrintGCDetails-XX:SurvivorRatio=8
     *-XX:PretenureSizeThreshold=3145728
     */
    public static void testPretenureSizeThreshold(){
        byte[] allocation1,allocation2,allocation3,allocation4;
        allocation1 = new byte[_1MB/4];
        allocation2 = new byte[_1MB/2];
        allocation3 = new byte[4*_1MB];
        allocation4 = new byte[4*_1MB];
        try {
            System.out.println("allocation1:"+ AddressPrint.addressOf(allocation1));
            System.out.println("allocation2:"+ AddressPrint.addressOf(allocation2));
            System.out.println("allocation3:"+ AddressPrint.addressOf(allocation3));
            System.out.println("allocation4:"+ AddressPrint.addressOf(allocation4));

        } catch (Exception e) {
            e.printStackTrace();
        }

    }
    public static void main(String[] args){
        TestPretenureSizeThreshold.testPretenureSizeThreshold();
    }
}

输入VM参数,-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:PretenureSizeThreshold=3145728 -XX:+UseSerialGC,-verbose:gc和-XX:+PrintGC是一样的意思。执行结果如下图所示

我们看到老年代使用了40%的空间,虚拟机提供了一个-XX:PretenureSizeThreshold参数,虚拟机提供了一个-XX:PretenureSizeThreshold参数,令大于这个设置值的对象直接在老年代分配。这样做的目的是避免在Eden区及两个Survivor区之间发生大量的内存复制(新生代采用复制算法收集内存)。注意:PretenureSizeThreshold参数只对Serial和ParNew两款收集器有效,Parallel Scavenge收集器不认识这个参数,Parallel Scavenge收集器一般并不需要设置。我们本机JDK8的默认收集器是新生代使用ParallerGC,老年代使用Serial Old所以演示会比较麻烦,就不演示。如果遇到必须使用此参数的场合,可以考虑ParNew加CMS的收集器组合。

3.长期存活的对象进入老年代

既然虚拟机采用了分代收集的思想来管理内存,那么内存回收时就必须能识别哪些对象

应放在新生代,哪些对象应放在老年代中。为了做到这点,虚拟机给每个对象定义了一个对

象年龄(Age)计数器。如果对象在Eden出生并经过第一次Minor GC后仍然存活,并且能被Survivor容纳的话,将被移动到Survivor空间中,并且对象年龄设为1。对象在Survivor区中每“熬过”一次Minor GC,年龄就增加1岁,当它的年龄增加到一定程度(默认为15岁),就将会被晋升到老年代中。对象晋升老年代的年龄阈值,可以通过参数-XX:MaxTenuringThreshold设置。

执行TestMaxTenuringThreshold这个类,代码示例见下图:

package com.zhuguang.allen;

import com.zhuguang.allen.tools.AddressPrint;

/**
 * @ClassName TestAllocation$
 * @Description TODO
 * @Author
 * @date 2019/6/11 17:13
 * @Version 1.0
 **/
public class TestMaxTenuringThreshold {

    private static final int _1MB=1024*1024 ;
    /**
     *VM参数:-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC
     */
    public static void testMaxTenuringThreshold (){
        byte[] allocation1,allocation2,allocation3,allocation4,allocation5;
        allocation1=new byte[1/4*_1MB];//1
        //allocation5=new byte[1/4*_1MB];//1
        allocation2=new byte[4*_1MB];//1
        allocation3=new byte[4*_1MB];
        allocation3=null;
        allocation3=new byte[4*_1MB];//出现一次Minor GC
        try {
            System.out.println("allocation1:"+AddressPrint.addressOf(allocation1));
            System.out.println("allocation2:"+ AddressPrint.addressOf(allocation2));
            System.out.println("allocation3:"+AddressPrint.addressOf(allocation3));
            //System.out.println("allocation4:"+AddressPrint.addressOf(allocation4));
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    public static void main(String[] args){
        TestMaxTenuringThreshold.testMaxTenuringThreshold();
    }
}

VM参数为:-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1 -XX:+PrintTenuringDistribution 当XX:MaxTenuringThreshold=1时,a1 = 0.25M,a2=4M;分配a3=4M时,Eden无法容纳4M的对象了,发起Minor GC,此时a1,a2 age=1,这个时候,Survivor最大容量1M,无法同时容纳存活的4.5M a1,a2。虚拟机将4M的a2放入老年代,同时将0.25M的a1放入Survivor to中,此时空间分布Eden(0M),Survivor from(0.25M),Old(4M),放入4M的a3,此时空间分布Eden(4M),Survivor from(0.25M),Old(4M)。a3=null;只是说明了a3无引用,但是数组空间仍然存在,只是提示jvm我下次可以被回收了a3=4M,又分配了4M的空间,这个时候Eden 4+4=8M 已经满了,触发一次GC(这时,jvm会清理age=1的对象,a1,a2被放在了老年代)发现之前创建的4M数组没有GC Root相关联,而且不符合自救规则,回收。此时空间分布Eden(4M),Survivor from(0M),Old(4.25M)。GC打印的结果为:

当XX:MaxTenuringThreshold=8时,a1 = 0.25M,a2=4M;分配a3=4M时,Eden无法容纳4M的对象了,发起Minor GC这个时候,Survivor最大容量1M,无法同时容纳存活的4.5M a1,a2。虚拟机将4M的a2放入老年代,同时将0.25M的a1放入Survivor to中,此时空间分布Eden(0M),Survivor from(0.25M),Old(4M)放入3M的a3,此时空间分布Eden(4M),Survivor from(0.25M),Old(4M)。a3=null;只是说明了a3无引用,但是数组空间仍然存在,只是提示jvm我下次可以被回收了a3=4M,又分配了4M的空间,这个时候Eden 4+4=8M 已经满了,触发一次GC发现之前创建的4M数组没有GC Root相关联,而且不符合自救规则,回收。此时空间分布Eden(4M),Survivor from(0.25M),Old(4M)。执行结果如下图所示

4. 动态对象年龄判定

 

为了能更好地适应不同程序的内存状况,虚拟机并不是永远地要求对象的年龄必须达到

了MaxTenuringThreshold才能晋升老年代,如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半,年龄大于或等于该年龄的对象就可以直接进入老年代,无须等到MaxTenuringThreshold中要求的年龄。执行代码:TestPretenureSizeThreshold

package com.zhuguang.allen;


import com.zhuguang.allen.tools.AddressPrint;

/**
 * @ClassName TestPretenureSizeThreshold$
 * @Description TODO
 * @Author 
 * @date 2019/6/18 16:04
 * @Version 1.0
 **/
public class TestPretenureSizeThreshold {
    private static final int _1MB=1024*1024;
    /**
     *VM参数:-verbose:gc-Xms20M-Xmx20M-Xmn10M-XX:+PrintGCDetails-XX:SurvivorRatio=8
     *-XX:PretenureSizeThreshold=3145728
     */
    public static void testPretenureSizeThreshold(){
        byte[] allocation1,allocation2,allocation3,allocation4;
        allocation1 = new byte[_1MB/4];
        allocation2 = new byte[_1MB/2];
        allocation3 = new byte[4*_1MB];
        allocation4 = new byte[4*_1MB];
        try {
            System.out.println("allocation1:"+ AddressPrint.addressOf(allocation1));
            System.out.println("allocation2:"+ AddressPrint.addressOf(allocation2));
            System.out.println("allocation3:"+ AddressPrint.addressOf(allocation3));
            System.out.println("allocation4:"+ AddressPrint.addressOf(allocation4));

        } catch (Exception e) {
            e.printStackTrace();
        }

    }
    public static void main(String[] args){
        TestPretenureSizeThreshold.testPretenureSizeThreshold();
    }
}

VM参数为:-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails  -XX:

SurvivorRatio=8  -XX:MaxTenuringThreshold=15 -XX:+PrintTenuringDistribution。

执行的结果为a1,a2,a3都进入老年代,survivor空间还是百分之0,新生代Eden区只会存在a4。

5、空间分配担保

在发生Minor GC之前,虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间,如果这个条件成立,那么Minor GC可以确保是安全的。如果不成立,则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果允许,那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小,如果大于,将尝试着进行一次Minor GC,尽管这次Minor GC是有风险的;如果小于,或者HandlePromotionFailure设置不允许冒险,那这时也要改为进行一次Full GC。

“冒险”是冒了什么风险,前面提到过,新生代使用复制收集算法,但为了内存利用率,只使用其中一个Survivor空间来作为轮换备份,因此当出现大量对象在Minor GC后仍然存活的情况(最极端的情况就是内存回收后新生代中所有对象都存活),就需要老年代进行分配担保,把Survivor无法容纳的对象直接进入老年代。与生活中的贷款担保类似,老年代要进行这样的担保,前提是老年代本身还有容纳这些对象的剩余空间,一共有多少对象会活下来在实际完成内存回收之前是无法明确知道的,所以只好取之前每一次回收晋升到老年代对象容量的平均大小值作为经验值,与老年代的剩余空间进行比较,决定是否进行Full GC来让老年代腾出更多空间。

取平均值进行比较其实仍然是一种动态概率的手段,也就是说,如果某次Minor GC存活后的对象突增,远远高于平均值的话,依然会导致担保失败(Handle Promotion Failure)。如果出现了HandlePromotionFailure失败,那就只好在失败后重新发起一次Full GC。虽然担保失败时绕的圈子是最大的,但大部分情况下都还是会将HandlePromotionFailure开关打开,避免Full GC过于频繁。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值