内存分配策略

墨蓝 2022-02-03 09:59 224阅读 0赞

# 这里的内存指的是Java堆内存 #

Java堆内存的划分：

***1.jdk1.7及以前的划分：***  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXNodWFpNTI4_size_16_color_FFFFFF_t_70]  
***2.jdk1.8的内存划分：***  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXNodWFpNTI4_size_16_color_FFFFFF_t_70 1]

对象的内存分配，往大方向讲，就是在堆上分配（但也可能经过JIT编译后被拆散为标
    量类型并间接地栈上分配[1]），对象主要分配在新生代的Eden区上，如果启动了本地线程分
    配缓冲，将按线程优先在TLAB上分配。 少数情况下也可能会直接分配在老年代中，分配的
    规则并不是百分之百固定的，其细节取决于当前使用的是哪一种垃圾收集器组合，还有虚拟
    机中与内存相关的参数的设置。

1.优先分配到Eden区
     2.如果有大对象，直接进入老年代
     3.长期存活的对象，分配到老年代
     4.如果Eden空间不够，需要向老年代借空间，空间担保
     5.动态对象年龄判断

Java虚拟机中参数的定义
    -Xms20M    设置Java堆内存最小为20M
    -Xmx20M    设置Java堆内存最大为20M
    -Xmn10M    设置Java堆内存新生代为10M
    -XX:SurvivorRatio=8   新生代中Eden区与一个Survivor区的空间比例是8:1
    -XX:PretenureSizeThreshold  令大于这个设置值的对象直接在老年代分配。 这样做的目的是避免在Eden区及两个Survivor区之间
    							发生大量的内存复制
    						
    							 注意PretenureSizeThreshold参数只对 Serial 和 ParNew 两款收集器有效
    							 
    							 如果遇到必须使用此参数的场合，可以考虑 ParNew 加 CMS 的收集器组合

新生代GC（Minor GC）：指发生在新生代的垃圾收集动作，因为Java对象大多都具备朝
    					生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。
    					
    老年代GC（Major GC/Full GC）：指发生在老年代的GC，出现了Major GC，经常会伴
    							随至少一次的Minor GC（但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行
    							Major GC的策略选择过程）。 Major GC的速度一般会比Minor GC慢10倍以上。

*  
 *  
 *

#### 1.优先分配到Eden区 ####

public class TestMemory {
    
        @Test
        public void test01() {
            byte[] bytes = new byte[8 * 1024 * 1024];
        }
    }

由上面代码测试，查看垃圾收集日志 需要在运行的IDE设置VM options中添加以下参数：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXNodWFpNTI4_size_16_color_FFFFFF_t_70 2]  
可以查看到日志如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXNodWFpNTI4_size_16_color_FFFFFF_t_70 3]  
***可以得知，分配的8M空间，主要都是集中在Eden区，仅仅只有一小部分分配在from survivor区域中。***

*  
 *  
 *  
 *

当将代码改造成如下代码时：分配的内存空间变大些

#### 2.如果有大对象，直接进入老年代 ####

public class TestMemory {
    
        @Test
        public void test01() {
            byte[] bytes = new byte[40 * 1024 * 1024];
        }
    }

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXNodWFpNTI4_size_16_color_FFFFFF_t_70 4]  
***可以看出，Eden区域里面的内存空间占用反而变小了，但是ParOldGen里面的 used占用变大了，说明在创建大内存的时候，会直接往老年代空间分配内存使用！***

可以在VM options中指定参数，可以使你想让的大对象进入老年代，   -XX:PretenureSizeThreshold
     这个参数来配置进入老年代的 对象的大小

public class TestMemory {
    
        private  static int _1MB = 1024 * 1024;
        @Test
        public void test02() {
            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];
        }
     }

日志打印如下：

[GC (Allocation Failure) [DefNew: 8192K->1024K(9216K), 0.0099768 secs] 8192K->1117K(19456K), 0.0101741 secs] 
    [Times: user=0.00 sys=0.00, real=0.01 secs] 
    [GC (Allocation Failure) [DefNew: 9216K->824K(9216K), 0.0032433 secs] 9309K->1857K(19456K), 0.0032779 secs] 
    [Times: user=0.00 sys=0.00, real=0.00 secs] [GC (Allocation Failure) [DefNew: 9016K->912K(9216K), 0.0108573 secs] 
    10049K->2403K(19456K), 0.0108906 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] [GC (Allocation Failure) 
    [DefNew: 7309K->195K(9216K), 0.0034662 secs] 8800K->6088K(19456K), 0.0035079 secs]
     [Times: user=0.00 sys=0.00, real=0.00 secs] 
    
    Heap
     def new generation   total 9216K, used 7548K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
      eden space 8192K,  89% used [0x00000000fec00000, 0x00000000ff32e570, 0x00000000ff400000)
      from space 1024K,  19% used [0x00000000ff400000, 0x00000000ff430e40, 0x00000000ff500000)
      to   space 1024K,   0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
     tenured generation   total 10240K, used 5893K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
       the space 10240K,  57% used [0x00000000ff600000, 0x00000000ffbc1510, 0x00000000ffbc1600, 0x0000000100000000)
     Metaspace       used 8590K, capacity 9494K, committed 9856K, reserved 1058816K
      class space    used 1104K, capacity 1289K, committed 1408K, reserved 1048576K
    Disconnected from the target VM, address: '127.0.0.1:1089', transport: 'socket'

对以上现象的解释：

test02（）方法中，尝试分配3个2MB大小和1个4MB大小的对象，
    在运行时通过-Xms20M、 -Xmx20M、 -Xmn10M这3个参数限制了Java堆大小为20MB，不可扩
    展，其中10MB分配给新生代，剩下的10MB分配给老年代。 -XX：SurvivorRatio=8决定了新
    生代中Eden区与一个Survivor区的空间比例是8:1，从输出的结果也可以清晰地看到“eden
    space 8192K、 from space 1024K、 to space 1024K”的信息，新生代总可用空间为
    9216KB（Eden区+1个Survivor区的总容量）。
    
    执行test02（）中分配allocation4对象的语句时会发生一次Minor GC，这次GC的
    结果是新生代6651KB变为148KB，而总内存占用量则几乎没有减少（因为allocation1、
    allocation2、 allocation3三个对象都是存活的，虚拟机几乎没有找到可回收的对象）。 这次
    GC发生的原因是给allocation4分配内存的时候，发现Eden已经被占用了6MB，剩余空间已不
    足以分配allocation4所需的4MB内存，因此发生Minor GC。 GC期间虚拟机又发现已有的3个
    2MB大小的对象全部无法放入Survivor空间（Survivor空间只有1MB大小），所以只好通过分
    配担保机制提前转移到老年代去。
    
    这次GC结束后，4MB的allocation4对象顺利分配在Eden中，因此程序执行完的结果是
    Eden占用4MB（被allocation4占用），Survivor空闲，老年代被占用6MB（被allocation1、allocation2、 allocation3占用）。

*  
 *  
 *

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

既然虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象
    应放在新生代，哪些对象应放在老年代中。 为了做到这点，虚拟机给每个对象定义了一个对
    象年龄（Age）计数器。 如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被
    Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1。 对象在Survivor区中
    每“熬过”一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁），就
    将会被晋升到老年代中。 对象晋升老年代的年龄阈值，可以通过参数-XX：MaxTenuringThreshold设置
    
    当对象存活时间，大于等于  -XX：MaxTenuringThreshold 设置的参数值时，会将此对象放到老年代。否则此对象如果未被回收，
    还是会在新年代空间中，等待回收或者是达到 参数值时 进入老年代空间。

*  
 *  
 *

#### 4.动态对象年龄判定 ####

为了能更好地适应不同程序的内存状况，虚拟机并不是永远地要求对象的年龄必须达到
    了MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总
    和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等
    到MaxTenuringThreshold中要求的年龄。

*  
 *  
 *

#### 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过于频繁

-XX：-HandlePromotionFailure 参数是设置 是否允许担保失败
    
    -XX：-HandlePromotionFailure = true   是允许担保失败
    -XX：-HandlePromotionFailure = false  是不允许担保失败

在JDK 6 Update 24之后，HandlePromotionFailure参数不会再影响到虚拟机的空间分配担保策略，
    观察OpenJDK中的源码变化，虽然源码中还定义了HandlePromotionFailure参数，但是在代码中已经不会再使用它。
     JDK 6 Update 24之后的规则变为只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就
    会进行Minor GC，否则将进行Full GC。 也就是 如果老年代 的空间 足够新生代 对象使用 就会进行 新生代 垃圾回收，
    如果 老年代 空间 不够使用的， 就会先 进行Full GC (也就是先进性老年代空间垃圾回收，然后再新生代空间回收)

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXNodWFpNTI4_size_16_color_FFFFFF_t_70]: /images/20220203/5d3ef7a7c743408a99a349c00bd354c7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXNodWFpNTI4_size_16_color_FFFFFF_t_70 1]: /images/20220203/49b27c0e576849a8bb90d20bd163c98d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXNodWFpNTI4_size_16_color_FFFFFF_t_70 2]: /images/20220203/26bfaefd14ec41ea93407f30d977d116.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXNodWFpNTI4_size_16_color_FFFFFF_t_70 3]: /images/20220203/6eb1f2953b684a228da3f7b2a275f0fa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXNodWFpNTI4_size_16_color_FFFFFF_t_70 4]: /images/20220203/ca227e0f0af340d4a163feaf12220f6b.png