几中垃圾收集器组合测试

测试代码:

public class demonopara {

private static final int _1MB = 1024*1024;

public static void main(String[] args) {

// TODO Auto-generated method stub

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];

}

}

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

(堆大小20M,不可拓展,10M新生代,10M老生代,Eden和Survivor的比例是8:1,OK)



1.Parallel Scavenge + Serial Old(-XX:+UseParallelGC)

Heap

 PSYoungGen      total 9216K, used 7159K [0x00000007ff600000, 0x0000000800000000, 0x0000000800000000)

  eden space 8192K, 87% used [0x00000007ff600000,0x00000007ffcfde20,0x00000007ffe00000)

  from space 1024K, 0% used [0x00000007fff00000,0x00000007fff00000,0x0000000800000000)

  to   space 1024K, 0% used [0x00000007ffe00000,0x00000007ffe00000,0x00000007fff00000)

 ParOldGen       total 10240K, used 4096K [0x00000007fec00000, 0x00000007ff600000, 0x00000007ff600000)

  object space 10240K, 40% used [0x00000007fec00000,0x00000007ff000010,0x00000007ff600000)

 PSPermGen       total 21504K, used 2611K [0x00000007f9a00000, 0x00000007faf00000, 0x00000007fec00000)

  object space 21504K, 12% used [0x00000007f9a00000,0x00000007f9c8cc78,0x00000007faf00000)

//前三个对象allocation1,allocation2,allocation3都分配到了,Eden区,第四个4M的直接去了老生代。。。
//-XX:+PretenureSizeThreshold  直接晋升老生代的对象的大小,设置这个参数后,大于这个参数的对象直接在老生代分配。但是!!!请注意!!!PretenureSizeThreshold这个参数只对Serial和parNew有用,Parallel Scavenge不认识他。。


2.Serial+Serial Old(-XX:+UseSerialGC)

[GC[DefNew: 6995K->240K(9216K), 0.0044170 secs] 6995K->6384K(19456K), 0.0044380 secs] [Times: user=0.01 sys=0.01, real=0.01 secs] 

Heap

 def new generation   total 9216K, used 4666K [0x00000007f9a00000, 0x00000007fa400000, 0x00000007fa400000)

  eden space 8192K,  54% used [0x00000007f9a00000, 0x00000007f9e527b0, 0x00000007fa200000)

  from space 1024K,  23% used [0x00000007fa300000, 0x00000007fa33c198, 0x00000007fa400000)

  to   space 1024K,   0% used [0x00000007fa200000, 0x00000007fa200000, 0x00000007fa300000)

 tenured generation   total 10240K, used 6144K [0x00000007fa400000, 0x00000007fae00000, 0x00000007fae00000)

   the space 10240K,  60% used [0x00000007fa400000, 0x00000007faa00030, 0x00000007faa00200, 0x00000007fae00000)

 compacting perm gen  total 21248K, used 2614K [0x00000007fae00000, 0x00000007fc2c0000, 0x0000000800000000)

   the space 21248K,  12% used [0x00000007fae00000, 0x00000007fb08d840, 0x00000007fb08da00, 0x00000007fc2c0000)

No shared spaces configured.

这对组合就是中规中矩的,Eden发现4MB放不下了,触发MinorGC,GC期间发现3个2MB全部无法放到Survivor里面,所以只好通过担保机制提前转移到老年代中去。然后Eden放进了4MB的对象。


3.ParNew + Serial Old(-XX:+UseParNewGC)

[GC[ParNew: 6995K->282K(9216K), 0.0039460 secs] 6995K->6426K(19456K), 0.0039770 secs] [Times: user=0.01 sys=0.01, real=0.00 secs] 

Heap

 par new generation   total 9216K, used 4708K [0x00000007f9a00000, 0x00000007fa400000, 0x00000007fa400000)

  eden space 8192K,  54% used [0x00000007f9a00000, 0x00000007f9e527b0, 0x00000007fa200000)

  from space 1024K,  27% used [0x00000007fa300000, 0x00000007fa346a50, 0x00000007fa400000)

  to   space 1024K,   0% used [0x00000007fa200000, 0x00000007fa200000, 0x00000007fa300000)

 tenured generation   total 10240K, used 6144K [0x00000007fa400000, 0x00000007fae00000, 0x00000007fae00000)

   the space 10240K,  60% used [0x00000007fa400000, 0x00000007faa00030, 0x00000007faa00200, 0x00000007fae00000)

 compacting perm gen  total 21248K, used 2614K [0x00000007fae00000, 0x00000007fc2c0000, 0x0000000800000000)

   the space 21248K,  12% used [0x00000007fae00000, 0x00000007fb08d840, 0x00000007fb08da00, 0x00000007fc2c0000)

No shared spaces configured.


跟上面的差不多。。。


4.Parallel Scavenge + Parallel Old(-XX:+UseParallelOldGC)

Heap

 PSYoungGen      total 9216K, used 7159K [0x00000007ff600000, 0x0000000800000000, 0x0000000800000000)

  eden space 8192K, 87% used [0x00000007ff600000,0x00000007ffcfde20,0x00000007ffe00000)

  from space 1024K, 0% used [0x00000007fff00000,0x00000007fff00000,0x0000000800000000)

  to   space 1024K, 0% used [0x00000007ffe00000,0x00000007ffe00000,0x00000007fff00000)

 ParOldGen       total 10240K, used 4096K [0x00000007fec00000, 0x00000007ff600000, 0x00000007ff600000)

  object space 10240K, 40% used [0x00000007fec00000,0x00000007ff000010,0x00000007ff600000)

 PSPermGen       total 21504K, used 2611K [0x00000007f9a00000, 0x00000007faf00000, 0x00000007fec00000)

  object space 21504K, 12% used [0x00000007f9a00000,0x00000007f9c8cc78,0x00000007faf00000)


parallel Scavenge。。。新分配的4MB去了老生代


5.ParNew + CMS + Serial Old(-XX:+UseConcMarkSweepGC)

[GC[ParNew: 7003K->289K(9216K), 0.0046330 secs] 7003K->6435K(19456K), 0.0046730 secs] [Times: user=0.02 sys=0.01, real=0.00 secs] 

[GC [1 CMS-initial-mark: 6146K(10240K)] 10531K(19456K), 0.0002410 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 

Heap

 par new generation   total 9216K, used 4715K [0x00000007f9a00000, 0x00000007fa400000, 0x00000007fa400000)

  eden space 8192K,  54% used [0x00000007f9a00000, 0x00000007f9e527a8, 0x00000007fa200000)

  from space 1024K,  28% used [0x00000007fa300000, 0x00000007fa348520, 0x00000007fa400000)

  to   space 1024K,   0% used [0x00000007fa200000, 0x00000007fa200000, 0x00000007fa300000)

 concurrent mark-sweep generation total 10240K, used 6146K [0x00000007fa400000, 0x00000007fae00000, 0x00000007fae00000)

 concurrent-mark-sweep perm gen total 21248K, used 2615K [0x00000007fae00000, 0x00000007fc2c0000, 0x0000000800000000)

6MB去了老生代,4MB在新生代,而且,持久代也用了CMS~~~



6.G1(-XX:+UseG1GC)

[GC pause (young) (initial-mark), 0.0014180 secs]

   [Parallel Time: 1.0 ms, GC Workers: 8]

      [GC Worker Start (ms): Min: 120.1, Avg: 120.2, Max: 120.6, Diff: 0.5]

      [Ext Root Scanning (ms): Min: 0.0, Avg: 0.2, Max: 0.4, Diff: 0.4, Sum: 1.9]

      [Code Root Marking (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]

      [Update RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]

         [Processed Buffers: Min: 0, Avg: 1.1, Max: 5, Diff: 5, Sum: 9]

      [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]

      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]

      [Object Copy (ms): Min: 0.4, Avg: 0.5, Max: 0.6, Diff: 0.2, Sum: 3.7]

      [Termination (ms): Min: 0.0, Avg: 0.1, Max: 0.1, Diff: 0.1, Sum: 0.6]

      [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.1, Diff: 0.1, Sum: 0.3]

      [GC Worker Total (ms): Min: 0.5, Avg: 0.8, Max: 1.0, Diff: 0.5, Sum: 6.6]

      [GC Worker End (ms): Min: 121.0, Avg: 121.1, Max: 121.1, Diff: 0.1]

   [Code Root Fixup: 0.0 ms]

   [Code Root Migration: 0.0 ms]

   [Clear CT: 0.1 ms]

   [Other: 0.3 ms]

      [Choose CSet: 0.0 ms]

      [Ref Proc: 0.2 ms]

      [Ref Enq: 0.0 ms]

      [Free CSet: 0.0 ms]

   [Eden: 1024.0K(10.0M)->0.0B(9216.0K) Survivors: 0.0B->1024.0K Heap: 6588.3K(20.0M)->6560.0K(20.0M)]

 [Times: user=0.01 sys=0.01, real=0.00 secs] 

[GC concurrent-root-region-scan-start] 第一阶段开始,初始标记

[GC concurrent-root-region-scan-end, 0.0002720 secs]初始标记完毕

[GC concurrent-mark-start]    并发标记

[GC concurrent-mark-end, 0.0000430 secs]

[GC remark [GC ref-proc, 0.0000610 secs], 0.0005240 secs]  重新标记

 [Times: user=0.00 sys=0.00, real=0.01 secs] 

[GC cleanup 10M->10M(20M), 0.0004140 secs]   筛选回收,就是清理

 [Times: user=0.00 sys=0.00, real=0.00 secs] 

Heap

 garbage-first heap   total 20480K, used 10656K [0x00000007f9a00000, 0x00000007fae00000, 0x00000007fae00000)

  region size 1024K, 2 young (2048K), 1 survivors (1024K)

 compacting perm gen  total 20480K, used 2614K [0x00000007fae00000, 0x00000007fc200000, 0x0000000800000000)

   the space 20480K,  12% used [0x00000007fae00000, 0x00000007fb08d840, 0x00000007fb08da00, 0x00000007fc200000)

No shared spaces configured.

其实我也知道这样测G1什么也测不出什么特性来,我就是好奇。。。玩玩~

首先,发现G1的时间很棒哎~其他的都是0.004.。。G1:0.001

region size 1024K

 Heap: 6588.3K(20.0M)->6560.0K(20.0M)。。。我很想知道我的4MB去哪了。。。
garbage-first heap   total 20480K, used 10656K 只能在这看到10M是全的。。。
这里我会更新的。


另外,由于-XX:+UseParallelGC和-XX:+UseParallelOldGC看上去效果差不多,大R解释:
只用UseParallelGC与用了UseParallelOldGC背后实际的collector不一样,前者在HotSpot VM内是PSMarkSweep,后者是PSParallelCompact。 
http://hllvm.group.iteye.com/group/topic/37945

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
为什么要学JVM1、一切JAVA代码都运行在JVM之上,只有深入理解虚拟机才能写出更强大的代码,解决更深层次的问题。2、JVM是迈向高级工程师、架构师的必备技能,也是高薪、高职位的不二选择。3、同时,JVM又是各大软件公司笔试、面试的重中之重,据统计,头部的30家互利网公司,均将JVM作为笔试面试的内容之一。4、JVM内容庞大、并且复杂难学,通过视频学习是最快速的学习手段。课程介绍本课程包含11个大章节,总计102课时,无论是笔试、面试,还是日常工作,可以让您游刃有余。第1章 基础入门,从JVM是什么开始讲起,理解JDK、JRE、JVM的关系,java的编译流程和执行流程,让您轻松入门。第2章 字节码文件,深入剖析字节码文件的全部组成结构,以及javap和jbe可视化反解析工具的使用。第3章 类的加载、解释、编译,本章节带你深入理解类加载的分类、范围、双亲委托策略,自己手写类加载,理解字节码解释、即时编译、混合模式、热点代码检测、分层编译等核心知识。第4章 内存模型,本章节涵盖JVM内存模型的全部内容,程序计数、虚拟机栈、本地方法栈、方法区、永久代、元空间等全部内容。第5章 对象模型,本章节带你深入理解对象的创建过程、内存分配的方法、让你不再稀里糊涂。第6章 GC基础,本章节是垃圾回收的入门章节,带你了解GC回收的标准是什么,什么是可达性分析、安全点、安全区,四种引用类型的使用和区别等等。第7章 GC算法与收集,本章节是垃圾回收的重点,掌握各种垃圾回收算法,分代收集策略,7种垃圾回收的原理和使用,垃圾回收组合及分代收集等。第8章 GC日志详解,各种垃圾回收的日志都是不同的,怎么样读懂各种垃圾回收日志就是本章节的内容。第9章 性能监控与故障排除,本章节实战学习jcmd、jmx、jconsul、jvisualvm、JMC、jps、jstatd、jmap、jstack、jinfo、jprofile、jhat总计12种性能监控和故障排查工具的使用。第10章 阿里巴巴Arthas在线诊断工具,这是一个特别小惊喜,教您怎样使用当前最火热的arthas调优工具,在线诊断各种JVM问题。第11章 故障排除,本章会使用实际案例讲解单点故障、高并发和垃圾回收导致的CPU过高的问题,怎样排查和解决它们。课程资料课程附带配套项目源码2个159页高清PDF理论篇课件1份89页高清PDF实战篇课件1份Unsafe源码PDF课件1份class_stats字段说明PDF文件1份jcmd Thread.print解析说明文件1份JProfiler内存工具说明文件1份字节码可视化解析工具1份GC日志可视化工具1份命令行工具cmder 1份学习方法理论篇部分推荐每天学习2课时,可以在公交地铁上用手机进行学习。实战篇部分推荐对照视频,使用配套源码,一边练习一遍学习。课程内容较多,不要一次性学太多,而是要循序渐进,坚持学习。      
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值