Parallel Scavenge收集器与MaxTenuringThreshold

在准备Java垃圾收集器和内存分配策略课件的过程中，看到Parallel Scavenge收集器与Serial收集器在Survivor区的使用策略还是有很大不同。本文对看到的Parallel Scavenge收集器的运行现象进行笔记。

本人开发环境的JVM版本信息如下：

>java -version  
java version "1.8.0_101"  
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)  
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode) 

测试代码如下：

	private static final int _1MB = 1024 * 1024;

	/*
	 * VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8
	 */
	public static void main(String[] args) throws Exception {
		byte[] alloc1, alloc2, alloc3, alloc4;
		alloc1 = new byte[_1MB / 4];
		System.out.println("alloc1 " + printAddressOf(alloc1));
		alloc2 = new byte[3 * _1MB];
		System.out.println("alloc2 " + printAddressOf(alloc2));
		alloc3 = new byte[3 * _1MB];
		System.out.println("alloc3 " + printAddressOf(alloc3));
		alloc4 = new byte[3 * _1MB];
		System.out.println("alloc4 " + printAddressOf(alloc4));
		
		System.out.println();
		System.out.println("alloc1 " + printAddressOf(alloc1));
		System.out.println("alloc2 " + printAddressOf(alloc2));
		System.out.println("alloc3 " + printAddressOf(alloc3));
		System.out.println("alloc4 " + printAddressOf(alloc4));
	}

printAddressOf是一个简单的获取对象在内存的地址的方法。
用VM参数-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8运行上述代码，在控制台得到的输出如下：

alloc1 0x00000000ff6f6158
alloc2 0x00000000ff788b30
alloc3 0x00000000ffa88b40
[GC (Allocation Failure) [PSYoungGen: 7714K->1016K(9216K)] 7714K->7176K(19456K), 0.0038298 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[Full GC (Ergonomics) [PSYoungGen: 1016K->0K(9216K)] [ParOldGen: 6160K->7101K(10240K)] 7176K->7101K(19456K), [Metaspace: 3444K->3444K(1056768K)], 0.0068693 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
alloc4 0x00000000ff600000

alloc1 0x00000000ff219e10
alloc2 0x00000000fec012f8
alloc3 0x00000000fef01308
alloc4 0x00000000ff600000
Heap
 PSYoungGen      total 9216K, used 3314K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
  eden space 8192K, 40% used [0x00000000ff600000,0x00000000ff93caa0,0x00000000ffe00000)
  from space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)
  to   space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
 ParOldGen       total 10240K, used 7101K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  object space 10240K, 69% used [0x00000000fec00000,0x00000000ff2ef588,0x00000000ff600000)
 Metaspace       used 3451K, capacity 4564K, committed 4864K, reserved 1056768K
  class space    used 385K, capacity 388K, committed 512K, reserved 1048576K

从上面的内容可以看出：

• 在GC和Full GC后，alloc1不在Survivor区，而是进入了老年代

现在是不能下结论说alloc1是否在Survivor区待过，我推测alloc1在GC后，是到过Survivor区的，在Full GC是被移动到了老年代。理由有两点：

1. GC后，PSYoungGen的区域已使用量变为1016K，在Full GC才变为0K
2. alloc1最后的内存地址比alloc2，alloc3要高，如果alloc1和alloc2、alloc3是同时被移动到老年代的，alloc1的内存地址更可能比后面两个对象要低，说明alloc1晚于alloc2，alloc3被移动到老年代

我想证实我的推测，所以对测试代码做了点变动：

	private static final int _1MB = 1024 * 1024;

	/*
	 * VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8
	 */
	public static void main(String[] args) throws Exception {
		byte[] alloc1, alloc2, alloc3, alloc4;
		alloc1 = new byte[_1MB / 4];
		System.out.println("alloc1 " + printAddressOf(alloc1));
		alloc2 = new byte[3 * _1MB];
		System.out.println("alloc2 " + printAddressOf(alloc2));
		alloc3 = new byte[3 * _1MB];
		System.out.println("alloc3 " + printAddressOf(alloc3));
		alloc3 = null;
		alloc4 = new byte[3 * _1MB];
		System.out.println("alloc4 " + printAddressOf(alloc4));
		
		System.out.println();
		System.out.println("alloc1 " + printAddressOf(alloc1));
		System.out.println("alloc2 " + printAddressOf(alloc2));
//		System.out.println("alloc3 " + printAddressOf(alloc3));
		System.out.println("alloc4 " + printAddressOf(alloc4));
	}

用同样的VM参数运行，在控制台得到的输出如下：

alloc1 0x00000000ff6f6158
alloc2 0x00000000ff788b30
alloc3 0x00000000ffa88b40
[GC (Allocation Failure) [PSYoungGen: 7714K->1016K(9216K)] 7714K->4112K(19456K), 0.0024849 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
alloc4 0x00000000ff600000

alloc1 0x00000000ffe20000
alloc2 0x00000000fec02000
alloc4 0x00000000ff600000
Heap
 PSYoungGen      total 9216K, used 4330K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
  eden space 8192K, 40% used [0x00000000ff600000,0x00000000ff93caa0,0x00000000ffe00000)
  from space 1024K, 99% used [0x00000000ffe00000,0x00000000ffefe040,0x00000000fff00000)
  to   space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
 ParOldGen       total 10240K, used 3096K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  object space 10240K, 30% used [0x00000000fec00000,0x00000000fef06010,0x00000000ff600000)
 Metaspace       used 3451K, capacity 4564K, committed 4864K, reserved 1056768K
  class space    used 385K, capacity 388K, committed 512K, reserved 1048576K

从上面的内容，可以看出：

• 只发生了一次GC，没有发生Full GC
• 只有alloc2被移动到了老年代，alloc1被移动到了Survivor区，alloc3被直接从eden回收，alloc4分配在了eden上

所以我相信我之前的推测是正确的：alloc1在GC后在Survivor区短暂地停留了一段时间，然后在Full GC中被移动到了老年代。

关于在Parallel Scavenge + Parallel Old模式下，Survivor区地对象进入老年代地算法还没有清楚。我将MaxTenuringThreshold参数设置了不同地值来运行上面地代码，得到地结果没有变化。这里面的详细算法，有待对JVM的源码进行分析后才能揭开其神秘的面纱。