gc的两个作用：一个是回收对象，一个是处理堆碎块。。。
根对象的集合：局部变量的对象引用
栈帧里面的对象引用，类变量里面的对象引用。类常量池的对象应用。
本地方法的对象引用。
gc 判断的垃圾对象的方法是 计数和跟踪。。
-XX:-PrintGC Print messages at garbage collection. Manageable.
-XX:-PrintGC Details Print more details at garbage collection. Manageable. (Introduced in 1.4.0.)
-XX:-PrintGCTimeStamps Print timestamps at garbage collection. Manageable (Introduced in 1.4.0.)
写了好几篇关于这个方向的文章了，但连自己都感觉写的有点乱，没有总结。所以现在把所有方法整理到一起，如果以后又发现新的，我继续补充到这篇文章里。
这篇是技巧性的文章，如果要找关于GC或者调整内纯的文章，看我其他几篇文章。因为是JVM 调优总结，所以废话少说。从各方面一共收集到以下几个方法：
1.升级 JVM 版本。如果能使用64-bit，使用64-bit JVM。
基本上没什么好解释的，很简单将JVM升级到最新的版本。如果你还是使用JDK1.4甚至是更早的JVM，那你首先要做的就是升级。因为JVM从1.4- >1.5->1.6可不是仅仅的版本号升级，或者仅仅往里面加了一堆新的语言特性，这么简单。而是真正在JVM做了重大的改进，每次版本升级，都有巨大的性能升级。尤其是ＳＵＮ认识到ｊａｖａ是知己的全部的时候（夸张点，但连股票号都改成ＪＡＶＡ了，呵呵）。如果你经常逛SUN 的JVM论坛，你就会发现实际上JVM上的毛病是这么多。如果你因为各种原因，而不能升级到1.6，那你可以升级到该版本的最新版。
2.选择一个正确的GC（Gargage Collection）。
由于当JAVA程序GC的时候，会停下当前程序。尤其Full GC的时候，会停留很长时间。一般对于GUI程序来说，是很难接受的（想想Eclipse暂停的时候）。 JAVA5 以后，开始自带了好几种GC，你可以选择一个适合你的种类。有以下四种Serial Collector，Parallel collector，Concurrent Collector，Train Collector（废弃）。后面几种时候使用并行收集，所以理论上有效率更高（要求你有超过2CUP，但是现在多核开始普及了，呵呵）。提示：更改GC 种类以后要适当挺高JVM的内存量。
3.正确设置内存大小。对JVM堆内的各个区域（young,old,perm）正确设置大小。
这个是最困难的调整，因为这个调整会直接影响GC的效率。而且由于各个程序的类型不用，所以没有一个通用的数据。除了几个常用规则以外，需要使用工具（jstat,jvmstat,jconsole等等）仔细调整。下面会提到几个常用的准则。通常使用一下几个参数调整-Xms -Xmx-XX:MaxPermSize。
3.1 调高-XX:NewRatio（NewSize/MaxNewSize）的值，会减少young gc的次数，但会增加old gc的时间。
3.2 增加普通GC的方法（减小Full GC）。扩大young区域的大小（最大40%），并过大Survivor的区域。使得更多的object留在young gen。
4.减小类的使用量，注意类的load和unload，减少JSP页数。
类实际上也是对象，会直接分配perm区域里，即使Full GC也会很少收集。JSP也会分配到perm区域里，效果同理。如果perm过大，超过XX:MaxPermSize值，会发生 OutOfMemoryError: PermGen space异常。解决方法是提高-XX:MaxPermSize值。
5.避免使用-Xnoclassgc
6.如果是RMI程序，要注意调整RMI DGC的时间。
以下是几个写程序时，应该注意的地方。也可减小GC，提高JVM性能。
1.不要使用System.gc()方法。
因为它会产生Full GC。
2.尽可能少分配大的临时对象（生命周期短的）
可能会直接分配到old区域里，old区域只有Full GC的时候会收集。
3.避免使用finalize()方法。
finalize()会增加GC的负担，使用java.lang.ref代替。
JDK5.0垃圾收集优化之--Don't Pause
作者：江南白衣，最新版链接：http://blog.csdn.net/calvinxiu/archive/2007/05/18/1614473.aspx，版权所有，转载请保留原文链接。
原本想把题目更简单的定为--《不要停》的，但还是自己YY一下就算了。
Java开发Server最大的障碍，就是JDK1.4版之前的的串行垃圾收集机制会引起长时间的服务暂停，明白原理后，想想那些用JDK1.3写Server的先辈，不得不后怕。
好在JDK1.4已开始支持多线程并行的后台垃圾收集算法，JDK5.0则优化了默认值的设置。
一、参考资料：
1. Tuning Garbage Collection with the 5.0 Java Virtual Machine 官方指南。
2. Hotspot memory management whitepaper 官方白皮书。
3. Java Tuning White Paper 官方文档。
4. FAQ about Garbage Collection in the Hotspot 官方FAQ，JVM1.4.2。
5. Java HotSpot 虚拟机中的垃圾收集 JavaOne2004上的中文ppt
6. A Collection of JVM Options JVM选项的超完整收集。
二、基本概念
1、堆(Heap)
JVM管理的内存叫堆。在32Bit操作系统上有1.5G-2G的限制，而64Bit的就没有。
JVM初始分配的内存由-Xms指定，默认是物理内存的1/64但小于1G。
JVM最大分配的内存由-Xmx指定，默认是物理内存的1/4但小于1G。
默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制，可以由-XX:MinHeapFreeRatio=指定。
默认空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制，可以由-XX:MaxHeapFreeRatio=指定。
服务器一般设置-Xms、-Xmx相等以避免在每次GC 后调整堆的大小，所以上面的两个参数没啥用。
2.基本收集算法
1. 复制：将堆内分成两个相同空间，从根(ThreadLocal的对象，静态对象）开始访问每一个关联的活跃对象，将空间A的活跃对象全部复制到空间B，然后一次性回收整个空间A。
因为只访问活跃对象，将所有活动对象复制走之后就清空整个空间，不用去访问死对象，所以遍历空间的成本较小，但需要巨大的复制成本和较多的内存。
2. 标记清除(mark-sweep)：收集器先从根开始访问所有活跃对象，标记为活跃对象。然后再遍历一次整个内存区域，把所有没有标记活跃的对象进行回收处理。该算法遍历整个空间的成本较大暂停时间随空间大小线性增大，而且整理后堆里的碎片很多。
3. 标记整理(mark-sweep-compact)：综合了上述两者的做法和优点，先标记活跃对象，然后将其合并成较大的内存块。
可见，没有免费的午餐，无论采用复制还是标记清除算法，自动的东西都要付出很大的性能代价。
3.分代
分代是Java垃圾收集的一大亮点，根据对象的生命周期长短，把堆分为3个代：Young，Old和Permanent，根据不同代的特点采用不同的收集算法，扬长避短也。
Young(Nursery)，年轻代。研究表明大部分对象都是朝生暮死，随生随灭的。因此所有收集器都为年轻代选择了复制算法。
复制算法优点是只访问活跃对象，缺点是复制成本高。因为年轻代只有少量的对象能熬到垃圾收集，因此只需少量的复制成本。而且复制收集器只访问活跃对象，对那些占了最大比率的死对象视而不见，充分发挥了它遍历空间成本低的优点。
Young的默认值为4M，随堆内存增大，约为1/15，JVM会根据情况动态管理其大小变化。
-XX:NewRatio= 参数可以设置Young与Old的大小比例，-server时默认为1:2，但实际上young启动时远低于这个比率？如果信不过JVM，也可以用-Xmn硬性规定其大小，有文档推荐设为Heap总大小的1/4。
Young的大小非常非常重要，见“后面暂停时间优先收集器”的论述。
Young里面又分为3个区域，一个Eden，所有新建对象都会存在于该区，两个Survivor区，用来实施复制算法。每次复制就是将Eden和第一块 Survior的活对象复制到第2块，然后清空Eden与第一块Survior。Eden与Survivor的比例由-XX:SurvivorRatio =设置，默认为32。Survivio大了会浪费，小了的话，会使一些年轻对象潜逃到老人区，引起老人区的不安，但这个参数对性能并不重要。
Old(Tenured)，年老代。年轻代的对象如果能够挺过数次收集，就会进入老人区。老人区使用标记整理算法。因为老人区的对象都没那么容易死的，采用复制算法就要反复的复制对象，很不合算，只好采用标记清理算法，但标记清理算法其实也不轻松，每次都要遍历区域内所有对象，所以还是没有免费的午餐啊。
-XX:MaxTenuringThreshold=设置熬过年轻代多少次收集后移入老人区，CMS中默认为0，熬过第一次GC就转入，可以用-XX:+PrintTenuringDistribution查看。
Permanent，持久代。装载Class信息等基础数据，默认64M，如果是类很多很多的服务程序，需要加大其设置-XX:MaxPermSize=，否则它满了之后会引起fullgc()或Out of Memory。注意Spring，Hibernate这类喜欢AOP动态生成类的框架需要更多的持久代内存。
4.minor/major collection
每个代满了之后都会促发collection，（另外Concurrent Low Pause Collector默认在老人区68%的时候促发)。GC用较高的频率对young进行扫描和回收，这种叫做minor collection。
而因为成本关系对Old的检查回收频率要低很多，同时对Young和Old的收集称为major collection。
System.gc()会引发major collection，使用-XX:+DisableExplicitGC禁止它，或设为CMS并发-XX:+ExplicitGCInvokesConcurrent。
5.小结
Young -- minor collection -- 复制算法
Old(Tenured) -- major colletion -- 标记清除/标记整理算法
三、收集器
1.古老的串行收集器(Serial Collector)
使用 -XX:+UseSerialGC，策略为年轻代串行复制，年老代串行标记整理。
2.吞吐量优先的并行收集器(Throughput Collector)
使用 -XX:+UseParallelGC ，也是JDK5 -server的默认值。策略为：
1.年轻代暂停应用程序，多个垃圾收集线程并行的复制收集，线程数默认为CPU个数，CPU很多时，可用–XX:ParallelGCThreads=减少线程数。
2.年老代暂停应用程序，与串行收集器一样，单垃圾收集线程标记整理。
所以需要2+的CPU时才会优于串行收集器，适用于后台处理，科学计算。
可以使用-XX:MaxGCPauseMillis= 和 -XX:GCTimeRatio 来调整GC的时间。
3.暂停时间优先的并发收集器(Concurrent Low Pause Collector-CMS)
前面说了这么多，都是为了这节做铺垫......
使用-XX:+UseConcMarkSweepGC，策略为：
1.年轻代同样是暂停应用程序，多个垃圾收集线程并行的复制收集。
2.年老代则只有两次短暂停，其他时间应用程序与收集线程并发的清除。
3.1 年老代详述
并行(Parallel)与并发(Concurrent)仅一字之差，并行指多条垃圾收集线程并行，并发指用户线程与垃圾收集线程并发，程序在继续运行，而垃圾收集程序运行于另一个个CPU上。
并发收集一开始会很短暂的停止一次所有线程来开始初始标记根对象，然后标记线程与应用线程一起并发运行，最后又很短的暂停一次，多线程并行的重新标记之前可能因为并发而漏掉的对象，然后就开始与应用程序并发的清除过程。可见，最长的两个遍历过程都是与应用程序并发执行的，比以前的串行算法改进太多太多了！！！
串行标记清除是等年老代满了再开始收集的，而并发收集因为要与应用程序一起运行，如果满了才收集，应用程序就无内存可用，所以系统默认68%满的时候就开始收集。内存已设得较大，吃内存又没有这么快的时候，可以用-XX:CMSInitiatingOccupancyFraction=恰当增大该比率。
3.2 年轻代详述
可惜对年轻代的复制收集，依然必须停止所有应用程序线程，原理如此，只能靠多CPU，多收集线程并发来提高收集速度，但除非你的Server 独占整台服务器，否则如果服务器上本身还有很多其他线程时，切换起来速度就..... 所以，搞到最后，暂停时间的瓶颈就落在了年轻代的复制算法上。
因此Young的大小设置挺重要的，大点就不用频繁GC，而且增大GC的间隔后，可以让多点对象自己死掉而不用复制了。但Young增大时，GC造成的停顿时间攀升得非常恐怖，比如在我的机器上，默认8M的Young，只需要几毫秒的时间，64M就升到90毫秒，而升到256M时，就要到300毫秒了，峰值还会攀到恐怖的800ms。谁叫复制算法，要等Young满了才开始收集，开始收集就要停止所有线程呢。
3.3 持久代
可设置-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled，使CMS收集持久代的类，而不是fullgc，netbeans5.5 performance文档的推荐。
4.增量(train算法)收集器(Incremental Collector)
已停止维护，–Xincgc选项默认转为并发收集器。
四、暂停时间显示
加入下列参数 (请将PrintGC和Details中间的空格去掉，CSDN很怪的认为是禁止字句）
-verbose:gc -XX:+PrintGC Details -XX:+PrintGCTimeStamps
会程序运行过程中将显示如下输出
9.211: [GC 9.211: [ParNew: 7994K->0K(8128K), 0.0123935 secs] 427172K->419977K(524224K), 0.0125728 secs]
显示在程序运行的9.211秒发生了Minor的垃圾收集，前一段数据针对新生区，从7994k整理为0k，新生区总大小为8128k，程序暂停了12ms，而后一段数据针对整个堆。
对于年老代的收集，暂停发生在下面两个阶段，CMS-remark的中断是17毫秒：
[GC [1 CMS-initial-mark: 80168K(196608K)] 81144K(261184K), 0.0059036 secs]
[1 CMS-remark: 80168K(196608K)] 82493K(261184K),0.0168943 secs]
再加两个参数 -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime对暂停时间看得更清晰。
五、真正不停的BEA JRockit 与Sun RTS2.0
Bea的JRockit 5.0 R27 的特色之一是动态决定的垃圾收集策略，用户可以决定自己关心的是吞吐量，暂停时间还是确定的暂停时间，再由JVM在运行时动态决定、改变改变垃圾收集策略。
它的Deterministic GC的选项是-Xgcprio: deterministic，号称可以把暂停可以控制在10-30毫秒，非常的牛，一句Deterministic道尽了RealTime的真谛。不过细看一下文档，30ms的测试环境是1 GB heap 和 平均 30% 的活跃对象(也就是300M)活动对象，2 个 Xeon 3.6 GHz 4G内存 ，或者是4 个Xeon 2.0 GHz，8G内存。
最可惜JRockt的license很奇怪，虽然平时使用免费，但这个30ms的选项就需要购买整个Weblogic Real Time Server的license。
其他免费选项，有：
* -Xgcprio:pausetime -Xpausetarget=210ms
因为免费，所以最低只能设置到200ms pause target。 200ms是Sun认为Real-Time的分界线。
* -Xgc:gencon
普通的并发做法，效率也不错。
JavaOne2007上有Sun的 Java Real-Time System 2.0 的介绍，RTS2.0基于JDK1.5，在Real-Time Garbage Collctor上又有改进，但还在beta版状态，只供给OEM，更怪。
六、JDK 6.0的改进
因为JDK5.0在Young较大时的表现还是不够让人满意，又继续看JDK6.0的改进，结果稍稍失望，不涉及我最头痛的年轻代复制收集改良。
1.年老代的标识-清除收集，并行执行标识
JDK5.0只开了一条收集进程与应用线程并发标识，而6.0可以开多条收集线程来做标识，缩短标识老人区所有活动对象的时间。
2.加大了Young区的默认大小
默认大小从4M加到16M，从堆内存的1/15增加到1/7
3.System.gc()可以与应用程序并发执行
使用-XX:+ExplicitGCInvokesConcurrent 设置
七、小结
1. JDK5.0/6.0
对于服务器应用，我们使用Concurrent Low Pause Collector，对年轻代，暂停时多线程并行复制收集；对年老代，收集器与应用程序并行标记--整理收集，以达到尽量短的垃圾收集时间。
本着没有深刻测试前不要胡乱优化的宗旨，命令行属性只需简单写为：
-server -XmsM -XmxM -XX:+UseConcMarkSweepGC -XX:+PrintGC Details -XX:+PrintGCTimeStamps
然后要根据应用的情况，在测试软件辅助可以下看看有没有JVM的默认值和自动管理做的不够的地方可以调整，如-xmn 设Young的大小，-XX:MaxPermSize设持久代大小等。
2. JRockit 6.0 R27.2
但因为JDK5的测试结果实在不能满意，后来又尝试了JRockit，总体效果要好些。
JRockit的特点是动态垃圾收集器是根据用户关心的特征动态决定收集算法的，参数如下
-XmsM -XmxM -Xgcprio:pausetime -Xpausetarget=200ms -XgcReport -XgcPause -Xverbose:memory
GC的基本原理
Java的内存管理实际上就是对象的管理，其中包括对象的分配和释放。
对于程序员来说，分配对象使用new关键字；释放对象时，只要将对象所有引用赋值为null，让程序不能够再访问到这个对象，我们称该对象为"不可达的".GC将负责回收所有"不可达"对象的内存空间。
对于GC来说，当程序员创建对象时，GC就开始监控这个对象的地址、大小以及使用情况。通常，GC采用有向图的方式记录和管理堆（heap）中的所有对象（详见 参考资料1 ）。通过这种方式确定哪些对象是"可达的"，哪些对象是"不可达的".当GC确定一些对象为"不可达"时，GC就有责任回收这些内存空间。但是，为了保证 GC能够在不同平台实现的问题，Java规范对GC的很多行为都没有进行严格的规定。例如，对于采用什么类型的回收算法、什么时候进行回收等重要问题都没有明确的规定。因此，不同的JVM的实现者往往有不同的实现算法。这也给Java程序员的开发带来行多不确定性。本文研究了几个与GC工作相关的问题，努力减少这种不确定性给Java程序带来的负面影响。
增量式GC（ Incremental GC ）
GC在JVM中通常是由一个或一组进程来实现的，它本身也和用户程序一样占用heap空间，运行时也占用CPU.当GC进程运行时，应用程序停止运行。因此，当GC运行时间较长时，用户能够感到 Java程序的停顿，另外一方面，如果GC运行时间太短，则可能对象回收率太低，这意味着还有很多应该回收的对象没有被回收，仍然占用大量内存。因此，在设计GC的时候，就必须在停顿时间和回收率之间进行权衡。一个好的GC实现允许用户定义自己所需要的设置，例如有些内存有限有设备，对内存的使用量非常敏感，希望GC能够准确的回收内存，它并不在意程序速度的放慢。另外一些实时网络游戏，就不能够允许程序有长时间的中断。增量式GC就是通过一定的回收算法，把一个长时间的中断，划分为很多个小的中断，通过这种方式减少GC对用户程序的影响。虽然，增量式GC在整体性能上可能不如普通GC的效率高，但是它能够减少程序的最长停顿时间。
Sun JDK提供的HotSpot JVM就能支持增量式GC.HotSpot JVM缺省GC方式为不使用增量GC，为了启动增量GC，我们必须在运行Java程序时增加-Xincgc的参数。HotSpot JVM增量式GC的实现是采用Train GC算法。它的基本想法就是，将堆中的所有对象按照创建和使用情况进行分组（分层），将使用频繁高和具有相关性的对象放在一队中，随着程序的运行，不断对组进行调整。当GC运行时，它总是先回收最老的（最近很少访问的）的对象，如果整组都为可回收对象，GC将整组回收。这样，每次GC运行只回收一定比例的不可达对象，保证程序的顺畅运行。
详解finalize函数
finalize 是位于Object类的一个方法，该方法的访问修饰符为protected，由于所有类为Object的子类，因此用户类很容易访问到这个方法。由于， finalize函数没有自动实现链式调用，我们必须手动的实现，因此finalize函数的最后一个语句通常是super.finalize（）。通过这种方式，我们可以实现从下到上实现finalize的调用，即先释放自己的资源，然后再释放父类的资源。
根据Java语言规范，JVM保证调用finalize函数之前，这个对象是不可达的，但是JVM不保证这个函数一定会被调用。另外，规范还保证finalize函数最多运行一次。
很多Java初学者会认为这个方法类似与C++中的析构函数，将很多对象、资源的释放都放在这一函数里面。其实，这不是一种很好的方式。原因有三，其一，GC为了能够支持finalize函数，要对覆盖这个函数的对象作很多附加的工作。其二，在finalize运行完成之后，该对象可能变成可达的，GC还要再检查一次该对象是否是可达的。因此，使用 finalize会降低GC的运行性能。其三，由于GC调用finalize的时间是不确定的，因此通过这种方式释放资源也是不确定的。
通常，finalize用于一些不容易控制、并且非常重要资源的释放，例如一些I/O的操作，数据的连接。这些资源的释放对整个应用程序是非常关键的。在这种情况下，程序员应该以通过程序本身管理（包括释放）这些资源为主，以finalize函数释放资源方式为辅，形成一种双保险的管理机制，而不应该仅仅依靠finalize来释放资源。
今天粗略的看了下java的gc， http://calvin.iteye.com/blog/91905。以前也看过一些，但是怎么找到测试的环境来验证参数的改变带来的变化呢。有一点要说名的是jvm规范并未说明java gc采取什么样的策略，所以在各个jvm的实现也有所不同。在了解基本概念之前，其实我们可以想想，gc主要就是负责那些占用了内存资源的对象的管理，或者说是对垃圾对象（不再使用）的回收java的gc说白了就是对java内存（也就是堆的管理）。因此肯定会对这些对象的生命周期不同而分类，分完类后就会采用什么样的策略去处理这些垃圾对象。
基本概念：
根据对象的生命周期分类：young，old，permanent。
young：新生代又分为Eden 和两片生存空间（survivor spaces）。所有新建对象都放在eden：两片生存区中保证有一片空间在任何时间是空的，当垃圾收集发生时，加入suvivor1是空的，survivor2里面是原先有的对象。当发生垃圾回收时，先把 Eden 中的活的对象复制到survivor1，再把survivor2复制到survivor1，然后清理eden和survior2.直到到达最大门限值（老化），然后复制到旧生代(old)。可以用-Xmn参数规定其大小。
old：young 总是不断膨胀的，其中有些对象在young中发生的几次收集中始终都在survivor中存活，终于survivor的空间也撑不住了，于是这些对象被搬到了old区了（注：也有可能是young区的对象被收集了几次后被搬到old区，这个几次由参数-XX:MaxTenuringThreshold=参数来设置）。当然old区也不是说这里面的对象就一直有效，old也是要垃圾清理的，但是young的垃圾清理不同，old区采用的是标记清理。所谓标记清理，就是先遍历一遍所有的对象，看看那些是活跃那些是垃圾，然后再遍历一次，清理垃圾。
Permanent，持久代。装载Class信息等基础数据，默认64M，如果是类很多很多的服务程序，需要加大其设置-
XX:MaxPermSize=，否则它满了之后会引起fullgc()或Out of Memory。 像Spring，Hibernate这类喜欢动态生成类的框架
需要更多的持久代内存。
young是一个比较活跃的区域，因此gc在对young收集频率很高，这种收集叫minor collection，而且使用的是复制算法。
而对old代则使用的是标记整理（或标记压缩整理），这种成本比较大。同时对young和old收集则是major collection。
GC收集器除了在具体执行回收的时候很容易理解外，因为策略的不同又有以下几种分类：
A:串行收集器： 使用 -XX:+UseSerialGC，策略为年轻代串行复制，年老代串行标记整理。这种方法很老。
B:吞吐量优先的并行收集器：使用 -XX:+UseParallelGC ，也是JDK5 -server的默认值。策略为：
1.年轻代暂停应用程序，多个垃圾收集线程并行的复制收集，线程数默认为CPU个数，CPU很多时，可用–
XX:ParallelGCThreads=减少线程数。多cpu时代的选择，呵呵。
2.年老代暂停应用程序，与串行收集器一样，单垃圾收集线程标记整理。
可以使用-XX:MaxGCPauseMillis= 和 -XX:GCTimeRatio 来调整GC的时间。
需要注意的是，不管是年轻代还是年老代都需要短暂的暂停应用。
C:暂停时间优先的并发收集器(Concurrent Low Pause Collector-CMS)
使用-XX:+UseConcMarkSweepGC，简称CMS.策略为：
1.年轻代同样是暂停应用程序，多个垃圾收集线程并行的复制收集。
还是需要暂停应用，这个就是大型系统的瓶颈所在，特别是当年轻代变大的时候，整个复制时间长也就意味着
暂停应用时间长。太小的话又会导致频繁的垃圾回收。
2.年老代则只有两次短暂停，其他时间应用程序与收集线程并发的清除。
这个改进比较大，大部分垃圾回收的时候应用是运行的。
3.持久代也用CMS去收集而不是full gc。
在涉及到调优gc的时候，先要观察一下暂停时间显示，有了数据我们才好说话。
加入下列参数 (请将PrintGC和Details中间的空格去掉，CSDN很怪的认为是禁止字句）
命令代码 复制代码
1. -verbose:gc -XX:+PrintGC Details -XX:+PrintGCTimeStamps
-verbose:gc -XX:+PrintGC Details -XX:+PrintGCTimeStamps
会程序运行过程中将显示如下输出
9.211: [GC 9.211: [ParNew: 7994K->0K(8128K), 0.0123935 secs] 427172K->419977K(524224K), 0.0125728 secs]
显示在程序运行的9.211秒发生了Minor的垃圾收集，前一段数据针对新生区，从7994k整理为0k，新生区总大小为8128k，
程序暂停了12ms，而后一段数据针对整个堆。
对于年老代的收集，暂停发生在下面两个阶段，CMS-remark的中断是17毫秒：
[GC [1 CMS-initial-mark: 80168K(196608K)] 81144K(261184K), 0.0059036 secs]
[1 CMS-remark: 80168K(196608K)] 82493K(261184K),0.0168943 secs]
再加两个参数 -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime对暂停时间看得更清晰
根对象的集合：局部变量的对象引用
栈帧里面的对象引用，类变量里面的对象引用。类常量池的对象应用。
本地方法的对象引用。
gc 判断的垃圾对象的方法是 计数和跟踪。。
-XX:-PrintGC Print messages at garbage collection. Manageable.
-XX:-PrintGC Details Print more details at garbage collection. Manageable. (Introduced in 1.4.0.)
-XX:-PrintGCTimeStamps Print timestamps at garbage collection. Manageable (Introduced in 1.4.0.)
写了好几篇关于这个方向的文章了，但连自己都感觉写的有点乱，没有总结。所以现在把所有方法整理到一起，如果以后又发现新的，我继续补充到这篇文章里。
这篇是技巧性的文章，如果要找关于GC或者调整内纯的文章，看我其他几篇文章。因为是JVM 调优总结，所以废话少说。从各方面一共收集到以下几个方法：
1.升级 JVM 版本。如果能使用64-bit，使用64-bit JVM。
基本上没什么好解释的，很简单将JVM升级到最新的版本。如果你还是使用JDK1.4甚至是更早的JVM，那你首先要做的就是升级。因为JVM从1.4- >1.5->1.6可不是仅仅的版本号升级，或者仅仅往里面加了一堆新的语言特性，这么简单。而是真正在JVM做了重大的改进，每次版本升级，都有巨大的性能升级。尤其是ＳＵＮ认识到ｊａｖａ是知己的全部的时候（夸张点，但连股票号都改成ＪＡＶＡ了，呵呵）。如果你经常逛SUN 的JVM论坛，你就会发现实际上JVM上的毛病是这么多。如果你因为各种原因，而不能升级到1.6，那你可以升级到该版本的最新版。
2.选择一个正确的GC（Gargage Collection）。
由于当JAVA程序GC的时候，会停下当前程序。尤其Full GC的时候，会停留很长时间。一般对于GUI程序来说，是很难接受的（想想Eclipse暂停的时候）。 JAVA5 以后，开始自带了好几种GC，你可以选择一个适合你的种类。有以下四种Serial Collector，Parallel collector，Concurrent Collector，Train Collector（废弃）。后面几种时候使用并行收集，所以理论上有效率更高（要求你有超过2CUP，但是现在多核开始普及了，呵呵）。提示：更改GC 种类以后要适当挺高JVM的内存量。
3.正确设置内存大小。对JVM堆内的各个区域（young,old,perm）正确设置大小。
这个是最困难的调整，因为这个调整会直接影响GC的效率。而且由于各个程序的类型不用，所以没有一个通用的数据。除了几个常用规则以外，需要使用工具（jstat,jvmstat,jconsole等等）仔细调整。下面会提到几个常用的准则。通常使用一下几个参数调整-Xms -Xmx-XX:MaxPermSize。
3.1 调高-XX:NewRatio（NewSize/MaxNewSize）的值，会减少young gc的次数，但会增加old gc的时间。
3.2 增加普通GC的方法（减小Full GC）。扩大young区域的大小（最大40%），并过大Survivor的区域。使得更多的object留在young gen。
4.减小类的使用量，注意类的load和unload，减少JSP页数。
类实际上也是对象，会直接分配perm区域里，即使Full GC也会很少收集。JSP也会分配到perm区域里，效果同理。如果perm过大，超过XX:MaxPermSize值，会发生 OutOfMemoryError: PermGen space异常。解决方法是提高-XX:MaxPermSize值。
5.避免使用-Xnoclassgc
6.如果是RMI程序，要注意调整RMI DGC的时间。
以下是几个写程序时，应该注意的地方。也可减小GC，提高JVM性能。
1.不要使用System.gc()方法。
因为它会产生Full GC。
2.尽可能少分配大的临时对象（生命周期短的）
可能会直接分配到old区域里，old区域只有Full GC的时候会收集。
3.避免使用finalize()方法。
finalize()会增加GC的负担，使用java.lang.ref代替。
JDK5.0垃圾收集优化之--Don't Pause
作者：江南白衣，最新版链接：http://blog.csdn.net/calvinxiu/archive/2007/05/18/1614473.aspx，版权所有，转载请保留原文链接。
原本想把题目更简单的定为--《不要停》的，但还是自己YY一下就算了。
Java开发Server最大的障碍，就是JDK1.4版之前的的串行垃圾收集机制会引起长时间的服务暂停，明白原理后，想想那些用JDK1.3写Server的先辈，不得不后怕。
好在JDK1.4已开始支持多线程并行的后台垃圾收集算法，JDK5.0则优化了默认值的设置。
一、参考资料：
1. Tuning Garbage Collection with the 5.0 Java Virtual Machine 官方指南。
2. Hotspot memory management whitepaper 官方白皮书。
3. Java Tuning White Paper 官方文档。
4. FAQ about Garbage Collection in the Hotspot 官方FAQ，JVM1.4.2。
5. Java HotSpot 虚拟机中的垃圾收集 JavaOne2004上的中文ppt
6. A Collection of JVM Options JVM选项的超完整收集。
二、基本概念
1、堆(Heap)
JVM管理的内存叫堆。在32Bit操作系统上有1.5G-2G的限制，而64Bit的就没有。
JVM初始分配的内存由-Xms指定，默认是物理内存的1/64但小于1G。
JVM最大分配的内存由-Xmx指定，默认是物理内存的1/4但小于1G。
默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制，可以由-XX:MinHeapFreeRatio=指定。
默认空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制，可以由-XX:MaxHeapFreeRatio=指定。
服务器一般设置-Xms、-Xmx相等以避免在每次GC 后调整堆的大小，所以上面的两个参数没啥用。
2.基本收集算法
1. 复制：将堆内分成两个相同空间，从根(ThreadLocal的对象，静态对象）开始访问每一个关联的活跃对象，将空间A的活跃对象全部复制到空间B，然后一次性回收整个空间A。
因为只访问活跃对象，将所有活动对象复制走之后就清空整个空间，不用去访问死对象，所以遍历空间的成本较小，但需要巨大的复制成本和较多的内存。
2. 标记清除(mark-sweep)：收集器先从根开始访问所有活跃对象，标记为活跃对象。然后再遍历一次整个内存区域，把所有没有标记活跃的对象进行回收处理。该算法遍历整个空间的成本较大暂停时间随空间大小线性增大，而且整理后堆里的碎片很多。
3. 标记整理(mark-sweep-compact)：综合了上述两者的做法和优点，先标记活跃对象，然后将其合并成较大的内存块。
可见，没有免费的午餐，无论采用复制还是标记清除算法，自动的东西都要付出很大的性能代价。
3.分代
分代是Java垃圾收集的一大亮点，根据对象的生命周期长短，把堆分为3个代：Young，Old和Permanent，根据不同代的特点采用不同的收集算法，扬长避短也。
Young(Nursery)，年轻代。研究表明大部分对象都是朝生暮死，随生随灭的。因此所有收集器都为年轻代选择了复制算法。
复制算法优点是只访问活跃对象，缺点是复制成本高。因为年轻代只有少量的对象能熬到垃圾收集，因此只需少量的复制成本。而且复制收集器只访问活跃对象，对那些占了最大比率的死对象视而不见，充分发挥了它遍历空间成本低的优点。
Young的默认值为4M，随堆内存增大，约为1/15，JVM会根据情况动态管理其大小变化。
-XX:NewRatio= 参数可以设置Young与Old的大小比例，-server时默认为1:2，但实际上young启动时远低于这个比率？如果信不过JVM，也可以用-Xmn硬性规定其大小，有文档推荐设为Heap总大小的1/4。
Young的大小非常非常重要，见“后面暂停时间优先收集器”的论述。
Young里面又分为3个区域，一个Eden，所有新建对象都会存在于该区，两个Survivor区，用来实施复制算法。每次复制就是将Eden和第一块 Survior的活对象复制到第2块，然后清空Eden与第一块Survior。Eden与Survivor的比例由-XX:SurvivorRatio =设置，默认为32。Survivio大了会浪费，小了的话，会使一些年轻对象潜逃到老人区，引起老人区的不安，但这个参数对性能并不重要。
Old(Tenured)，年老代。年轻代的对象如果能够挺过数次收集，就会进入老人区。老人区使用标记整理算法。因为老人区的对象都没那么容易死的，采用复制算法就要反复的复制对象，很不合算，只好采用标记清理算法，但标记清理算法其实也不轻松，每次都要遍历区域内所有对象，所以还是没有免费的午餐啊。
-XX:MaxTenuringThreshold=设置熬过年轻代多少次收集后移入老人区，CMS中默认为0，熬过第一次GC就转入，可以用-XX:+PrintTenuringDistribution查看。
Permanent，持久代。装载Class信息等基础数据，默认64M，如果是类很多很多的服务程序，需要加大其设置-XX:MaxPermSize=，否则它满了之后会引起fullgc()或Out of Memory。注意Spring，Hibernate这类喜欢AOP动态生成类的框架需要更多的持久代内存。
4.minor/major collection
每个代满了之后都会促发collection，（另外Concurrent Low Pause Collector默认在老人区68%的时候促发)。GC用较高的频率对young进行扫描和回收，这种叫做minor collection。
而因为成本关系对Old的检查回收频率要低很多，同时对Young和Old的收集称为major collection。
System.gc()会引发major collection，使用-XX:+DisableExplicitGC禁止它，或设为CMS并发-XX:+ExplicitGCInvokesConcurrent。
5.小结
Young -- minor collection -- 复制算法
Old(Tenured) -- major colletion -- 标记清除/标记整理算法
三、收集器
1.古老的串行收集器(Serial Collector)
使用 -XX:+UseSerialGC，策略为年轻代串行复制，年老代串行标记整理。
2.吞吐量优先的并行收集器(Throughput Collector)
使用 -XX:+UseParallelGC ，也是JDK5 -server的默认值。策略为：
1.年轻代暂停应用程序，多个垃圾收集线程并行的复制收集，线程数默认为CPU个数，CPU很多时，可用–XX:ParallelGCThreads=减少线程数。
2.年老代暂停应用程序，与串行收集器一样，单垃圾收集线程标记整理。
所以需要2+的CPU时才会优于串行收集器，适用于后台处理，科学计算。
可以使用-XX:MaxGCPauseMillis= 和 -XX:GCTimeRatio 来调整GC的时间。
3.暂停时间优先的并发收集器(Concurrent Low Pause Collector-CMS)
前面说了这么多，都是为了这节做铺垫......
使用-XX:+UseConcMarkSweepGC，策略为：
1.年轻代同样是暂停应用程序，多个垃圾收集线程并行的复制收集。
2.年老代则只有两次短暂停，其他时间应用程序与收集线程并发的清除。
3.1 年老代详述
并行(Parallel)与并发(Concurrent)仅一字之差，并行指多条垃圾收集线程并行，并发指用户线程与垃圾收集线程并发，程序在继续运行，而垃圾收集程序运行于另一个个CPU上。
并发收集一开始会很短暂的停止一次所有线程来开始初始标记根对象，然后标记线程与应用线程一起并发运行，最后又很短的暂停一次，多线程并行的重新标记之前可能因为并发而漏掉的对象，然后就开始与应用程序并发的清除过程。可见，最长的两个遍历过程都是与应用程序并发执行的，比以前的串行算法改进太多太多了！！！
串行标记清除是等年老代满了再开始收集的，而并发收集因为要与应用程序一起运行，如果满了才收集，应用程序就无内存可用，所以系统默认68%满的时候就开始收集。内存已设得较大，吃内存又没有这么快的时候，可以用-XX:CMSInitiatingOccupancyFraction=恰当增大该比率。
3.2 年轻代详述
可惜对年轻代的复制收集，依然必须停止所有应用程序线程，原理如此，只能靠多CPU，多收集线程并发来提高收集速度，但除非你的Server 独占整台服务器，否则如果服务器上本身还有很多其他线程时，切换起来速度就..... 所以，搞到最后，暂停时间的瓶颈就落在了年轻代的复制算法上。
因此Young的大小设置挺重要的，大点就不用频繁GC，而且增大GC的间隔后，可以让多点对象自己死掉而不用复制了。但Young增大时，GC造成的停顿时间攀升得非常恐怖，比如在我的机器上，默认8M的Young，只需要几毫秒的时间，64M就升到90毫秒，而升到256M时，就要到300毫秒了，峰值还会攀到恐怖的800ms。谁叫复制算法，要等Young满了才开始收集，开始收集就要停止所有线程呢。
3.3 持久代
可设置-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled，使CMS收集持久代的类，而不是fullgc，netbeans5.5 performance文档的推荐。
4.增量(train算法)收集器(Incremental Collector)
已停止维护，–Xincgc选项默认转为并发收集器。
四、暂停时间显示
加入下列参数 (请将PrintGC和Details中间的空格去掉，CSDN很怪的认为是禁止字句）
-verbose:gc -XX:+PrintGC Details -XX:+PrintGCTimeStamps
会程序运行过程中将显示如下输出
9.211: [GC 9.211: [ParNew: 7994K->0K(8128K), 0.0123935 secs] 427172K->419977K(524224K), 0.0125728 secs]
显示在程序运行的9.211秒发生了Minor的垃圾收集，前一段数据针对新生区，从7994k整理为0k，新生区总大小为8128k，程序暂停了12ms，而后一段数据针对整个堆。
对于年老代的收集，暂停发生在下面两个阶段，CMS-remark的中断是17毫秒：
[GC [1 CMS-initial-mark: 80168K(196608K)] 81144K(261184K), 0.0059036 secs]
[1 CMS-remark: 80168K(196608K)] 82493K(261184K),0.0168943 secs]
再加两个参数 -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime对暂停时间看得更清晰。
五、真正不停的BEA JRockit 与Sun RTS2.0
Bea的JRockit 5.0 R27 的特色之一是动态决定的垃圾收集策略，用户可以决定自己关心的是吞吐量，暂停时间还是确定的暂停时间，再由JVM在运行时动态决定、改变改变垃圾收集策略。
它的Deterministic GC的选项是-Xgcprio: deterministic，号称可以把暂停可以控制在10-30毫秒，非常的牛，一句Deterministic道尽了RealTime的真谛。不过细看一下文档，30ms的测试环境是1 GB heap 和 平均 30% 的活跃对象(也就是300M)活动对象，2 个 Xeon 3.6 GHz 4G内存 ，或者是4 个Xeon 2.0 GHz，8G内存。
最可惜JRockt的license很奇怪，虽然平时使用免费，但这个30ms的选项就需要购买整个Weblogic Real Time Server的license。
其他免费选项，有：
* -Xgcprio:pausetime -Xpausetarget=210ms
因为免费，所以最低只能设置到200ms pause target。 200ms是Sun认为Real-Time的分界线。
* -Xgc:gencon
普通的并发做法，效率也不错。
JavaOne2007上有Sun的 Java Real-Time System 2.0 的介绍，RTS2.0基于JDK1.5，在Real-Time Garbage Collctor上又有改进，但还在beta版状态，只供给OEM，更怪。
六、JDK 6.0的改进
因为JDK5.0在Young较大时的表现还是不够让人满意，又继续看JDK6.0的改进，结果稍稍失望，不涉及我最头痛的年轻代复制收集改良。
1.年老代的标识-清除收集，并行执行标识
JDK5.0只开了一条收集进程与应用线程并发标识，而6.0可以开多条收集线程来做标识，缩短标识老人区所有活动对象的时间。
2.加大了Young区的默认大小
默认大小从4M加到16M，从堆内存的1/15增加到1/7
3.System.gc()可以与应用程序并发执行
使用-XX:+ExplicitGCInvokesConcurrent 设置
七、小结
1. JDK5.0/6.0
对于服务器应用，我们使用Concurrent Low Pause Collector，对年轻代，暂停时多线程并行复制收集；对年老代，收集器与应用程序并行标记--整理收集，以达到尽量短的垃圾收集时间。
本着没有深刻测试前不要胡乱优化的宗旨，命令行属性只需简单写为：
-server -XmsM -XmxM -XX:+UseConcMarkSweepGC -XX:+PrintGC Details -XX:+PrintGCTimeStamps
然后要根据应用的情况，在测试软件辅助可以下看看有没有JVM的默认值和自动管理做的不够的地方可以调整，如-xmn 设Young的大小，-XX:MaxPermSize设持久代大小等。
2. JRockit 6.0 R27.2
但因为JDK5的测试结果实在不能满意，后来又尝试了JRockit，总体效果要好些。
JRockit的特点是动态垃圾收集器是根据用户关心的特征动态决定收集算法的，参数如下
-XmsM -XmxM -Xgcprio:pausetime -Xpausetarget=200ms -XgcReport -XgcPause -Xverbose:memory
GC的基本原理
Java的内存管理实际上就是对象的管理，其中包括对象的分配和释放。
对于程序员来说，分配对象使用new关键字；释放对象时，只要将对象所有引用赋值为null，让程序不能够再访问到这个对象，我们称该对象为"不可达的".GC将负责回收所有"不可达"对象的内存空间。
对于GC来说，当程序员创建对象时，GC就开始监控这个对象的地址、大小以及使用情况。通常，GC采用有向图的方式记录和管理堆（heap）中的所有对象（详见 参考资料1 ）。通过这种方式确定哪些对象是"可达的"，哪些对象是"不可达的".当GC确定一些对象为"不可达"时，GC就有责任回收这些内存空间。但是，为了保证 GC能够在不同平台实现的问题，Java规范对GC的很多行为都没有进行严格的规定。例如，对于采用什么类型的回收算法、什么时候进行回收等重要问题都没有明确的规定。因此，不同的JVM的实现者往往有不同的实现算法。这也给Java程序员的开发带来行多不确定性。本文研究了几个与GC工作相关的问题，努力减少这种不确定性给Java程序带来的负面影响。
增量式GC（ Incremental GC ）
GC在JVM中通常是由一个或一组进程来实现的，它本身也和用户程序一样占用heap空间，运行时也占用CPU.当GC进程运行时，应用程序停止运行。因此，当GC运行时间较长时，用户能够感到 Java程序的停顿，另外一方面，如果GC运行时间太短，则可能对象回收率太低，这意味着还有很多应该回收的对象没有被回收，仍然占用大量内存。因此，在设计GC的时候，就必须在停顿时间和回收率之间进行权衡。一个好的GC实现允许用户定义自己所需要的设置，例如有些内存有限有设备，对内存的使用量非常敏感，希望GC能够准确的回收内存，它并不在意程序速度的放慢。另外一些实时网络游戏，就不能够允许程序有长时间的中断。增量式GC就是通过一定的回收算法，把一个长时间的中断，划分为很多个小的中断，通过这种方式减少GC对用户程序的影响。虽然，增量式GC在整体性能上可能不如普通GC的效率高，但是它能够减少程序的最长停顿时间。
Sun JDK提供的HotSpot JVM就能支持增量式GC.HotSpot JVM缺省GC方式为不使用增量GC，为了启动增量GC，我们必须在运行Java程序时增加-Xincgc的参数。HotSpot JVM增量式GC的实现是采用Train GC算法。它的基本想法就是，将堆中的所有对象按照创建和使用情况进行分组（分层），将使用频繁高和具有相关性的对象放在一队中，随着程序的运行，不断对组进行调整。当GC运行时，它总是先回收最老的（最近很少访问的）的对象，如果整组都为可回收对象，GC将整组回收。这样，每次GC运行只回收一定比例的不可达对象，保证程序的顺畅运行。
详解finalize函数
finalize 是位于Object类的一个方法，该方法的访问修饰符为protected，由于所有类为Object的子类，因此用户类很容易访问到这个方法。由于， finalize函数没有自动实现链式调用，我们必须手动的实现，因此finalize函数的最后一个语句通常是super.finalize（）。通过这种方式，我们可以实现从下到上实现finalize的调用，即先释放自己的资源，然后再释放父类的资源。
根据Java语言规范，JVM保证调用finalize函数之前，这个对象是不可达的，但是JVM不保证这个函数一定会被调用。另外，规范还保证finalize函数最多运行一次。
很多Java初学者会认为这个方法类似与C++中的析构函数，将很多对象、资源的释放都放在这一函数里面。其实，这不是一种很好的方式。原因有三，其一，GC为了能够支持finalize函数，要对覆盖这个函数的对象作很多附加的工作。其二，在finalize运行完成之后，该对象可能变成可达的，GC还要再检查一次该对象是否是可达的。因此，使用 finalize会降低GC的运行性能。其三，由于GC调用finalize的时间是不确定的，因此通过这种方式释放资源也是不确定的。
通常，finalize用于一些不容易控制、并且非常重要资源的释放，例如一些I/O的操作，数据的连接。这些资源的释放对整个应用程序是非常关键的。在这种情况下，程序员应该以通过程序本身管理（包括释放）这些资源为主，以finalize函数释放资源方式为辅，形成一种双保险的管理机制，而不应该仅仅依靠finalize来释放资源。
今天粗略的看了下java的gc， http://calvin.iteye.com/blog/91905。以前也看过一些，但是怎么找到测试的环境来验证参数的改变带来的变化呢。有一点要说名的是jvm规范并未说明java gc采取什么样的策略，所以在各个jvm的实现也有所不同。在了解基本概念之前，其实我们可以想想，gc主要就是负责那些占用了内存资源的对象的管理，或者说是对垃圾对象（不再使用）的回收java的gc说白了就是对java内存（也就是堆的管理）。因此肯定会对这些对象的生命周期不同而分类，分完类后就会采用什么样的策略去处理这些垃圾对象。
基本概念：
根据对象的生命周期分类：young，old，permanent。
young：新生代又分为Eden 和两片生存空间（survivor spaces）。所有新建对象都放在eden：两片生存区中保证有一片空间在任何时间是空的，当垃圾收集发生时，加入suvivor1是空的，survivor2里面是原先有的对象。当发生垃圾回收时，先把 Eden 中的活的对象复制到survivor1，再把survivor2复制到survivor1，然后清理eden和survior2.直到到达最大门限值（老化），然后复制到旧生代(old)。可以用-Xmn参数规定其大小。
old：young 总是不断膨胀的，其中有些对象在young中发生的几次收集中始终都在survivor中存活，终于survivor的空间也撑不住了，于是这些对象被搬到了old区了（注：也有可能是young区的对象被收集了几次后被搬到old区，这个几次由参数-XX:MaxTenuringThreshold=参数来设置）。当然old区也不是说这里面的对象就一直有效，old也是要垃圾清理的，但是young的垃圾清理不同，old区采用的是标记清理。所谓标记清理，就是先遍历一遍所有的对象，看看那些是活跃那些是垃圾，然后再遍历一次，清理垃圾。
Permanent，持久代。装载Class信息等基础数据，默认64M，如果是类很多很多的服务程序，需要加大其设置-
XX:MaxPermSize=，否则它满了之后会引起fullgc()或Out of Memory。 像Spring，Hibernate这类喜欢动态生成类的框架
需要更多的持久代内存。
young是一个比较活跃的区域，因此gc在对young收集频率很高，这种收集叫minor collection，而且使用的是复制算法。
而对old代则使用的是标记整理（或标记压缩整理），这种成本比较大。同时对young和old收集则是major collection。
GC收集器除了在具体执行回收的时候很容易理解外，因为策略的不同又有以下几种分类：
A:串行收集器： 使用 -XX:+UseSerialGC，策略为年轻代串行复制，年老代串行标记整理。这种方法很老。
B:吞吐量优先的并行收集器：使用 -XX:+UseParallelGC ，也是JDK5 -server的默认值。策略为：
1.年轻代暂停应用程序，多个垃圾收集线程并行的复制收集，线程数默认为CPU个数，CPU很多时，可用–
XX:ParallelGCThreads=减少线程数。多cpu时代的选择，呵呵。
2.年老代暂停应用程序，与串行收集器一样，单垃圾收集线程标记整理。
可以使用-XX:MaxGCPauseMillis= 和 -XX:GCTimeRatio 来调整GC的时间。
需要注意的是，不管是年轻代还是年老代都需要短暂的暂停应用。
C:暂停时间优先的并发收集器(Concurrent Low Pause Collector-CMS)
使用-XX:+UseConcMarkSweepGC，简称CMS.策略为：
1.年轻代同样是暂停应用程序，多个垃圾收集线程并行的复制收集。
还是需要暂停应用，这个就是大型系统的瓶颈所在，特别是当年轻代变大的时候，整个复制时间长也就意味着
暂停应用时间长。太小的话又会导致频繁的垃圾回收。
2.年老代则只有两次短暂停，其他时间应用程序与收集线程并发的清除。
这个改进比较大，大部分垃圾回收的时候应用是运行的。
3.持久代也用CMS去收集而不是full gc。
在涉及到调优gc的时候，先要观察一下暂停时间显示，有了数据我们才好说话。
加入下列参数 (请将PrintGC和Details中间的空格去掉，CSDN很怪的认为是禁止字句）
命令代码 复制代码
1. -verbose:gc -XX:+PrintGC Details -XX:+PrintGCTimeStamps
-verbose:gc -XX:+PrintGC Details -XX:+PrintGCTimeStamps
会程序运行过程中将显示如下输出
9.211: [GC 9.211: [ParNew: 7994K->0K(8128K), 0.0123935 secs] 427172K->419977K(524224K), 0.0125728 secs]
显示在程序运行的9.211秒发生了Minor的垃圾收集，前一段数据针对新生区，从7994k整理为0k，新生区总大小为8128k，
程序暂停了12ms，而后一段数据针对整个堆。
对于年老代的收集，暂停发生在下面两个阶段，CMS-remark的中断是17毫秒：
[GC [1 CMS-initial-mark: 80168K(196608K)] 81144K(261184K), 0.0059036 secs]
[1 CMS-remark: 80168K(196608K)] 82493K(261184K),0.0168943 secs]
再加两个参数 -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime对暂停时间看得更清晰
195
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
