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

　　1. 为什么要了解垃圾收集和内存分配？主要针对虚拟机的哪些区域？

　　垃圾收集（Garbage Collection）经过半个世纪的发展，内存动态分配与内存回收技术已经相当成熟，似乎进入了“自动化”时代。

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

　　程序计数器、虚拟机栈、本地方法栈3个区域随线程而生，随线程而灭，栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作。当方法或线程结束时，内存就会随之回收。

　　Java堆和方法区则有显著的不确定性：一个接口的多个实现类需要的内存可能会不一样，一个方法所执行的不同条件分支所需要的内存也不一样，只有处于运行期间，我们才能知道程序究竟会创建哪些对象，创建多少个对象，这部分内存的分配和回收是动态的。垃圾回收器正式负责分配和回收这部分内存。

　　2. 如何判断对象是“存活”还是“死去”？

　　2.1 引用计数算法

　　在对象中添加一个引用计数器，每当有一个地方引用它时，计数器值加一；引用失效时，计数器值就减一；任何时刻计数器为零的对象就是不可能再被使用的。

　　这个简单的算法需要配合大量额外处理才能保证正确工作，比如单纯的引用计数很难解决对象之间的循环引用问题。参考博客：https://www.codenong.com/176745/。

　　2.2 可达性分析算法

　　通过一系列称为“GC roots”的根对象作为起始节点集，从这些节点开始根据引用关系向下搜索，搜索过程中所走过的路径称为“引用链”（Reference Chain），如果某个对象到GC Roots间没有任何引用链相连，则说明此对象不可能再被使用。

　　 

　　GC Roots对象包括以下几种：

• 在虚拟机栈（栈帧中的本地变量表）中引用的对象，比如当前正在运行的方法所使用到的参数，局部变量，临时变量等
• 在方法区中类静态属性引用的对象，比如Java类的引用类型静态变量
• 在方法区中常量引用的对象，比如字符串常量池里的引用
• 在本地方法栈中JNI引用的对象
• Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象等，还有系统类加载器
• 所有被同步锁（synchronized关键字）持有的对象
• 反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存

　　除了这些固定的GC Roots集合以外，根据用户所选用的垃圾收集器以及当前回收的内存区域不同，还会有其他对象加入。比如后面会提到的分代收集和局部回收（Partial GC），某个区域里的对象可能被堆中其他区域的对象所引用，这时需要把关联区域的对象一并加入GC Roots集合中去。

　　2.3 引用

• 强引用 类似Object obj = new Object()， 只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象
• 软引用  描述一些还有用，但非必须的对象。在系统将要发生内存溢出异常前，会把这些对象列进回收范围中进行二次回收。
• 弱引用  描述一些非必须的对象，但是它的强度比软引用更弱，被弱引用关联的对象只能生存到下一次垃圾收集发生为止
• 虚引用  是最弱的一种引用关系。无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的是在对象被收集器回收时收到一个系统通知。

　　2.4 回收方法区

　　方法区垃圾收集的性价比较低：在Java堆中，尤其在新生代中，对常规应用进行一次垃圾收集通常可以回收70%至99%的内存空间，方法区回收囿于苛刻的判定条件，其区域垃圾收集的回收成果往往远低于此。

　　方法区的垃圾收集主要回收两部分内容：废弃的常量和不再使用的类型。

　　假如一个字符串“Java”曾经进入常量池中，但是当前系统又没有任何一个字符串对象的值是“Java”，且虚拟机中没有其他地方引用这个字面量。如果这时发生内存回收，而且垃圾收集器判断确有必要的话，这个常量将会被系统清理出常量池。常量池中其他类（接口）、方法、字段的符号引用的判断也与此类似。

　　对于判断一个类型是否属于“不再被使用的类”的条件：

• 该类所有的实例都已经被回收，也就是Java堆中不存在该类及其任何派生子类的实例
• 加载该类的类加载器已经被回收，这个条件除非是精心设计的可替换类加载器的场景，如OSGi、JSP的重加载等，否则通常是很难达成的
• 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法

　　在大量使用反射、动态代理、CGLib等字节码框架，动态生成JSP以及OSGi这类频繁自定义类加载器的场景中，通常需要Java虚拟机具备类型卸载能力，以保证不会对方法区造成过大的内存压力

　　3. 追踪式垃圾收集算法

　　3.1 分代收集理论

　　分代收集理论建立在如下假说之上：

　　1） 弱分代假说（Weak Generational Hypothesis）绝大多数对象都是朝生夕灭的

　　2） 强分代假说（Strong Generational Hypothesis）熬过越多次垃圾收集过程的对象就越难以消亡

　　上面两个假说共同奠定了多款常用垃圾收集器的一致设计原则：垃圾收集器应该将Java堆划分出不同的区域，然后将回收对象按照其年龄（年龄即对象熬过垃圾收集过程的次数）分配到不同区域之中存储。

　　如果一个区域中大多数对象都是朝生夕灭的，那么把它们几种放在一起，每次收集只关注怎样保存少量存活而不是去标记那些大量将要被回收的对象，就能以较低的代价回收大量的内存；对于剩下难以消亡的对象，把它们集中放在一起，虚拟机便可以使用较低的频率来回收这个区域，这样同时兼顾了垃圾收集的时间开销和内存空间的有效利用。

　　3） 跨带引用假说

　　如前文提到过的，由于对象不是孤立的，所以对象之间会存在跨带引用。

　　存在互相引用关系的两个对象，应该是倾向于同时生存或者同时消亡的。

　　在新生代建立一个全局的数据结构（记忆集，后续会有介绍），这个结构把老年代划分成若干小块，表示出老年代的哪一块内存存在跨带引用。此后，当发生Minor GC时，只有包含了跨带引用的小块内存里的对象才会被加入到GC Roots进行扫描。虽然这种方法需要在对象改变引用关系时维护记录数据的正确性，会增加一些运行时的开销，但比起收集时扫描整个老年代来说仍是划算的。

• 部分收集（Partial GC）
  • 新生代收集（Minor GC/ Young GC）
  • 老年代收集（Major GC/ Old GC）
  • 混合收集 （Mixed GC）
• 整堆收集（Full GC）　　

　　3.2 标记 - 清除算法

　　首先标记出所有需要回收的对象，标记完成后，统一回收掉所有被标记的对象。该算法有两个缺点：

• 执行效率不稳定，如果Java堆中包含大量对象，而且大部分都是需要回收的，这时必须进行大量的标记和清除动作，导致标记和清除的执行效率随对象数量增长而降低
• 内存空间的碎片化问题，标记和清除会产生大量不连续的内存碎片，当需要分配较大对象时，由于无法找到连续的内存空间进行存储，需要进行另一次垃圾收集动作

　　 

　　3.3 标记 - 复制算法

　　把新生代分为一块较大的Eden空间和两块较小的Survivor空间。默认Eden和Survivor的大小比例为8:1.将对象载入Eden区中，当内存接近用完时，将还存活的对象移动到survivor区中，并将Eden区清除。如果存活的对象太大，survivor区存放不了，就通过分配担保机制直接放入老年代。

　　该算法不用考虑空间碎片的复杂情况，只要移动堆顶指针，按顺序分配即可。

　　3.4 标记 - 整理算法

　　标记 - 复制算法在对象存活率较高时就要进行较多的复制操作，效率会降低。

　　标记 - 整理算法的标记过程仍然与标记 - 清除算法一样，后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向内存空间一端移动，然后直接清理掉边界以外的内存。

·　　

 　　如果移动存活对象，尤其是在老年代这种每次回收都有大量对象存活区域，移动存活对象并更新所有引用这些对象的地方需要全程暂停用户应用程序才能进行，即“Stop The World”.

　　而标记 - 清除算法这种不考虑移动和整理存活对象的话，空间碎片化问题依赖更为复杂的内存分配器和内存访问器来解决。比如通过“分区空闲分配链表”来解决内存分配问题（计算机硬盘存储大文件就不要求物理连续的磁盘空间，能够在碎片化的磁盘上存储和访问就是通过硬盘分区表实现的）。

　　是否移动对象都存在弊端，移动则内存回收时会更复杂，不移动内存分配时会更复杂。HotSpot虚拟机里面关注吞吐量的Parallel Old收集器基于标记 - 整理算法的，关注延迟的CMS收集器则是基于标记 - 清除算法的。

　　4. HotSpot算法实现细节

　　4.1 根节点枚举

　　随着Java应用越做越大，光是方法区的大小就有数百上千兆，里面的类、常量更是恒河沙数，如要逐个检查以这里为起点的引用会耗费很多时间。

　　迄今为止，所有收集器在根节点枚举必须暂停用户线程，Stop The World。当用户线程停下来以后，并不需要一个不漏的检查完所有执行上下文和全局的引用位置。HotSpot虚拟机使用一组称为OopMap的数据结构。一旦类加载完成，HotSpot会把对象内什么偏移量上是什么类型的数据计算出来，在即时编译过程中，也会在特定的位置记录下栈里和寄存器里哪些位置是引用。

　　下面代码清单3-3是HotSpot虚拟机客户端模式下生成的一段String::hashCode()方法的本地代码，可以看到0x026eb7a9处的call指令有OopMap记录，它指明了EBX寄存器和栈中偏移量为16的内存区域中各有一个普通对象指针（Ordinary Object Pointer）的引用，有效范围为从call指令开始直到0x026eb730（指令流的起始位置）+142（OopMap记录的偏移量）= 0x026eb7be，即hlt指令为止。

[Verified Entry Point]
0x026eb730： mov   %eax, -0x8000（%esp）
……
;; ImplicitNullCheckStub slow case
0x026eb7a9： call 0x026e83e0     ; opMap{ebx=Oop[16]=Oop off=142}
                                 ; *caload
                                 ; -java.lang.String： hashCode@48（line 1489）
                                 ; {runtime_call}
0x026eb7ae： push $0x83c5c18     ; {external_word}
0x026eb7b3： call 0x026eb7b8
0x026eb7b8： pusha
0x026eb7b9： call 0x0822bec0     ; {runtime_call}
0x026eb7be： hlt

　　4.2 安全点

　　在OopMap的协助下，HotSpot可以快速准确地完成GC Roots枚举。但是，如果为每一条指令都生成对应的OopMap，需要大量的额外存储空间。

　　实际上HotSpot并非为每条指令都生成OopMap，只是在指定位置记录了这些信息，这些位置称为安全点。用户程序必须执行到安全点后才会暂停。安全点位置选取基本上以“是否具有让程序长时间执行的特征”为标准进行选定。“长时间执行”最明显的特征就是指令序列的复用，例如方法调用、循环跳转、异常跳转等，所以具有这些功能的指令才会产生安全点。

　　另一个需要考虑的问题是如何在垃圾收集发生时让所有线程都跑到最近的安全点：

• 抢先式中断（Preemptive Suspension）系统首先把所有线程全部中断，如果发现有用户线程中断的地方不在安全点上，就恢复这条线程，让其跑到安全点上，再中断。目前几乎没有虚拟机采用这种方式了。
• 主动式中断（Voluntary Suspension）不直接对线程操作，仅仅简单地设置一个标志位，各个线程执行过程时会不停地主动轮询这个标志，一旦发现中断标志为真时就自己在最近的安全点上主动中断挂起。

　　HotSpot使用内存保护陷阱的方式，把轮询操作精简至只有一条汇编指令的程度。下表程序清单的test指令就是HotSpot生成的轮询指令，当需要暂停用户线程时，虚拟机把0x160100的内存页设置为不可读，那线程执行到test指令时就会产生一个自陷异常信号，然后在预先注册的异常处理器中挂起线程实现等待，这样仅通过一条汇编指令便完成安全点轮询和触发线程中断了。

0x01b6d627： call 0x01b2b210   ; OopMap{[60]=Oop off=460}
                               ; *invokeinterface size
                               ; -Client1： main@113（line 23）
                               ; {virtual_call}
0x01b6d62c： nop               ; OopMap{[60]=Oop off=461}
                               ; *if_icmplt
                               ; -Client1： main@118（line 23）
0x01b6d62d： test  %eax, 0x160100; {poll}
0x01b6d633： mov   0x50(%esp), %esi
0x01b6d637： cmp   %eax, %esi

　　4.3 安全区域

　　安全点机制保证了程序执行时，在不太长的时间就会遇到可进入垃圾收集过程的安全点。但是，程序不执行的时候呢？所谓的程序不执行就是没有分配处理器时间，典型的场景便是用户线程处于Sleep状态或者Blocked状态，这时候线程无法响应虚拟机的中断请求，不能在走到安全的地方去中断挂起自己。

　　安全区域是指能够确保某一段代码片段之中，引用关系不会发生变化，在这个区域中任意地方开始垃圾收集都是安全的。

　　当用户线程执行到安全区域里面的代码时，首先会标识自己进入到安全区域，当虚拟机需要发起垃圾收集时就不必去管这些已声明自己在安全线程内的线程了。

　　当线程要离开安全区域时，需要检查根节点是否完成了根节点枚举，如果没有，需要一直等待，直到收到可以离开安全区域的信号。

　　4.4 记忆集与卡表

　　前面提到过为了解决跨代引用的问题，垃圾收集器会在新生代建立名为记忆集的数据结构。

　　记忆集是一种用于记录从非收集区域指向收集区域的指针集合的抽象数据结构。记录全部含跨代引用对象的实现方案，无论是空间占用还是维护成本都相当高昂，实际场景中收集器只需要通过记忆集判断某一块非收集区域是否存有指向了收集区域的指针即可，即卡精度。

　　卡表是记忆集的一种具体实现，它定义了记忆集的记录精度、堆内存的映射关系等。

　　CARD_TABLE [ this address >> 9 ] = 0;

　　字节数组CARD_TABLE的每一个元素都对应着其标识的内存区域中一块特定大小的内存块，这个内存块被称作“卡页”（Card Page）。一般来说，卡页的大小都是以2的N次幂的字节数。一个卡页的内存中通常包含不止一个对象，只要卡页内有一个（或更多）对象的字段存在着跨代指针，就将对应卡表的数组元素的值标识为1，称这个元素变脏。在垃圾收集发生时，只要筛选出卡表中变脏的元素，就能轻易得出哪些卡页内存块中包含跨代指针，把它们加入GC Roots中一并扫描。　　

　　4.5 写屏障

　　通过记忆集可以缩减GC Roots扫描范围问题，但是卡表元素如何维护，例如，谁来把它们变脏？

　　假如是解释执行的字节码，虚拟机负责每条字节码指令的执行，有充分的介入空间；但在编译执行的场景中呢？即时编译后的代码已经是纯粹的机器指令流了。

　　在HotSpot虚拟机里通过写屏障（write barrier）技术维护卡表状态的。写屏障可以看做在虚拟机层面对“引用类型字段赋值”这个动作的AOP切面，在引用对象赋值时会产生一个环形通知，供程序执行额外的动作，即赋值的前后都在写屏障的覆盖范围内。　　

void oop_field_store(oop* field, oop new_value) {
        // 引用字段赋值操作
        *field = new_value;
        // 写后屏障
        post_write_barrier(field, new_value);

}

　　应用写屏障后，虚拟机就会为所有赋值操作生成相应的指令，一旦收集器在写屏障中增加了更新卡表操作，无论更新的是不是老年代对新生代对象的引用，每次只要对引用进行更新，将会产生额外的开销，不过这个开销相比于Minor GC时，扫描整个老年代的代价相比低得多。

　　除了写屏障开销外，卡表在高并发场景下还面临着“伪共享”问题。现代中央处理器的缓存系统中是以缓存行为单位存储的，当多线程修改互相独立的变量时，如果这些变量恰好共享同一个缓存行，就会彼此影响（写回，无效化或者同步）而导致性能降低。

　　为了避免伪共享问题，一个简单的解决方案是不采用无条件的写屏障，而是先检查卡表标记，只有当卡表元素被标记过，才将其标记为变脏。　　

　　4.6 并发的可达性分析

　　从GC Roots继续往下遍历对象图，这一步骤的停顿时间与Java堆容量成正比关系。引入三色标记把遍历对象图过程中遇到的对象，按照“是否访问过”标记为以下三种颜色：

• 白色：对象尚未被垃圾收集器访问过。在可达性分析开始阶段，所有对象都是白色的，若分析结束阶段，仍然是白色对象，即代表不可达。
• 黑色：对象已被垃圾收集器访问过，且这个对象的所有引用都已经扫描过。黑色的对象代表它是安全存活的。
• 灰色：对象已经被垃圾收集器访问过，但这个对象上至少有一个引用没有被扫描过

　　如果用户线程与收集器并发工作，收集器在对象图上标记颜色，同时用户线程在修改引用关系——即修改对象图的结构，这会造成两种结果：

　　1） 把原本消亡的对象错标为存活，将产生一点逃过本次收集的浮动垃圾

　　2） 把原本存活的对象错误标记为已消亡，程序会因此发生错误

　　Wilson在1994年提出当且仅当满足以下两个条件时，会产生对象消失问题：

• 赋值器插入了一条或多条从黑色对象到白色对象的引用
• 赋值器删除了全部灰色对象到改白色对象的直接或间接引用

　　由此产生了两种解决方案：增量更新（Incremental Update）和原始快照（Snapshot At The Beginning, SATB）

　　增量更新破坏第一个条件，当黑色对象插入新的指向白色对象的引用关系时，就将这个新插入的引用记录下来，等并发扫描结束后，再将记录过的引用关系中的黑色对象为根，重新扫描一次。

　　原始快照破坏第二个条件，当灰色对象要删除指向白色对象的引用关系时，就将这个要删除的引用记录下来，在并发扫描结束后，再将这些记录过的引用关系中的灰色对象为根，重新扫描一次。

　　以上对引用关系记录的插入还是删除，虚拟机的记录操作都是通过写屏障实现的。

　　5. 经典垃圾收集器

　　如果两个收集器之间存在连线，就说明他们可以搭配使用。

　　

　　5.1 Serial收集器

　　Serial收集器是最基础、历史最悠久的收集器，是一个单线程工作的收集器。迄今为止，它是HotSpot虚拟机运行在客户端模式下的默认新生代收集器，与其他收集器的单线程相比，其简单高效垃圾收集的停顿时间可以控制在十几、几十毫秒，最多一百多毫秒以内。

　　 

　　5.2 Parallel Scavenge收集器

　　Parallel Scavenge收集器是一款新生代收集器，基于标记-复制算法实现的收集器，且能够并行收集。CMS收集器关注于尽可能地缩短垃圾收集时用户线程的停顿时间，Parallel Scavenge收集器则是达到一个可控制的吞吐量（Throughput）。吞吐量是处理器用于运行用户代码的时间与处理器总消耗时间的比值。 

 　　5.3 CMS收集器

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

　　CMS收集器基于标记清除算法实现的，整个过程分为四个步骤：

• 初始标记   标记GC Roots能直接关联到的对象
• 并发标记   从GC Roots遍历整个对象图
• 重新标记   修正对象标记，参考4.6 增量更新
• 并发清除   清理删除掉标记过程中判断为已经死亡的对象

　　 

　　CMS收集器有以下三个缺点：

• CMS收集器对处理器资源非常敏感。虽然它不会导致用户线程停顿，但由于占用了一部分线程（或者说处理器计算能力）而导致应用程序变慢，降低总吞吐量。
• CMS处理器无法处理浮动垃圾，有可能出现“Concurrent Mode Failure”失败进而导致另一次完全“Stop The World”的Full GC 的产生。在CMS的并发标记和并发清理阶段，用户线程还在继续运行，程序自然就会伴随对象的产生而出现垃圾，但这一部分垃圾对象出现在标记过程结束后，CMS只能留待下一次垃圾收集时再清理掉。由于用户线程在垃圾收集阶段还在运行，需要预留足够的内存空间提供给用户线程使用，如果预留的内存无法满足程序分配新对象的需要，就会出现“Concurrent Mode Failure”失败，虚拟机不得不冻结用户线程，临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就会加长。
• CMS是基于标记清除算法实现的。存在大量的空间碎片，对大对象的分配造成麻烦。

　　5.4 Garbage First收集器

　　G1是一款面向服务端应用的垃圾收集器。G1把连续的Java堆划分为多个大小相等的独立区域，每一个区域都可以根据需要扮演新生代的Eden空间、Survivor空间或者老年代空间。Region中还有一类特殊的Humongous区域，专门用来存储大对象。虽然G1保留了新生代和老年代的概念，但新生代和老年代不再是固定的，它们都是一系列区域的动态集合。

 　　

　　G1收集器的运作过程大致可以分为以下四个步骤：

• 初始标记（Initial Marking）：仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS指针的值（G1为每一个区域设计了两个名为TAMS的指针，把区域中的一部分空间划分出来用于并发回收过程中的新对象分配）让下一阶段用户线程并发运行时，能正确地在可用的Region中分配新对象。
• 并发标记（Concurrent Marking）：从GC Roots开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象。
• 最终标记（Final Marking）：用于处理并发阶段结束后仍遗留下来的少量SATB记录。
• 筛选回收（Live Data Counting and Evacuation）:负责更新Region的统计数据，对各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，把决定回收的那部分Region存活对象复制到空的Region中，再清理掉整个旧Region的全部空间。这里涉及存活对象的移动，所以需要暂停用户线程。

　　

 

　　从G1开始， 最先进的垃圾收集器的设计导向都不约而同地变为追求能够应付应用的内存分配速率（Allocation Rate） ，而不追求一次把整个Java堆全部清理干净。这样，应用在分配，同时收集器在收集，只要收集的速度能跟得上对象分配的速度，那一切就能运作得很完美。