代码如下:
public class TestTenuringThreshold {
private static final int _1MB = 1024 * 1024; /**
* vm-args: -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8
* -XX:MaxTenuringThreshold=1 -XX:+PrintTenuringDistribution
*/
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];
}
public static void main(String[] args) {
testTenuringThreshold();
}
}
代码分析:
这个代码会发生两次Minor GC:
第一次:allocation3第一次创建byte数组时,因为eden只有8M左右,没有内存再分配给新对象,所有进行了第一次GC-----allocation2的索引对象进入了老年代.
第二次:在allocation3 = null;执行以后,之前创建的对象已经"死亡",触发第二次GC回收死亡对象.与此同时,如果MaxTenuringThreshold的参数为1的话,在survivor中的allocation1的索引对象,因为age已经为1,所以会进入老年代.而当MaxTenuringThreshold大于1时,survivor中的allocation1的索引对象age+=1,不会进入老年代;
运行结果
MaxTenuringThreshold=1
[GC[DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 1)
- age 1: 700488 bytes, 700488 total
: 5392K->684K(9216K), 0.0048021 secs] 5392K->4780K(19456K), 0.0048690 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC[DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 1)
- age 1: 224 bytes, 224 total
: 5028K->0K(9216K), 0.0016226 secs] 9124K->4776K(19456K), 0.0016547 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
def new generation total 9216K, used 4234K [0x33c00000, 0x34600000, 0x34600000)
eden space 8192K, 51% used [0x33c00000, 0x34022830, 0x34400000)
from space 1024K, 0% used [0x34400000, 0x344000e0, 0x34500000)
to space 1024K, 0% used [0x34500000, 0x34500000, 0x34600000)
tenured generation total 10240K, used 4775K [0x34600000, 0x35000000, 0x35000000)
the space 10240K, 46% used [0x34600000, 0x34aa9f70, 0x34aaa000, 0x35000000)
compacting perm gen total 12288K, used 233K [0x35000000, 0x35c00000, 0x39000000)
the space 12288K, 1% used [0x35000000, 0x3503a4a0, 0x3503a600, 0x35c00000)
ro space 10240K, 44% used [0x39000000, 0x3947d3a8, 0x3947d400, 0x39a00000)
rw space 12288K, 52% used [0x39a00000, 0x3a049a18, 0x3a049c00, 0x3a600000)
MaxTenuringThreshold=15
[GC[DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 15)
- age 1: 700488 bytes, 700488 total
: 5556K->684K(9216K), 0.0053202 secs] 5556K->4780K(19456K), 0.0053826 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC[DefNew
Desired survivor size 524288 bytes, new threshold 15 (max 15)
- age 1: 224 bytes, 224 total
: 4948K->0K(9216K), 0.0016949 secs] 9044K->4776K(19456K), 0.0017323 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
def new generation total 9216K, used 4234K [0x33c00000, 0x34600000, 0x34600000)
eden space 8192K, 51% used [0x33c00000, 0x34022810, 0x34400000)
from space 1024K, 0% used [0x34400000, 0x344000e0, 0x34500000)
to space 1024K, 0% used [0x34500000, 0x34500000, 0x34600000)
tenured generation total 10240K, used 4775K [0x34600000, 0x35000000, 0x35000000)
the space 10240K, 46% used [0x34600000, 0x34aa9f70, 0x34aaa000, 0x35000000)
compacting perm gen total 12288K, used 233K [0x35000000, 0x35c00000, 0x39000000)
the space 12288K, 1% used [0x35000000, 0x3503a4a0, 0x3503a600, 0x35c00000)
ro space 10240K, 44% used [0x39000000, 0x3947d3a8, 0x3947d400, 0x39a00000)
rw space 12288K, 52% used [0x39a00000, 0x3a049a18, 0x3a049c00, 0x3a600000)
问题分析:
问题出现:MaxTenuringThreshold=1时,结果与分析完全对应.但MaxTenuringThreshold=15时的结果相对预期出现了偏差.
-----------第一次编辑-----------17.8.12 11:20
尝试解决:
尝试1:此时jdk使用的是1.7.0_80,更换jdk为1.6.0_24
MaxTenuringThreshold=1
[GC [DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 1)
- age 1: 441368 bytes, 441368 total
: 5023K->431K(9216K), 0.0033469 secs] 5023K->4527K(19456K), 0.0033763 secs] [Times: user=0.00 sys=0.02, real=0.00 secs]
[GC [DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 1)
- age 1: 88 bytes, 88 total
: 4611K->0K(9216K), 0.0007613 secs] 8707K->4526K(19456K), 0.0007800 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
def new generation total 9216K, used 4260K [0x33040000, 0x33a40000, 0x33a40000)
eden space 8192K, 52% used [0x33040000, 0x33468fe0, 0x33840000)
from space 1024K, 0% used [0x33840000, 0x33840058, 0x33940000)
to space 1024K, 0% used [0x33940000, 0x33940000, 0x33a40000)
tenured generation total 10240K, used 4526K [0x33a40000, 0x34440000, 0x34440000)
the space 10240K, 44% used [0x33a40000, 0x33eabb98, 0x33eabc00, 0x34440000)
compacting perm gen total 12288K, used 412K [0x34440000, 0x35040000, 0x38440000)
the space 12288K, 3% used [0x34440000, 0x344a7368, 0x344a7400, 0x35040000)
ro space 10240K, 54% used [0x38440000, 0x389bd9f8, 0x389bda00, 0x38e40000)
rw space 12288K, 55% used [0x38e40000, 0x394e13f8, 0x394e1400, 0x39a40000)
MaxTenuringThreshold=15
[GC [DefNew
Desired survivor size 524288 bytes, new threshold 15 (max 15)
- age 1: 441368 bytes, 441368 total
: 5023K->431K(9216K), 0.0034562 secs] 5023K->4527K(19456K), 0.0034839 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC [DefNew
Desired survivor size 524288 bytes, new threshold 15 (max 15)
- age 1: 88 bytes, 88 total
- age 2: 441224 bytes, 441312 total
: 4611K->430K(9216K), 0.0009541 secs] 8707K->4526K(19456K), 0.0009800 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
def new generation total 9216K, used 4747K [0x33040000, 0x33a40000, 0x33a40000)
eden space 8192K, 52% used [0x33040000, 0x33477090, 0x33840000)
from space 1024K, 42% used [0x33840000, 0x338abbe0, 0x33940000)
to space 1024K, 0% used [0x33940000, 0x33940000, 0x33a40000)
tenured generation total 10240K, used 4096K [0x33a40000, 0x34440000, 0x34440000)
the space 10240K, 40% used [0x33a40000, 0x33e40010, 0x33e40200, 0x34440000)
compacting perm gen total 12288K, used 413K [0x34440000, 0x35040000, 0x38440000)
the space 12288K, 3% used [0x34440000, 0x344a76f8, 0x344a7800, 0x35040000)
ro space 10240K, 54% used [0x38440000, 0x389bd9f8, 0x389bda00, 0x38e40000)
rw space 12288K, 55% used [0x38e40000, 0x394e13f8, 0x394e1400, 0x39a40000)
发现在参数为15时第二次GC出现了age 2 字样,而且运行结果的 from space(即一个survivor)中存在数据
结果:
更换jdk版本以后结果符合了预期,可以看出jdk在升级以后对虚拟机进行了改动.
至于此改动的具体内容与意义,笔者现在无法分析,留在以后解决再更新
-----------第二次编辑-----------17.8.12 15:18