JVM学习-----java7与Java8新生代GC发生了什么

测试代码

VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8

verbose:gc 表示输出虚拟机中GC的详细情况.
-Xms20m:表示堆的最小值为20M
-Xms20m:表示堆的最大值同样设置为20M,
-Xmn10M:表示新生代分配10M
-XX:SurvivorRatio=8:表示新生代的eden区:from区：to区:8:1:1
-XX:+PrintGCDetails 打印GC日志到控制台

package com.wuhulala.jvm.gc;

/**
* 新生代GC
*
* @author xueaohui
* @version 1.0
* @date 2017/3/19
* @link https://github.com/wuhulala */
public class MinorGC {

private static final int _1MB = 1024 * 1024;

public static void main(String[] args) {
byte[] allocation1, allocation2, allocation3, allocation4;
allocation1 = new byte[_1MB * 2];
allocation2 = new byte[_1MB * 2];
allocation3 = new byte[_1MB * 2];
allocation4 = new byte[_1MB * 5]; //出现一次MinorGC

}

}

java8_1.8.0_111

日志

/**
*  Heap java8
*PSYoungGen      total 9216K, used 7789K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
*eden space 8192K, 95% used [0x00000000ff600000,0x00000000ffd9b7d8,0x00000000ffe00000)
*from space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
*to   space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)
*ParOldGen       total 10240K, used 4096K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
*object space 10240K, 40% used [0x00000000fec00000,0x00000000ff000010,0x00000000ff600000)
*Metaspace       used 3215K, capacity 4494K, committed 4864K, reserved 1056768K
*class space    used 355K, capacity 386K, committed 512K, reserved 1048576K
*/

从上面结果来看 java8 默认使用的新生代垃圾收集器是PSYoungGen(Parallel Scavenge) 它是并行收集器

注重于吞吐量的指标，吞吐量可以简单理解为 CPU执行用户程序的时间。

如果没有太多的操作 ，那么GC次数肯定也会很少，所以就不用过于关注GC的时候的停顿时间。

在这种应用场景之下，我们就可以关注一下 吞吐量了(吞吐量=运行用户代码时间/（运行用户代码时间+GC消耗的时间）)

//在注释掉**allocation4 = new byte[_1MB * 4]; **此语句之后 我发现GC打印日志如下

//Heap
//PSYoungGen      total 9216K, used 7789K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
//eden space 8192K, 95% used [0x00000000ff600000,0x00000000ffd9b7d8,0x00000000ffe00000)
//from space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
//to   space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)
//ParOldGen       total 10240K, used 0K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
//object space 10240K, 0% used [0x00000000fec00000,0x00000000fec00000,0x00000000ff600000)
//Metaspace       used 3216K, capacity 4494K, committed 4864K, reserved 1056768K
//class space    used 355K, capacity 386K, committed 512K, reserved 1048576K

可见老年代没有任何对象

在对allocation4分配内存之后

新生代内存没有发生变化 老年代的内存刚好4M内存 与allocation4的内存大小对应

那么老年代的估计就是allocation4了

但是为了解决这个疑惑

那么我为allocation4分配5M内存，查看日志

// ParOldGen       total 10240K, used 5120K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)

那就可以有了如下解释

PS收集器为了保证吞吐量 并且在新生代没有足够的内存的情况下 直接把新的大对象分配到了老年代

java7_1.7.0_15

/**
* Heap java7
*def new generation   total 9216K, used 4779K [0x331b0000, 0x33bb0000, 0x33bb0000)
*eden space 8192K,  53% used [0x331b0000, 0x335ed7f0, 0x339b0000)
*from space 1024K,  42% used [0x33ab0000, 0x33b1d660, 0x33bb0000)
*to   space 1024K,   0% used [0x339b0000, 0x339b0000, 0x33ab0000)
*tenured generation   total 10240K, used 6144K [0x33bb0000, 0x345b0000, 0x345b0000)
*the space 10240K,  60% used [0x33bb0000, 0x341b0030, 0x341b0200, 0x345b0000)
*compacting perm gen  total 12288K, used 203K [0x345b0000, 0x351b0000, 0x385b0000)
*the space 12288K,   1% used [0x345b0000, 0x345e2fd8, 0x345e3000, 0x351b0000)
*ro space 10240K,  45% used [0x385b0000, 0x38a37290, 0x38a37400, 0x38fb0000)
*rw space 12288K,  54% used [0x38fb0000, 0x3963ace8, 0x3963ae00, 0x39bb0000)
*/

java7 默认使用的是Serial 收集器，它是最原始的收集器。

由于survivor区没有足够的内存存放，

所以allocation1 allocation2 allocation3 直接进入老年代

在老年代的是allocation1 、allocation2、 allocation3 内存占6M

在新生代的时候是新的allocation4 内存占4M

===================2017.03.19 PM=========================

、

经查阅资料得知：

-XX:PretenureSizeThreshold 参数可以配置一个内存阀值，大于这个值的对象直接分配在老年代之中。

在Parallel Scavenge收集器中此参数无效。

那么在java7中allocation4没有进入老年代就可以解释了。

在VM参数加入

-XX:PretenureSizeThreshold=3145728 （3M）

打印日志：

Heap
def new generation   total 9216K, used 7348K [0x331b0000, 0x33bb0000, 0x33bb0000)
eden space 8192K,  89% used [0x331b0000, 0x338dd0b8, 0x339b0000)
from space 1024K,   0% used [0x339b0000, 0x339b0000, 0x33ab0000)
to   space 1024K,   0% used [0x33ab0000, 0x33ab0000, 0x33bb0000)
tenured generation   total 10240K, used 4096K [0x33bb0000, 0x345b0000, 0x345b0000)
the space 10240K,  40% used [0x33bb0000, 0x33fb0010, 0x33fb0200, 0x345b0000)
compacting perm gen  total 12288K, used 185K [0x345b0000, 0x351b0000, 0x385b0000)
the space 12288K,   1% used [0x345b0000, 0x345de658, 0x345de800, 0x351b0000)
ro space 10240K,  45% used [0x385b0000, 0x38a37290, 0x38a37400, 0x38fb0000)
rw space 12288K,  54% used [0x38fb0000, 0x3963ace8, 0x3963ae00, 0x39bb0000)

the space 10240K, 40% used [0x33bb0000, 0x33fb0010, 0x33fb0200, 0x345b0000)

由上可知allocation4现在在老年代中

占用了40%的内存

tip: 大内存对象最好不要用