【笔记】《深入理解Java虚拟机（第二版）》-第3章-垃圾收集器与内存分配策略

第3章 垃圾收集器与内存分配策略

3.1 概述

垃圾收集（Garbage Collection，GC），大部分人都把这项技术当做Java语言的伴生产物。事实上，GC的历史比Java久远，1960年诞生于MIT的Lisp是第一门使用内存动态分配和垃圾收集技术的语言。

当需要排查各种内存溢出、内存泄露问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就需要对这些“自动化”的技术实施必要的监控和调节。

程序计数器、虚拟机栈、本地方法栈3个区域随线程而生，随线程而灭；栈中的栈帧随方法进入和退出而有条不紊地执行着出栈和入栈操作。这几个区域的内存分配和回收都具备确定性。而Java堆和方法区则不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，只有在运行期间才能知道会创建哪些对象，这部分内存分配和回收都是动态的。

3.2 对象已死吗

3.2.1 引用计数算法

Reference Counting 实现简单，判定效率也很高，在大部分情况下它都是一个不错的算法，也有比较著名的应用案例，如微软的COM（Component Object Model）技术、使用ActionScript 3 的FlashPlayer、Python语言和在游戏脚本领域被广泛应用的Squirrel。但是主流的Java虚拟机没有选用，主要原因是很难解决对象之间循环引用的问题。

3.2.2 可达性分析算法

在主流的商用程序语言（Java、C#，甚至包括前面提到的古老的Lisp）的主流实现中，都是通过可达性分析（Reachability Analysis）来判定对象是否存活的。这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连时，则证明该对象是不可用的。

可作为GC Roots 的对象包括：

• 虚拟机栈（栈帧中的本地变量表）中引用的对象
• 方法区类静态属性引用的对象
• 方法区常量引用的对象
• 本地方法栈中JNI（即一般说的Native方法）引用的对象

3.2.3 再谈引用

JDK 1.2之前，Java中引用的定义很传统：如果Reference类型的数据中存储的数值代表的是另一块内存的起始地址，就称这块内存代表着一个引用。 我们希望能描述：当内存空间还足够时，则能保留在内存之中；如果内存空间在进行垃圾收集后还是非常紧张，则可以抛弃这些对象。很多系统的缓存功能都符合这样的应用场景。

JDK 1.2后，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）4种

• 强引用就是指在代码中普遍存在的，类似“Object obj = new Object()”这类的引用。只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象.
• 软引用就是用来描述一些还有用但非必须的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。在JDK 1.2之后，提供了SoftReference类来实现软引用
• 弱引用也是用于描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK 1.2之后，提供了WeakReference类来实现弱引用。
• 虚引用也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时收到一个系统通知。在JDK1.2之后，提供了PhantomReference类来实现虚引用。

3.2.4 生存还是死亡

即使可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。

如果对象被判定为有必要执行finalize()方法，那么这个对象将会放置在一个叫做F-Queue的队列中，并在稍后由一个虚拟机自动建立的、低优先级的Finalizer线程去执行它。这里所谓“执行”是指虚拟机会触发这个方法，但不承诺会等待它运行结束。原因是：一个对象finalize()执行缓慢或者发生了死循环，会导致F-Queue队列中其他对象永久处于等待。

任何一个对象的finalize()方法都只会被系统自动调用一次。

建议大家避免使用finalize()。

3.2.5 回收方法区

永久代的垃圾收集主要回收两部分内容：废弃常量和无用的类。

类要同时满足下面3个条件才算是“无用的类”：

• 该类的所有实例都已经被回收，也就是Java堆中不存在该类的任何实例。
• 加载该类的ClassLoader已经被回收。
• 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

虚拟机可以对满足上述3个条件的无用类进行回收。是多对类进行回收，HotSpot提供了-Xnoclassgc参数进行控制，还可以使用-verbose:class以及-XX:+TraceClassLoading、-XX:+TraceClassUnLoading查看类加载和卸载信息，其中-verbose:class和-XX:+TraceClassLoading可以在Product版的虚拟机中使用，-XX:+TraceClassUnLoading参数需要FastDebug版的虚拟机支持。

在大量使用反射、动态代理、CGLib等ByteCode框架、动态生成JSP以及OSGi这类频繁自定义ClassLoader的场景都需要虚拟机具备类卸载的功能，以保证永久代不会溢出

3.3 垃圾收集算法

3.3.1 标记-清除算法

最基础的收集算法是“标记-清除”（Mark-Sweep）算法，分为“标记”和“清除”两个阶段。 主要不足有两个：一是效率问题，标记和清除两个过程效率都不高；另一个是空间问题，产生大量不连续的内存碎片。

3.3.2 复制算法

Copying，将可用内存划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

现代商业虚拟机都采用这种收集算法来回收新生代。 并不需要1：1的比例来划分内存空间。而是分为一块较大的Eden和两块较小的Survivor，每次使用Eden和其中一块Survivor HotSpot虚拟机默认Eden和Survivor大小比例是8：1 当Survivor空间不够时，需要依赖其他内存（这里指老年代）进行分配担保（Handle Promotion）。

3.3.3 标记-整理算法

老年代不能直接选用复制收集算法。

“标记-整理”（Mark-Compact）算法过程和“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活对象都向一端移动，然后直接清理掉段边界之外的内存。

3.3.4 分代收集算法

当前商业虚拟机的垃圾收集都采用“分代收集”（Generational Collection）算法，只是根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代。 新生代：复制算法 老年代：“标记-清理”或者“标记-整理”算法

3.4 HotSpot的算法实现

3.4.1 枚举根节点

方法区很大，如果逐个检查，消耗很多时间

GC停顿 枚举根节点时需要停顿所有的Java执行线程

目前主流Java虚拟机使用的都是准确式GC，所以当执行系统停顿下来后，并不需要一个不漏地检查所有执行上下文和全局的引用位置，虚拟机应当是有办法直接得知那些地方存放着对象引用。在HotSpot的实现中，使用一组称为OopMap的数据结构。类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用。这样，GC在扫描时就可以直接得知这些信息了。

3.4.2 安全点

可能导致引用关系变化，或者说OopMap内容变化的指令非常多，如果为每一条指令都生成对应的OopMap，那将会需要大量的额外空间

只在特定位置记录了这些信息，这些位置称为安全点（Safepoint），即程序执行时并非在所有地方都能停顿下来开始GC，只有到达安全点时才能暂停。 安全点的选定基本上是以程序“是否具有让程序长时间执行的特征”为标准进行选定的 “长时间执行”的最明显特征就是指令序列复用，例如方法调用、循环跳转、异常跳转等，所以这些功能的指令才会产生Safepoint。

抢先式中断（Preemptive Suspension）和主动式中断（Voluntary Suspension）。抢先式中断不需要线程的执行代码主动去配合，在GC发生时，首先把所有线程全部中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让它“跑”到安全点上。现在几乎没有虚拟机实现采用抢先式中断来暂停线程从而响应GC事件。

而主动式中断的思想是当GC需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起。轮询标志的地方和安全点是重合的，另外再加上创建对象需要分配内存的地方。

3.4.3 安全区域

使用Safepoint似乎已经完美地解决了如何进入GC的问题，但实际情况却不一定。Safepoint机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safepoint，但是，程序“不执行”的时候呢？所谓程序不执行就是没有分配CPU时间，典型的例子就是线程处于Sleep状态或者Blocked状态。对于这种情况，需要安全区域（Safe Region）来解决。

安全区域是指在一段代码片段之中，引用关系不会发生变化。在这个区域中的任意地方开始GC都是安全的。我们也可以把Safe Region看作是扩展了的Safepoint

线程执行到Safe Region中的代码时，首先标识自己已经进入了Safe Region，那样，当在这段时间里JVM要发起GC时，就不用管标识自己为Safe Region状态的线程了。在线程要离开Safe Region时，它要检查系统是否已经完成了根节点枚举（或者是整个GC过程），如果完成了，那线程就继续执行，否则它就必须等待直到收到可以安全离开Safe Region的信号为止。

3.5 垃圾收集器

3.5.1 Serial收集器

单线程收集器 垃圾收集时，必须暂停其他所有工作线程，直到它收集结束

新生代：复制 暂停所有 单线程 老年代：标记-整理 暂停所有 单线程

Client模式下默认新生代收集器。

3.5.2 ParNew收集器

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

新生代：复制 暂停所有 多线程 老年代：标记-整理 暂停所有 单线程

Server模式下虚拟机中首选的新生代收集器。 除Serial之外，只有它能与CMS（Concurrent Mark Sweep）配合工作。

-XX:+UseConcMarkSweepGC选项后的默认新生代收集器，也可以使用-XX:+UseParNewGC选项来强制指定它。

-XX:ParallelGCThreads参数来限制垃圾收集的线程数。

注意：并发（Concurrent）指用户线程和垃圾收集线程同时执行（但不一定是并行的，可能会交替执行）和并行（Parallel）指多条垃圾收集线程并行工作，用户线程仍然处于等待状态

3.5.3 Parallel Scavenger 收集器

新生代收集器 复制算法 多线程收集器

目标则是达到可控制的吞吐量（Throughput）。所谓吞吐量是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)

停顿时间越短越适合与用户交互的程序 高吞吐量则适合后台运算不需要太多交互的任务。

控制最大垃圾收集停顿时间的-XX:MaxGCPauseMills参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数。

GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的。

Pallel Scavenger收集器也经常称为“吞吐量优先”收集器。 -XX:+UseAdaptiveSizePolicy值得关注。这是一个开关参数，当这个参数打开后，就不需要手工指定新生代的大小（-Xmn）、Eden和Survivor区的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为GC自适应的调节策略（GC Ergonomics）。 只需要把基本内存数据设置好（-Xmx设置最大堆），然后使用MaxGCPauseMills参数（更关注最大停顿时间）或GCTimeRatio（更关注吞吐量）参数给虚拟机设立一个优化目标，那具体细节参数的调节工作就由虚拟机完成了。

3.5.4 Serial Old 收集器

Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器 “标记-整理”算法 主要给Client模式下的虚拟机使用。Server模式下，那么它主要还有量大用途：一种是在JDK 1.5以及之前的版本中与Parallel Scavenger收集器搭配使用，另一种是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。

3.5.5 Parallel Old 收集器

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

直到Parallel Old收集器出现后，“吞吐量优先”收集器终于有了比较名副其实的应用组合，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenger加Parallel Old收集器。

3.5.6 CMS 收集器

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

“标记-清除”算法实现的，整个过程分为4个步骤，包括：

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

初始标记、重新标记仍然需要“Stop the World”.初始标记仅仅是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。

CMS是一款优秀的收集器：并发收集、低停顿。缺点：

• 对CPU资源非常敏感。 为了应付这种情况，虚拟机提供了一种称为“增量式并发收集器”（i-CMS）的CMS收集器变种，所做的和抢占式模拟多任务机制的思想一样。i-CMS被声明为deprecated，不再提倡用户使用
• CMS收集器无法处理浮动垃圾（Floating Garbage），可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。 要是CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以说参数-XX:CMSInitiatingOccupancyFraction设置得太高很容易导致大量“Concurrent Mode Failure”失败，性能反而降低。
• 空间碎片过多时，给大对象分配带来很大麻烦。 没有足够大的连续空间导致提前出发一次Full GC。 -XX:UseCMSCompactAtFullCollection开关参数（默认开启），用于在CMS收集器顶不住要进行Full GC时开启内存碎片的合并整理过程，内存整理无法并发，停顿时间不得不变长。 -XX:CMSFullGCsBeforeCompaction，这个参数用于设置执行多少次不压缩的Full GC后，跟着来一次带压缩的（默认为0，表示每次进入FullGC时都进行碎片整理）

3.5.7 G1收集器

G1(Gabage-First)收集器是当今收集器技术的最前沿成果之一

G1是一款面向服务器端应用的垃圾收集器。HotSpot开发团队赋予它的使命是（在较长期的）未来可以替换掉JDK 1.5 发布的CMS收集器。G1具备如下特点：

• 并行与并发
• 分代收集
• 空间整合
• 可预测的停顿

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

G1收集器之所以可预测停顿，是因为它有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region（也就是Garbage-First名称的来由）。

在G1收集器中，Region之间的对象引用以及其他收集器中新生代和老年代之间的对象引用，虚拟机都是使用Remembered Set来避免全堆扫描的。G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region中（在分代的例子中就是检查是否老年代中的对象引用了新生代中的对象），如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set中。当进行内存回收时，在GC根节点枚举范围中加入Remembered Set 即可保证不对全堆扫描也不会有遗漏。

不计算维护Remembered Set的操作，G1收集器的运作大致可划分为：

• 初始标记，停顿线程、耗时短
• 并发标记，耗时长、可并发
• 最终标记，停顿线程、可并行
• 筛选回收

初始标记仅仅是标记一下GC Roots能直接关联到的对象，并且修改TAMS（Next Top at Mark Start） 并发标记从GC Root开始对堆中对象进行可达性分析，找出存活对象 最终标记为了修正在并发标记时因用户程序继续运作而导致标记产生变动的那部分标记记录，虚拟机将这段对象变化记录在线程Remembered Set Logs里面，然后合并到Remembered Set。 筛选回收先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间指定回收计划。

3.5.8 理解GC日志

FullGC的“Full”说明这次GC是发生了Stop-The-World的。

3.5.9 垃圾收集器参数总结

参数	描述
UseSerialGC	虚拟器运行在Client模式下的默认值，打开此开关后，使用Serial+Serial Old
UseParNewGC	打开此开关后，使用ParNew+Serial Old
UseConcMarkSweepGC	打开此开关后，使用ParNew+CMS+Serial Old，Serial Old作为CMS出现Concurrent Mode Failure后的后备收集器使用
UseParallelGC	虚拟器运行在Server模式下的默认值，打开此开关后，使用Parallel Scavenger+Serial Old（PS MarkSweep）的收集器组合进行内存回收
UseParallelOldGC	打开此开关后，使用Parallel Scavenger + Parallel Old
SurvivorRatio	新生代中Eden区和Survivor区的容量比值，默认为8，表示Eden：Survivor=8：1
PretenureSizeThreshold	直接晋升到老年代的对象大小，设置这个参数后，大于这个参数的对象直接在老年代分配
MaxTenuringThreshold	晋升到老年代的对象年龄，每个对象在坚持过一次Minor GC之后，年龄就增加1，当超过这个参数值时就进入老年代
UseAdaptiveSizePolicy	动态调整Java堆中各个区域的大小和进入老年代的年龄
HandlePromotionFailure	是否允许分配担保失败
ParallelGCThreads	设置并行GC时进行内存回收的线程数
GCTimeRatio	GC时间占总时间的比率，默认为99，即允许1%的GC时间，仅在Parallel Scavenger收集器时生效
MaxGCPauseMills	设置GC最大停顿时间，仅在使用Parallel Scavenger收集器时生效
CMSInitiatingOccupancyFraction	设置CMS收集器在老年代空间被使用多少后触发垃圾收集。默认值为68%，仅在使用CMS时生效
UseCMSCompactAtFullCollection	设置CMS收集器在完成垃圾收集后是否要进行一次内存碎片整理。仅在CMS时生效
CMSFullGCsBeforeCompaction	设置CMS收集器在进行若干次垃圾收集后再启动一次内存碎片整理。仅在使用CMS收集器时生效。

3.6 内存分配与回收策略

3.6.1 对象优先在Eden分配

注意：新生代GC（Minor GC）：指在新生代的垃圾收集动作

老年代GC（Major GC/Full GC）：指发生在老年代的GC，出现了Major GC,经常会伴随至少一次的MinorGC（但非绝对），MajorGC的速度一般会比Minor GC慢10倍以上。

3.6.2 大对象直接进入老年代

大对象是指，需要大量连续内存空间的Java对象。

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

对象在Survivor区每熬过一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁），就将晋升到老年代中

3.6.4 动态对象年龄判定

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

3.6.5 空间分配担保

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