JVM中的内存分配策略

- 日理万妓 2022-07-15 04:57 249阅读 0赞

对象的内存分配，从大方向上将，就是在堆上分配（但也可能经过JIT编译后被拆散为标量类型并间接地在栈上分配），对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TLAB上分配。少数情况也可能直接分配在老年代中，分配的规则并不是百分之百固定的，其细节取决于当前使用的是哪一种垃圾收集器组合，还有虚拟机中与内存相关的参数的设置。  
　　下面讲解集中最普遍的内存分配规则，并通过代码去验证这些规则。本文中的代码在测试时使用Client模式虚拟机运行，没有手工指定收集器组合，换句话说，验证的是使用Serial/Serial Old收集器下（ParNew/Serial Old组合的规则也基本一致）的内存分配策略。

## 1、对象优先在Eden分配 ##

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

虚拟机提供了-XX:+PrintGCDetails这个收集器日志参数，告诉虚拟机在发生垃圾收集行为时打印内存回收日志，并且在进程退出的时候输出当前内存各区域的分配情况。在实际应用中，内存回收日志一般都是打印到文件后通过日志工具进行分析，不过本实验的日志并不多，直接阅读就能看得很清除。代码及运行结果如下：

private static final int _1MB = 1024*1024;
    
    /**
     * VM Args : -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+PrintGCDetails
     */
    public static void testAllocation(){
    	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];//出现一次Minor GC
    }

运行结果：

\[GC \[DefNew: **6487K->152K(9216K)**, 0.0041641 secs\] **6487K->6296K(19456K)**, 0.0042253 secs\] \[Times: user=0.02 sys=0.00, real=0.00 secs\]  
Heap  
def new generation total 9216K, used 4412K \[0x326e0000, 0x330e0000, 0x330e0000)  
**eden space 8192K**, 52% used \[0x326e0000, 0x32b08fe0, 0x32ee0000)  
**from space 1024K**, 14% used \[0x32fe0000, 0x330062b0, 0x330e0000)  
**to space 1024K**, 0% used \[0x32ee0000, 0x32ee0000, 0x32fe0000)  
tenured generation total 10240K, used 6144K \[0x330e0000, 0x33ae0000, 0x33ae0000)  
**the space 10240K**, 60% used \[0x330e0000, 0x336e0030, 0x336e0200, 0x33ae0000)  
compacting perm gen total 12288K, used 375K \[0x33ae0000, 0x346e0000, 0x37ae0000)  
the space 12288K, 3% used \[0x33ae0000, 0x33b3dcb0, 0x33b3de00, 0x346e0000)  
ro space 10240K, 54% used \[0x37ae0000, 0x3805d9f8, 0x3805da00, 0x384e0000)  
rw space 12288K, 55% used \[0x384e0000, 0x38b813f8, 0x38b81400, 0x390e0000)

上述程序的testAllocation()方法中，尝试分配3个2MB和1个4MB的对象，在运行时通过-Xms20M、-Xmx20M和-Xmn10M这3个参数限制Java堆大小为20M，且不可扩展，其中10MB分配给新生代，剩下的10M就分配给老年代了。-XX:SurvivorRatio=8决定了新生代中Eden和Survivor区的空间比例为8:1，从运行结果可以看到“eden space 8192K、from space 1024K、to space 1024K”的信息，新生代总可用空间为9216KB（Eden区+1个Survivor区的总容量）。

执行testAllocation()中分配allocation4对象的语句时会发生一次Minor GC，这次GC的结果是新生代由6487K变为152K，而总内存占用了几乎没有减少（因为allocation1,2,3三个对象都是存活的虚拟机几乎没有找到可回收的对象）。这次GC发生的原因是给allocation4分配所需的4MB内存时，发现Eden区已经被占用了6MB，剩余空间不足以分配4MB，因此发生Minor GC。GC期间虚拟机又发现已有的3个2MB对象无法全部放入Survivor空间（Survivor只有1MB），所以只好通过分配担保机制提前转移到老年代。

这次GC结束后，4MB的allocation4对象被顺利分配到Eden中。因此程序执行完的结果是Eden占用4MB（被allocation4占用），Survivor空闲，老年代被占用6MB（allocation1,2,3占用）。

在这里补充一点，Minor GC和Full GC的区别：

新生代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倍以上。

## 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的对象都会直接在老年代中进行分配。

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

虚拟机采用了分代收集的思想来管理内存，那内存回收时就必须识别哪些对象应该放在新生代，哪些对象应该放在老年代中。为了做到这点，虚拟机给每个对象定义了一个对象年龄（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];
    }

当-XX:MaxTenuringThreshold=1时，运行结果：

\[GC \[DefNew  
Desired 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 \[DefNew  
Desired 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 \[DefNew  
Desired 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 \[DefNew  
Desired 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的空间被占用。

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

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

/\*\*  
\* VM Args : -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8  
\* -XX:MaxTenuringThreshold=15 -XX:+PrintTenuringDistribution  
*/  
public static void testTenuringThreshold2()\{  
byte\[\] allocation1,allocation2,allocation3,allocation4;  
allocation1 = new byte\[\_1MB/4\];  
allocation2 = new byte\[\_1MB/4\];  
allocation3 = new byte\[4*\_1MB\];  
allocation4 = new byte\[4\*\_1MB\];  
allocation4 = null;  
allocation4 = new byte\[4\*\_1MB\];  
\}  
运行结果：

\[GC \[DefNew  
Desired survivor size 524288 bytes, new threshold 1 (max 15)

*  age 1: 682360 bytes, 682360 total

: 5115K->666K(9216K), 0.0068333 secs\] 5115K->4762K(19456K), 0.0069434 secs\] \[Times: user=0.01 sys=0.00, real=0.01 secs\]  
\[GC \[DefNew  
Desired survivor size 524288 bytes, new threshold 15 (max 15)  
: 4762K->0K(9216K), 0.0015284 secs\] 8858K->4762K(19456K), 0.0016157 secs\] \[Times: user=0.00 sys=0.00, real=0.00 secs\]  
Heap  
def new generation total 9216K, used 4178K \[0x04470000, 0x04e70000, 0x04e70000)  
eden space 8192K, 51% used \[0x04470000, 0x04884830, 0x04c70000)  
from space 1024K, 0% used \[0x04c70000, 0x04c70000, 0x04d70000)  
to space 1024K, 0% used \[0x04d70000, 0x04d70000, 0x04e70000)  
tenured generation total 10240K, used 4762K \[0x04e70000, 0x05870000, 0x05870000)  
the space 10240K, 46% used \[0x04e70000, 0x053168f8, 0x05316a00, 0x05870000)  
compacting perm gen total 12288K, used 2137K \[0x05870000, 0x06470000, 0x09870000)  
the space 12288K, 17% used \[0x05870000, 0x05a86580, 0x05a86600, 0x06470000)  
No shared spaces configured.

发现运行结果中Survivor占用仍然为0%，而老年代比预期增加了6%，也就是说allocation1，allocation2对象都直接进入了老年代，而没有等到15岁的临界年龄。因为这两个对象加起来达到了512KB，并且它们是同年的，满足同年对象达到Survivor空间的一半规则。我们只要注释一个对象的new操作，就会发现另外一个不会晋升到老年代了。

## 5、空间分配担保 ##

当发生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过于频繁。

/**
    	 * VM Args : -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8
    	 * -XX:-HandlePromotionFailure -XX:+PrintGCDetails
    	 */
    	public static void testHandlePromotion(){
    		byte[] allocation1,allocation2,allocation3,allocation4,allocation5,
    			allocation6,allocation7;
    		allocation1 = new byte[2*_1MB];
    		allocation2 = new byte[2*_1MB];
    		allocation3 = new byte[2*_1MB];
    		allocation1 = null;
    		allocation4 = new byte[2*_1MB];
    		allocation5 = new byte[2*_1MB];
    		allocation6 = new byte[2*_1MB];
    		allocation4 = null;
    		allocation5 = null;
    		allocation6 = null;
    		allocation7 = new byte[2*_1MB];
    	}

以HandlePromotionFailure=false运行结果：

\[GC \[DefNew: 6651K->154K(9216K), 0.0033102 secs\] 6651K->4250K(19456K), 0.0033813 secs\] \[Times: user=0.00 sys=0.00, real=0.00 secs\]  
\[GC \[DefNew: 6384K->6384K(9216K), 0.0000288 secs\]\[Tenured: 4096K->4250K(10240K), 0.0039019 secs\] 10480K->4250K(19456K), \[Perm : 2132K->2132K(12288K)\], 0.0040460 secs\] \[Times: user=0.00 sys=0.00, real=0.00 secs\]  
Heap  
def new generation total 9216K, used 2211K \[0x044e0000, 0x04ee0000, 0x04ee0000)  
eden space 8192K, 27% used \[0x044e0000, 0x04708fe0, 0x04ce0000)  
from space 1024K, 0% used \[0x04de0000, 0x04de0000, 0x04ee0000)  
to space 1024K, 0% used \[0x04ce0000, 0x04ce0000, 0x04de0000)  
tenured generation total 10240K, used 4250K \[0x04ee0000, 0x058e0000, 0x058e0000)  
the space 10240K, 41% used \[0x04ee0000, 0x053068a8, 0x05306a00, 0x058e0000)  
compacting perm gen total 12288K, used 2137K \[0x058e0000, 0x064e0000, 0x098e0000)  
the space 12288K, 17% used \[0x058e0000, 0x05af6710, 0x05af6800, 0x064e0000)  
No shared spaces configured.

以HandlePromotionFailure=true运行结果：

\[GC \[DefNew: 6651K->154K(9216K), 0.0038289 secs\] 6651K->4250K(19456K), 0.0038877 secs\] \[Times: user=0.00 sys=0.00, real=0.00 secs\]  
\[GC \[DefNew: 6384K->154K(9216K), 0.0006008 secs\] 10480K->4250K(19456K), 0.0006525 secs\] \[Times: user=0.00 sys=0.00, real=0.00 secs\]  
Heap  
def new generation total 9216K, used 2366K \[0x043d0000, 0x04dd0000, 0x04dd0000)  
eden space 8192K, 27% used \[0x043d0000, 0x045f8fe0, 0x04bd0000)  
from space 1024K, 15% used \[0x04bd0000, 0x04bf6888, 0x04cd0000)  
to space 1024K, 0% used \[0x04cd0000, 0x04cd0000, 0x04dd0000)  
tenured generation total 10240K, used 4096K \[0x04dd0000, 0x057d0000, 0x057d0000)  
the space 10240K, 40% used \[0x04dd0000, 0x051d0020, 0x051d0200, 0x057d0000)  
compacting perm gen total 12288K, used 2137K \[0x057d0000, 0x063d0000, 0x097d0000)  
the space 12288K, 17% used \[0x057d0000, 0x059e6710, 0x059e6800, 0x063d0000)  
No shared spaces configured.

在JDK 6 Update 24之后，HandlePromotionFailure参数不再影响虚拟机的空间分配担保策略，虽然源码中仍旧定义了此参数，但是代码中已经不会再使用它。JDK 6 Update 24之后的规则变为：**只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小，就会进行Minor GC，否则将进行Full GC。**