JVM之垃圾收集器与内存分配策略（二）

本篇文章是继JVM之垃圾收集器与内存分配策略（一）后写的，同样是笔者从《深入理解JVM虚拟机》中总结下来的，当做笔记。

GC类型以及导致Full GC的情况以及解决方法

GC类型包括：

1. Minor GC：对新生代进行的GC；
2. Major GC：对老年代进行的GC；
3. Full GC：对整个堆进行的GC。

导致Full GC的情况包括：

1. System.gc()方法的调用：建议JVM进行Full GC，会增加Full GC的频率，尽量不使用此方法；
2. 老年代空间不足：当出现大对象和大数组或新生代对象转入老年代时可能会出现老年代空间不足的情况，因此可通过避免创建大对象和大数组或调优时尽量让对象在Minor GC阶段被回收，如果Full GC后仍然不足会抛java.lang.OutOfMemoryError: Java heap space异常；
3. 方法区空间不足：当系统中要加载的类、反射的类和调用的方法较多时，Permanet Generation可能会被占满，在未配置为采用CMS GC的情况下也会执行Full GC。可以通过增大Perm Gen空间或转为使用CMS GC的方法避免Perm Gen空间占满，如果Full GC仍然回收不了会抛出java.lang.OutOfMemoryError: PermGen space 异常；
4. CMS GC时出现promotion failed和concurrent mode failue：promotion failed是进行Minor GC时Survivor空间放不下，对象放入老年代也放不下造成的，concurrent mode failue是CMS GC无法处理浮动垃圾时产生的，可以通过增大Survivor空间和老年代空间或者调低触发Full GC的比率解决；
5. 空间分配担保导致Full GC：如果HandlePromotionFailure设置为不允许担保失败或者老年代最大可用的连续空间小于历次晋升到老年代对象的平均大小或者某次GC存活的对象可能远大于历次晋升到老年代对象的平均值也会触发Full GC；

6. 堆中分配很大对象：当分配需要大量连续空间的对象时，此对象会直接进入老年代，而老年代无法提供如此大的连续空间分配时会触发Full GC。

垃圾收集器

如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。Java虚拟机规范中对垃圾收集器应该如何实现并没有任何规定，因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器都可能会有很大差别，并且一般都会提供参数供用户根据自己的应用特点和要求组合出各个年代所使用的收集器。这里的收集器基于JDK1.7之后的HotSpot虚拟机，这个虚拟机包含的所有收集器如图所示：

上图展示了作用于不同分代的收集器，如果两个收集器之间存在连线，就表示它们可以搭配使用。下面逐个简单介绍一下。

Serial收集器

Serial收集器是最基本、发展历史最悠久的收集器，在JDK1.3.1以前是新生代收集的唯一选择。这个收集器是一个单线程的收集器，但其“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集时，必须暂停其他的所有工作线程，直到它收集结束，即“Stop The World”。这项工作是虚拟机在后台自动发起和自动完成的，在用户不可见的情况下把用户正常工作的线程全部停掉，这对很多应用来说是难以接受的。

从JDK1.3开始，HotSpot虚拟机开发团队为消除或减少工作现场因内存回收而导致停顿的努力一直在进行着，用户线程的停顿时间在不断缩短，但仍然没有办法完全消除。

Serial收集器看似是一个鸡肋，实际上它依然是虚拟机运行在Client模式下的默认新生代收集器。它有着优于其他收集器的地方：简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。在用户的桌面应用场景中，分配给虚拟机管理的内存一般来说不会很大，收集几十兆甚至一两百兆的新生代停顿时间完全可以控制在几十毫秒最多一百多毫秒以内，只要不是频繁发生，这点停顿是可以接受的。

ParNew收集器

ParNew收集器就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样。

ParNew收集器是许多运行在Server模式下的虚拟机中首选的新生代收集器，很重要的原因是除了Serial收集器外，只有它能与CMS收集器配合工作。

ParNew收集器在单CPU环境中绝对不会有比Serial收集器更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分百的保证可以超越Serial收集器。但随着CPU数量的增加，它对于GC时系统资源的有效利用还是很有好处的。它默认开启的收集线程数量与CPU的数量相同，在CPU非常多的环境下，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。

从ParNew收集器开始，后边还会接触到几款并发和并行的收集器。这两个并发编程中的概念放到垃圾收集器的上下文语境中，可以解释如下：

1. 并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程依然处于等待状态。
2. 并发（Concurrent）：指用户线程与垃圾收集线程同时运行（但不一定是并行的，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行在另一个CPU上。

Parallel Scavenge收集器

Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，也是并行的多线程收集器。

Parallel Scavenge收集器的关注点与其他收集器不同，其他收集器的关注点是尽可能的缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标是达到一个可控制的吞吐量（Throughput）。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间）。例如虚拟机总共运行了100分钟，其中垃圾收集花了1分钟，那么吞吐量对应前面的公式就是99/（99+1） = 99%。

停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量可以高效率的利用CPU时间，尽快的完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量：

1. -XX:MaxGCPauseMillis：控制最大垃圾收集停顿时间；
2. -XX:GCTimeRatio：设置吞吐量大小。

MaxGCPauseMillis参数允许的值时一个大于0的毫秒数，收集器将尽可能保证内存回收花费的时间不超过此值。但此值设定的越小不一定就使得垃圾收集速度变得更快，GC停顿时间缩短是以牺牲吞吐量和新生代空间换来的。例如新生代从500M变成300M，一次垃圾收集速度变快了但是垃圾收集也变得更频繁了。例如原来10S收集一次，每次停顿100毫秒，现在5S收集一次，每次停顿70毫秒。停顿时间虽然下降了但吞吐量也下降了。

GCTimeRatio参数的值应当是一个大于0且小于100的整数，也就是垃圾收集时间占总时间的比率，相当于是吞吐量的倒数。例如此值为n，那允许的最大GC时间就占1/(1+n)，默认值为99，即默认允许最大1%（1/(1+99)）的垃圾收集时间。

Parallel Scavenge收集器与ParNew收集器还有一个重要区别是自适应调节策略。Parallel Scavenge收集器有一个-XX:UseAdaptiveSizePolicy的开关参数，打开之后就不需要手工指定新生代的大小（-Xmm）、Eden区与Survivor区的比例（-XX:SurvivorRatio）、晋升老年代对象大小（-XX:PretenureSizeThreshold）等细节参数，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大吞吐量，这种调节方式称为GC自适应的调节策略（GC Ergonomics）。

Serial Old收集器

Serial Old是Serial收集器的老年代版本，同样是一个单线程收集器，使用“标记-整理”算法。这个收集器的主要意义也是在于给Client模式下的虚拟机使用。如果在Server模式下，那么它主要还有两大用途：

1. 在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用；
2. 作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用（这也是在文章开始的图中Serial Old和CMS两个老年代收集器之间会有连线的原因）。

Parallrl Old收集器

Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。这个收集器是在JDK1.6才开始提供的，在此之前新生代的Parallel Scavenge收集器一直处于比较尴尬的状态，因为Parallel Scavenge收集器只能选择与Serial Old收集器搭配使用。由于老年代Serial Old收集器在服务端应用性能上的拖累，即便是使用Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果。

在Parallel Old收集器出现后，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge和Paralled Old收集器。

CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。

CMS收集器是基于“标记-清除”算法实现的，它的运作过程分为4个步骤：

1. 初试标记（CMS initial mark）：需要“Stop The World”，仅仅标记一下GC Roots能直接关联到的对象，速度很快；
2. 并发标记（CMS concurrent mark）：进行GC Roots Tracing的过程，时间较长；
3. 重新标记（CMS remark）：也需要“Stop The World”，为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长，但远比并发标记的时间短；
4. 并发清除（CMS concurrent sweep）：进行“清除”过程，时间较长。

CMS收集器存在并发收集和低停顿的优点，但也存在3个明显的缺点：

1. 对CPU资源非常敏感。面向并发设计的程序都对CPU资源比较敏感。在并发阶段，虽然它没有导致用户线程停顿，但因为占用了一部分线程会导致应用程序变慢，总吞吐量变低。CMS默认启动回收线程数量是（CPU+3）/4,也就是CPU在4个以上时，并发回收时垃圾回收线程占用不少于25%的CPU资源，并且随着CPU数量的增加而下降。但当CPU不足4个时，CMS对用户程序的影响就可能变得很大；
2. CMS收集器无法处理“浮动垃圾”，可能出现“Concurrent Mode Failure”失败而导致另一个Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，CMS无法在当次收集中处理它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。并且由于垃圾收集阶段用户线程还需要运行，就需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。可以使用参数-XX:CMSInitiatingOccupancyFraction的值来设置可使用空间的百分比。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集。这样停顿时间就很长了。所以-XX:CMSInitiatingOccupancyFraction设置的值相当重要，太低了老年代可使用空间少，内存回收频率变高；太高了容易导致“Concurrent Mode Failure”失败，性能反而降低。
3. CMS是基于“标记-清除”算法实现的，因此也具备“标记-清除”算法的缺点，就是收集结束会有大量空间碎片产生。空间碎片过多会导致无法找到足够大的连续空间来分配当前对象而不得不提前触发一次Full GC。CMS提供了一个-XX:+UseCMSCompactAtFullCollection开关参数用于在CMS收集器顶不住要进行Full GC时开启内存碎片的合并整理过程，默认是开启状态，但内存整理的过程时无法并发的，虽然解决了空间碎片问题，但停顿时间又变长了。

G1收集器

G1（Garbage-First）收集器是当今收集器技术发展的最前沿成果之一，是一款面向服务端应用的垃圾收集器。

 在G1之前的其他收集器进行收集的范围都是整个新生代或者老年代，而使用G1收集器时，Java堆的内存布局就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域（称为Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是屋里隔离的了，它们都是一部分Region（不需要连续）的集合。

与其他GC收集器相比，G1具备以下特点：

1. 并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行；
2. 分代收集：与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果；
3. 空间整合：与CMS的“标记-清理”算法不同，G1从整体来看是基于“标记-整理”算法实现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现的，但无论如何这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后可提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC；
4. 可预测的停顿：降低停顿时间是CMS和G1共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。

G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划的避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需要时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。

G1收集器把Java堆分为多个Region，但垃圾收集也并不是简单的以Region为单位进行，因为Region不可能是孤立的。一个对象分配在某个Region中，它并非只能被本Region中的其他对象引用，而是可以与整个Java堆任意的对象发生引用关系。看起来只有扫描整个Java堆才能保证可达性判定对象是否存活的准确性。类似的，在其他收集器的分代收集中，新生代的一般比老年代小很多并且垃圾收集的频率要高很多，回收新生代的对象时如果也要扫描老年代，那Minoe GC的效率无疑是很低的。

解决以上问题的方法是为每个Region都提供一个与之对应的Remembered Set，Remembered Set是在实现部分垃圾收集时用于记录非收集部分指向收集部分的指针集合的抽象数据结构。虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否出于不同的Region中（在分代的例子中就是检查是否老年代中的对象引用了新生代中的对象），如果是，则通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set中。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。

如果不计算维护Remembered Set的操作，G1收集器的运作大致可分为以下4个步骤：

1. 初试标记（Initial Marking）：标记GC Roots直接关联对象，并修改TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建对象，需要“Stop The World”，但耗时很短；
2. 并发标记（Concurrent Marking）：从GC Root开始对堆中对象进行可达性分析，找出存活的对象，耗时较长，但可与用户程序并发执行；
3. 最终标记（Final Marking）：修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，需要“Stop The World”，但可并行执行；
4. 筛选回收（Live Data Counting and Evacuation）：首先对各个Region的回收价值和成本进行排序，根据用户锁期望的GC停顿时间来指定回收计划，同样需要“Stop The World”。

HotSpot收集器比较

HotSpot收集器比较

收集器名称	作用分代	JDK版本	是否支持并行	是否支持并发	垃圾收集算法	特点
Serial	新生代	JDK1.3以前新生代唯一选择	否	否	复制算法	简单高效，适用于Client模式下的虚拟机
ParNew	新生代	没找到	是	否	复制算法	Serial的多线程版本
Parallel Scavenge	新生代	JDK1.4	是	否	复制算法	吞吐量优先，自适应调节策略
Serial Old	老年代	JDK1.5	否	否	标记-整理算法	Serial老年代版本，可作为CMS的后备预案
Parallel Old	老年代	JDK1.6	是	否	标记-整理算法	与Parallel Scavenge搭配使用，吞吐量优先
CMS	老年代	JDK1.5	重新标记阶段支持	并发标记和并发清除阶段支持	标记-清除算法	以获取最短停顿时间为目标，对CPU资源敏感，无法处理浮动垃圾，会产生空间碎片
G1	新生代和老年代	JDK1.7	最终标记和筛选回收阶段支持	并发标记阶段支持	局部基于复制算法；整体基于标记-整理算法	有了Region的概念，不会产生空间碎片，可预测的停顿

内存分配与回收策略

Java技术体系中所提倡的自动内存管理最终可以归结为自动化的解决了两个问题：给对象分配内存以及回收分配给对象的内存。前面提到的都是回收内存，现在再探讨一下给对象分配内存。

对象的内存分配也就是再堆上分配，对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TLAB（Thread-local allocation buffer，默认大小为Eden区的1%，线程私有区域）上分配。少数情况下也可能会直接分配在老年代中，分配的规则不是百分百固定的，其细节取决于当前使用的是哪一种垃圾收集器组合，还有虚拟机中与内存相关的参数的设置。

接下来讲解几条最普遍的内存分配规则：

1. 对象优先在Eden区分配：大多数情况下，对象在新生代的Eden区中分配。当Eden区没有足够空间时，虚拟机将发起一次Minor GC。虚拟机提供-XX:+PrintGCDetails收集器日志参数，告诉虚拟机在发生垃圾收集行为时打印内存回收日志，并且在进程退出的时候输出当前的内存各区域分配情况；
2. 大对象之间进入老年代：所谓的大对象是指，需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组。虚拟机提供了-XX:PretenureSizeThreshold参数（只对Serial和ParNew两款收集器有效），令大于这个设置值的对象直接在老年代分配。这样做的目的是避免在Eden区以及两个Survivor区直接发生大量的内存复制；
3. 长期存活的对象将进入老年代：虚拟机给每个对象定义了一个对象年龄（Age）计数器。如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移到Survivor空间中，并且对象年龄设为1.对象在Survivor区中每经历一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认15岁），就会晋升到老年代中。可以通过-XX:MaxTenuringThreshold参数设置老年代的年龄阀值；
4. 动态年龄判定：虚拟机并不是永远要求对象的年龄必须达到MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小总和大约Survivor空间的一半，年龄大于或者等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄；
5. 空间分配担保： 在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果大于，那么Minor GC可以确保是安全的。否则虚拟机将查看HandlePromotionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试进行一次Minor GC，尽管这次Minor GC是有风险的；如果HandlePromotionFailure设置为不允许担保失败或者老年代最大可用的连续空间小于历次晋升到老年代对象的平均大小，这时要改为进行一次Full GC。其中的风险是指当新生代经过Minor GC后还有大量对象依然存活的情况下，作为轮换备份的一个Survivor空间可能是不够的，因此需要老年代进行分配担保，把Survivor无法容纳的对象之间进入老年代。但某次GC存活的对象可能远大于历次晋升到老年代对象的平均值，这时也会导致担保失败，在失败后重新发起一次Full GC。