Java虚拟机：垃圾收集器和内存分配策略

垃圾收集器和内存分配策略

垃圾收集器

说垃圾收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。下图展示了7种作用于不同分代的收集器，其中用于回收新生代的收集器包括Serial、PraNew、Parallel Scavenge，回收老年代的收集器包括Serial Old、Parallel Old、CMS，还有用于回收整个Java堆的G1收集器。不同收集器之间的连线表示它们可以搭配使用。

虚拟机包含了所有的收集器如图所示：

图中展示了7种作用不同分代的收集器，如果两个收集器之间存在连线，就说明它们可以搭配使用。

Serial收集器

复制算法

Serial收集器曾经是虚拟机新生代的唯一选择。“单线程”收集，并“stop the world"

简单高效

ParNew收集器

复制算法

ParNew收集器是Serial收集器的多线程版本。除了Serial外，只有它能于Cms收集器配合。

ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地保证可以超越Serial收集器。当然，随着可以使用的CPU的数量的增加，它对于GC时系统资源的有效利用还是很有好处的。它默认开启的收集线程数与CPU的数量相同，在CPU非常多（譬如32个，现在CPU动辄就4核加超线程，服务器超过32个逻辑CPU的情况越来越多了）的环境下，可以使用-XX：ParallelGCThreads参数来限制垃圾收集的线程数。

在谈垃圾收集器上下文的时：

• 并行（parallel)：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
• 并发（concurrent): 指用户线程与垃圾收集线程同时执行（但不一定并行的，可能交替执行），用户程序继续运行，而垃圾收集程序运行在另一个cpu上。

Parallel Scavenge收集器

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

它的关注点在于吞吐量，而其他收集器关注缩短停顿时间。

吞吐量=运行用户代码时间／（运行用户代码时间+垃圾收集时间）

Serial old收集器

Serial old是Serial收集器的老年代版本，它是一个单线程收集器，使用“标记整理”算法。

两种用途：与Parallel scavenge收集器搭配使用，另外作为CMS收集器的后背预案，在并发收集发生Concurrent Mode Failure时使用。

Parallel Old收集器

Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。这个收集器是在JDK 1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。原因是，如果新生代选择了Parallel Scavenge收集器，老年代除了Serial Old（PS MarkSweep）收集器外别无选择（还记得上面说过Parallel Scavenge收集器无法与CMS收集器配合工作吗？）。由于老年代Serial Old收集器在服务端应用性能上的“拖累”，使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果，由于单线程的老年代收集中无法充分利用服务器多CPU的处理能力，在老年代很大而且硬件比较高级的环境中，这种组合的吞吐量甚至还不一定有ParNew加CMS的组合“给力”。

CMS收集器（标记清除算法）

CMS（Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。

• 初始标记
• 并发标记
• 重新标记
• 并发清除

其中，初始标记、重新标记这两个步骤仍然需要“stop the world”。初始标记仅仅只是标记一下GC roots能够关联到的对象，速度很快。并发标记是进行GC roots Tracing过程。重新标记，修正并发标记期间用户程序就行运行而导致标记产生变动的那一部分对象。

三个缺点：

• 对CPU资源非常敏感
• CMS收集器无法处理浮动垃圾（Floating Garbage），可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。在JDK1.5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活，这是一个偏保守的设置，如果在应用中老年代增长不是太快，可以适当调高参数-XX：CMSInitiatingOccupancyFraction的值来提高触发百分比，以便降低内存回收次数从而获取更好的性能，在JDK 1.6中，CMS收集器的启动阈值已经提升至92%。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。
• CMS 是标记清除算法，会有大量的空间碎片，但是当无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。

G1收集器

采用标记-整理算法

G1收集器的特短：

• 并行与并发
• 分代收集（与其他收集器一样）
• 空间整理（标记-整理算法）
• 可预测的停顿

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

• 初始标记（Initial Marking）
• 并发标记（Concurrent Marking）
• 最终标记（Final Marking）
• 筛选回收（Live Data Counting and Evacuation）

内存分配与回收策略

Java 技术体系中所提倡的自动内存管理最终可以归结为自动化地解决两个问题：给对象分配内存以及回收分配对对象的内存。

对象优先在Eden分配

大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间进行分配时，虚拟机将发起一次 Minor Gc.

大对象直接进入老年代

所谓大对象是指，需要大量连续内存空间的Java对象，最典型的大对象就是字节数组等。

长期存活的对象将进入老年代

虚拟机给每个对象定义了一个对象年龄的计数器。如果对象在Eden出生并经过Minor Gc仍然存活，并且能够被Survior容器容纳，将被移到Survivior空间中，并且年龄设置为1.对象在Survivor区中每“熬过”一次Minor Gc，年龄就增加1岁，当它的年龄达到一定程度（默认为15岁），就被晋升到老年代中。

动态对象年龄判断

如果在Survivor 空间中相同年龄的对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无需等到MaxTenringThreshold中要求的年龄。

空间分配担保

在发生Minor Gc之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象的总空间，如果这个条件成立，那么Minnor Gc可用确保是安全的。如果不成立，则虚拟机会查看HandlePromotyionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代最大空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试一次 Minnor Gc；如果小于，或者HandlePromotyionFailure设置不允许冒险，那么这时要进行一次Full Gc.

下面解释一下“冒险”是冒了什么风险，前面提到过，新生代使用复制收集算法，但为了内存利用率，只使用其中一个Survivor空间来作为轮换备份，因此当出现大量对象在Minor GC后仍然存活的情况（最极端的情况就是内存回收后新生代中所有对象都存活），就需要老年代进行分配担保，把Survivor无法容纳的对象直接进入老年代。与生活中的贷款担保类似，老年代要进行这样的担保，前提是老年代本身还有容纳这些对象的剩余空间，一共有多少对象会活下来在实际完成内存回收之前是无法明确知道的，所以只好取之前每一次回收晋升到老年代对象容量的平均大小值作为经验值，与老年代的剩余空间进行比较，决定是否进行Full Gc来让老年代腾出更多的空间。

取平均值进行比较其实仍然是一种动态概率的手段，也就是说，如果某次Minor GC存活后的对象突增，远远高于平均值的话，依然会导致担保失败（Handle Promotion Failure）。如果出现了HandlePromotionFailure失败，那就只好在失败后重新发起一次Full GC。虽然担保失败时绕的圈子是最大的，但大部分情况下都还是会将HandlePromotionFailure开关打开，避免Full Gc过于频繁。