标签：through size client模式 max tag 垃圾收集 计算 线程 作用
通过学习了解到现在商用的JVM中的垃圾收集采用的是分代收集算法，即针对不同年代采用不同的收集算法。在JVM中，GC主要作用于堆内存中，堆内存又被划分为新生代和老年代，由于新生代对象绝大多数是朝生夕死，而老年代相对存活时间就很长，故而需要使用不同的垃圾收集机制，所以垃圾收集器也就分为新生代收集器和老年代收集器，两者相互组合进行JVM堆内存的空间回收（下图中相连的垃圾收集器表示可以相互组合，注意Serial Old和CMS也可以联合进行老年代的垃圾收集）。JDK6u14中开始测试的G1垃圾收集器，正式发布于JDK7u4中，是目前唯一不需要依赖其他垃圾收集器即可完成新生代和老年代内存收集。阅读之前先了解，GC的两个指标：暂停时间-应对与存在大量用户交互的场景；吞吐量-应对后台计算任务。
笔者使用的是JDK7u51，也就是JDK1.7.0_51
下面我将试着通过自己的理解来分析各个垃圾收集器的特点，目前并没有一个适用于任何场景的垃圾收集器，所以选择何种垃圾收集器进行配合是根据具体应用来区别对待的，那么了解各种垃圾收集器的特点以及他们之间是否可以相互配合，就十分重要了。
垃圾收集器运行过程中必然会发生“Stop the world”，只是时间长短和暂停时间可不可控的区别。
在进行下面的阅读之前，首先明确在垃圾收集器中，“并发”和“并行”这两个概念的差别：
Serial垃圾收集器，通过这个单词的意思“连续”，我认为这个应该是指的GC之后内存空间不存在内存碎片的意思，那么必然不会采用“标记-清除算法”来实现，所以这个垃圾收集器在新生代使用的是“复制算法”，而Serial Old作为Serail收集器的老年代版本，使用的就是“标记-整理算法”。
为什么先说Serial垃圾收集器，是因为这个收集器是最基本、历史最悠久的收集器，在JDK1.3.1之前，是JVM新生代收集的唯一选择。Serial收集器是一个单线程的收集器，这个“单线程”是指JVM在使用它进行GC的时候，必须暂停其他所有的工作线程（sun将这件事情称为“Stop the world”），直到GC完成，这是一件非常可怕的事情。看到这里，你可能想我一定要修改我的JVM的新生代收集器，不用Serial了，但是直至现在，Serial依然是JVM在运行Client模式下默认的新生代 收集器。与其他垃圾收集器的单线程相比，Serial简单而高效。对于用户桌面应用场景来说，分配给JVM的内存一般不会太大，收集十几甚至一两百兆的内存，停顿时间可以控制在几十毫秒，最多一百多毫秒以内，只要不是特别频繁，这些停顿还是可以接受的。所以，对于Client模式下的JVM来说，Serial是个很好的新生代收集器，简单高效。
ParNew收集器也是一个新生代收集器，其实就是Serial收集器的多线程版本，是一个“并行”的垃圾收集器，除了多线程外，其他和Serial差不多。想想也就明白了，当JVM团队开发出来了Serial，可以满足Client模式下的JVM，但是对于Server模式下的JVM来说，运行很长时间，有很多的对象需要收集（可能几十个G），单线程导致的停顿时间太长了（比如每运行1小时需要停顿5分钟），用户无法接受业务线程停顿那么长的时间，我猜测这种情况下那些大牛能想到的最简单的办法就是让Serial变成多线程，这样开多个线程就可以有效的降低停顿时间，故而这个Serial的多线程版本也就诞生了。
ParNew是许多运行在Server模式下的JVM中首选的垃圾收集器，其中一个重要原因就是除了Serial，它是唯一可以和CMS（Concurrent Mark Sweep）老年代垃圾收集器配合工作。
ParNew在单CPU环境中收集效果不如Serial收集器，但是随着CPU的增加，它对于GC时系统资源的利用还是很有好处的，默认开启的线程数与CPU的数量一致 。
Parallel Scavenge收集器，简称PS收集器，它和ParNew收集器一样是一个多线程的并行新生代垃圾收集器，一样采用“复制算法”（始发于JDK1.4.0）。那为什么还要这个PS收集器呢？现在想一下，ParNew收集器为什么会产生，不就是闲Serial收集器导致的“Stop the world”的时间太长了嘛，搞个多线程，减少停顿时间。这种的垃圾收集器适合重视服务的响应速度的应用程序（比如购物网站，肯定希望停顿时间越短越好，这样用户体验才好），但是对于一个后台计算任务（比如MapReduce）来说，没有太多的交互任务，那么它所重视的就不是这种响应速度，而是CPU的有效时间利用率（这是我的理解），官方称之为“吞吐量（Throughtput）”。吞吐量就是指CPU用来运行用户代码的时间和CPU的总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+GC消耗的时间）。
Parallel Scavenge收集器正是基于对“吞吐量”的追求而产生的，它的目标就是达到一个可控的吞吐量。由于与吞吐量关系密切，Parallel Scavenge收集器也被称为“吞吐量优先“收集器。Parallel Scavenge提供了两个参数用来精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX：MaxGCPauseMillis参数（单位：毫秒），以及直接设置吞吐量大小的-XX：GCTimeRatio参数（0-100之间，不包括首尾）。GCTimeRatio参数的计算规则是，比如设成19，那么允许最大时间就占总时间的5%，即1/（1+19），默认值是99，也就是默认允许最大GC时间占比是1%。
Parallel Scavenge收集器还有一个参数来开启GC的自适应调节策略，只需要将JVM基本内存设置好，并且制定上述两个参数中的一个来作为JVM的优化目标，那么JVM就可以根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大吞吐量，这个参数就是-XX：+UseAdaptiveSizePolicy。自适应调节策略也是PS收集器 相对于ParNew收集器的一个重要区别。ParNew收集器需要手工指定新生代大小（-Xmn）、Eden与Survivor的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数。
Parallel Old是Parallel Scavenge收集器的老年代版本，简称PS Old，使用了多线程和”标记-整理“算法，这个收集器是在JDK1.6中才提供的，在此之前PS new的地位比较尴尬，因为在此之前老年代的垃圾回收只有Serial Old这一种收集器，与Serial Old配合，Parallel Scavenge无法产生理想的回收效果，吞吐量在老年代很大且硬件比较高级的环境中可能还不如使用ParNew与CMS的组合”给力“，而PS Old产生之后，PS New才变得名副其实。
也就是说，在JDK1.6及之后，在注重吞吐量和CPU资源敏感的场合，都可以优先考虑PS New和PS Old的组合。
在JDK6u14中提供了Early Access版本的G1收集器以供试用，直到JDK7u4的时候才正式发布。G1是一款面向服务端应用的垃圾收集器，HotSpot开发团队赋予它的使命是未来替换掉CMS收集器，从这点上看，G1也是追求短停顿时间的。
G1收集器与上述的6种收集器相比，具有以下的特点：
G1最大的特点在我看来就是G1将Java堆划分成多个大小相等的独立区域（Region），虽然保留了新生代和老年代的概念，但是它们已经不再是物理隔离了，而都是一部分Region的集合。G1在后台维护一个 优先列表，这个列表中保存了G1收集到的各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收需要的时间的经验值），当需要进行垃圾回收的时候，根据用户允许的收集时间，优先回收列表中价值最大的那个Region（这就是Garbage-First，G1名字的由来）。这种使用Region划分空间以及根据优先级的区域回收方式，保证了G1收集器可以在有效的时间内获得尽可能高的收集效率，同时也避免了在整个JAVA堆中进行全区域的垃圾收集。
G1产生的原因我认为就是HotSpot团队对于低延时和吞吐量两者同时考虑，不断追求一个完美的垃圾收集器的产物，虽然在执行流程上和CMS有差不多，并且在初始标记和最终标记阶段都需要暂停用户线程，但是通过重新定义JAVA堆，引出了Region的概念，成功的让其在性能上能兼顾到低延时和吞吐量，且不需要依赖其他收集器。G1的未来就是优化初始标记和最终标记阶段，如果能解决这两个阶段的用户线程暂停，实现并发，那么就很有可能产生一个近似理想状态的一个垃圾收集器。
不过用户对于新生事物必须的认同需要一定的时间，并且之前垃圾收集器相互配合也可以满足用户需求，那么G1对于大多数公司来说不是必需品，但是，随着技术的不断成熟，我认为G1很有可能成为Server模式下的HotSpot默认的收集器。
对于G1收集器，可以参考：http://f.dataguru.cn/thread-514678-1-1.html
标签：through size client模式 max tag 垃圾收集 计算 线程 作用
原文地址：http://www.cnblogs.com/printN/p/6901671.html
