GC对吞吐量的影响
- - Java译站在看 内存管理术语表的时候偶然发现了” Pig in the Python（注：有点像中文里的贪心不足蛇吞象）”的定义，于是便有了这篇文章. 表面上看，这个术语说的是GC不停地将大对象从一个分代提升到另一个分代的情景. 这么做就好比巨蟒整个吞食掉它的猎物，以至于它在消化的时候都没办法移动了. 在接下来的这24个小时里我的头脑中充斥着这个令人窒息的巨蟒的画面，挥之不去.
GC对吞吐量的影响
标签：
gc
吞吐量
| 发表时间：2014-09-22 08:16 | 作者：
出处：http://it.deepinmind.com
在看 内存管理术语表的时候偶然发现了” Pig in the Python（注：有点像中文里的贪心不足蛇吞象）”的定义，于是便有了这篇文章。表面上看，这个术语说的是GC不停地将大对象从一个分代提升到另一个分代的情景。这么做就好比巨蟒整个吞食掉它的猎物，以至于它在消化的时候都没办法移动了。
在接下来的这24个小时里我的头脑中充斥着这个令人窒息的巨蟒的画面，挥之不去。正如精神病医生所说的，消除恐惧最好的方法就是说出来。于是便有了这篇文章。不过接下的故事我们要讲的不是蟒蛇，而是GC的调优。我对天发誓。
大家都知道GC暂停很容易造成性能瓶颈。现代JVM在发布的时候都自带了高级的垃圾回收器，不过从我的使用经验来看，要找出某个应用最优的配置真是难上加难。手动调优或许仍有一线希望，但是你得了解GC算法的确切机制才行。关于这点，本文倒是会对你有所帮助，下面我会通过一个例子来讲解JVM配置的一个小的改动是如何影响到你的应用程序的吞吐量的。
示例
我们用来演示GC对吞吐量产生影响的应用只是一个简单的程序。它包含两个线程：
-
PigEater - 它会模仿巨蟒不停吞食大肥猪的过程。代码是通过往java.util.List中添加 32MB字节来实现这点的，每次吞食完后会睡眠100ms。
-
PigDigester - 它模拟异步消化的过程。实现消化的代码只是将猪的列表置为空。由于这是个很累的过程，因此每次清除完引用后这个线程都会睡眠2000ms。
两个线程都会在一个while循环中运行，不停地吃了消化直到蛇吃饱为止。这大概得吃掉5000头猪。
package eu.plumbr.demo;
public class PigInThePython {
static volatile List pigs = new ArrayList();
static volatile int pigsEaten = 0;
static final int ENOUGH_PIGS = 5000;
public static void main(String[] args) throws InterruptedException {
new PigEater().start();
new PigDigester().start();
}
static class PigEater extends Thread {
@Override
public void run() {
while (true) {
pigs.add(new byte[32 * 1024 * 1024]); //32MB per pig
if (pigsEaten > ENOUGH_PIGS) return;
takeANap(100);
}
}
}
static class PigDigester extends Thread {
@Override
public void run() {
long start = System.currentTimeMillis();
while (true) {
takeANap(2000);
pigsEaten+=pigs.size();
pigs = new ArrayList();
if (pigsEaten > ENOUGH_PIGS) {
System.out.format("Digested %d pigs in %d ms.%n",pigsEaten, System.currentTimeMillis()-start);
return;
}
}
}
}
static void takeANap(int ms) {
try {
Thread.sleep(ms);
} catch (Exception e) {
e.printStackTrace();
}
}
}
现在我们将这个系统的吞吐量定义为“每秒可以消化的猪的头数”。考虑到每100ms就会有猪被塞到这条蟒蛇里，我们可以看到这个系统理论上的最大吞吐量可以达到10头/秒。
GC配置示例
我们来看下使用两个不同的配置系统的表现分别是什么样的。不管是哪个配置，应用都运行在一台拥有双核，8GB内存的Mac（OS X10.9.3）上。
第一个配置：
- 4G的堆（-Xms4g -Xmx4g）
- 使用CMS来清理年老代（-XX:+UseConcMarkSweepGC）使用并行回收器清理新生代（-XX:+UseParNewGC）
- 将堆的12.5%（-Xmn512m）分配给新生代，并将Eden区和Survivor区的大小限制为一样的。
第二个配置则略有不同：
- 2G的堆（-Xms2g -Xms2g）
- 新生代和年老代都使用Parellel GC(-XX:+UseParallelGC)
- 将堆的75%分配给新生代（-Xmn 1536m）
现在是该下注的时候了，哪个配置的表现会更好一些(就是每秒能吃多少猪，还记得吧)？那些把筹码放到第一个配置上的家伙，你们一定会失望的。结果正好相反：
- 第一个配置（大堆，大的年老代，CMS GC）每秒能吞食8.2头猪
- 第二个配置（小堆，大的新生代，Parellel GC）每秒可以吞食9.2头猪
现在我们来客观地看待一下这个结果。分配的资源少了2倍但吞吐量提升了12%。这和常识正好相反，因此有必要进一步分析下到底发生了什么。
分析GC的结果
原因其实并不复杂，你只要仔细看一下运行测试的时候GC在干什么就能发现答案了。这个你可以自己选择要使用的工具。在jstat的帮助下我发现了背后的秘密，命令大概是这样的：
jstat -gc -t -h20 PID 1s
通过分析数据，我注意到配置1经历了1129次GC周期（YGCT_FGCT），总共花了63.723秒：
Timestamp S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT
594.0 174720.0 174720.0 163844.1 0.0 174848.0 131074.1 3670016.0 2621693.5 21248.0 2580.9 1006 63.182 116 0.236 63.419
595.0 174720.0 174720.0 163842.1 0.0 174848.0 65538.0 3670016.0 3047677.9 21248.0 2580.9 1008 63.310 117 0.236 63.546
596.1 174720.0 174720.0 98308.0 163842.1 174848.0 163844.2 3670016.0 491772.9 21248.0 2580.9 1010 63.354 118 0.240 63.595
597.0 174720.0 174720.0 0.0 163840.1 174848.0 131074.1 3670016.0 688380.1 21248.0 2580.9 1011 63.482 118 0.240 63.723
第二个配置一共暂停了168次（YGCT+FGCT），只花了11.409秒。
Timestamp S0C S1C S0U S1U EC EU OC OU PC PU YGC YGCT FGC FGCT GCT
539.3 164352.0 164352.0 0.0 0.0 1211904.0 98306.0 524288.0 164352.2 21504.0 2579.2 27 2.969 141 8.441 11.409
540.3 164352.0 164352.0 0.0 0.0 1211904.0 425986.2 524288.0 164352.2 21504.0 2579.2 27 2.969 141 8.441 11.409
541.4 164352.0 164352.0 0.0 0.0 1211904.0 720900.4 524288.0 164352.2 21504.0 2579.2 27 2.969 141 8.441 11.409
542.3 164352.0 164352.0 0.0 0.0 1211904.0 1015812.6 524288.0 164352.2 21504.0 2579.2 27 2.969 141 8.441 11.409
考虑到两种情况下的工作量是等同的，因此——在这个吃猪的实验中当GC没有发现长期存活的对象时，它能更快地清理掉垃圾对象。而采用第一个配置的话，GC运行的频率大概会是6到7倍之多，而总的暂停时间则是5至6倍。
说这个故事有两个目的。第一个也是最主要的一个，我希望把这条抽风的蟒蛇赶紧从我的脑海里赶出去。另一个更明显的收获就是——GC调优是个很需要技巧的经验活，它需要你对底层的这些概念了如指掌。尽管本文中用到的这个只是很平常的一个应用，但选择的不同结果也会对你的吞吐量和容量规划产生很大的影响。在现实生活中的应用里面，这里的区别则会更为巨大。因此，就看你如何抉择了，你可以去掌握这些概念，或者，只关注你日常的工作就好了，让Plumbr来找出你所需要的最合适的 GC配置吧。
原创文章转载请注明出处： GC对吞吐量的影响
相关 [gc 吞吐量] 推荐：
Java GC 调优
- - Darktea关于 Java GC 已经有很多好的文档了, 比如这些:. 但是这里还是想再重点整理一下 Java GC 日志的格式, 可以作为实战时的备忘录.. 同时也会再整理一下各种概念. 一, JDK 6 提供的各种垃圾收集器. 先整理一下各种垃圾收集器.. 新生代收集器: Serial, ParNew, Parallel Scavenge (MaxGCPauseMillis vs.
[译]GC专家系列3-GC调优
- - SegmentFault 最新的文章原文链接： http://www.cubrid.org/blog/dev-platform/how-to-tune-java-garbage-collection/. 本篇是”GC专家系列“的第三篇. 在第一篇 理解Java垃圾回收中我们学习了几种不同的GC算法的处理过程，GC的工作方式，新生代与老年代的区别.
GC 日志分析
- - 码蜂笔记不同的JVM及其选项会输出不同的日志. 生成下面日志使用的选项： -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:d:/GClogs/tomcat6-gc.log. 最前面的数字 4.231 和 4.445 代表虚拟机启动以来的秒数.
初级分代GC
- - C++博客-首页原创精华区通常情况下GC分为两种，分别是：扫描GC(Tracing GC)和引用计数GC(Reference counting GC). 其中扫描GC是比较常用的GC实现方法，其原理是：把正在使用的对象找出来，然后把未被使用的对象释放. 而引用计数GC则是对每个对象都添加一个计数器，引用增加一个计数器就加一，引用减少一个计数器就减一，当计数器减至零时，把对象回收释放.
一个GC频繁的Case
- loudly - BlueDavy之技术Blog前两天碰到一个很诡异的GC频繁的现象，走了不少弯路，N种方法查找后才终于查明原因了，在这篇blog中记录下，以便以后碰到这类问题时能更快的解决. 前两天一位同学找到我，说有个应用在启动后就一直Full GC，拿到GC log先看了下，确实是非常的诡异，截取的部分log如下：. 这个日志中诡异的地方在于每次Full GC的时候旧生代都还有很多的空间，于是去看来下启动参数，此时的启动参数如下：.
Java GC日志查看
- - Java - 编程语言 - ITeye博客Java中的GC有哪几种类型. 虚拟机运行在Client模式的默认值，打开此开关参数后，. 使用Serial+Serial Old收集器组合进行垃圾收集. 打开此开关参数后，使用ParNew+Serial Old收集器组合进行垃圾收集. 打开此开关参数后，使用ParNew+CMS+Serial Old收集器组合进行垃圾收集.
GC的基本算法
- - 非技术 - ITeye博客1、引用计数（reference counting）. 原理：此对象有一个引用，则+1；删除一个引用，则-1. 缺点：无法处理循环引用的问题. 对象A和B分别有字段b、a，令A.b=B和B.a=A，除此之外这2个对象再无任何引用，那实际上这2个对象已经不可能再被访问，但是引用计数算法却无法回收他们.
CMS gc实践总结
- - 编程语言 - ITeye博客声明：原文转自http://www.blogjava.net/killme2008/archive/2009/09/22/295931.html，该文所有合法权益归原作者所有，仅在此做技术分享使用. 首先感谢阿宝同学的帮助，我才对这个gc算法的调整有了一定的认识，而不是停留在过去仅仅了解的阶段. 在读过sun的文档和跟阿宝讨论之后，做个小小的总结.
面向GC的Java编程
- - 并发编程网 - ifeve.comJava程序员在编码过程中通常不需要考虑内存问题，JVM经过高度优化的GC机制大部分情况下都能够很好地处理堆(Heap)的清理问题. 以至于许多Java程序员认为，我只需要关心何时创建对象，而回收对象，就交给GC来做吧. 甚至有人说，如果在编程过程中频繁考虑内存问题，是一种退化，这些事情应该交给编译器，交给虚拟机来解决.