【深入理解Java虚拟机】第三章 垃圾收集器与内存分配策略

3.2 对象已死吗

3.2.1 引用计数法

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

但主流的JVM没有选用引用计数法来管理内存，因为很难解决对象之间相互循环引用的问题

3.2.2 可达性分析算法

通过一系列称为“GC Root”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连时，则此对象是不可用的。

在上图中，虽然obj5，obj6和obj7之间存在引用，但它们到GC Roots是不可达的，所以会被判定为可回收对象

Java中，可作为GC Roots对象包括下面几种：

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

3.2.3 再谈引用

引用分类的目的：当内存空间还足够时，则保留在内存中；如果内存空间在进行GC后还是很紧张，则可以抛弃。

因此，将引用分为：

• 强引用，代码中普遍存在，类似“Object obj = new Object()”这类的引用，只要强引用还存在，GC就不会回收被引用的对象
• 软引用，描述一些还有用但并非必须的对象。对于软引用关联的对象，在系统将要发生内存溢出异常前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。
• 弱引用，描述非必须对象，其强度比软引用更弱，被弱引用关联的对象智能生存到下一次GC发生之前。当GC时，无论当前内存是否足够，都会被回收。
• 虚引用，也称为幽灵引用或者幻影引用，最弱的一种引用关系。一个对象是否有虚引用存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。唯一目的就是能在该对象被GC时收到一个系统通知。

3.2.4 生存还是死亡

即使在可达性分析算法中不可达的对象，此时也只是处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程：

1. 可达性分析后发现没有与GC Roots相连接的引用链，将会被第一次标记并且进行一次筛选，条件是此对象是否用必要执行finalize()。

   1. 当对象没有覆盖finalize()或finalize()已经被JVM调用过，JVM将这两种情况视为“没有必要执行”。

   2. 若该对象被判定有必要执行finalize()，那么这个对象将会放置在一个叫做F-Queue的队列中，并在稍后有一个JVM自动建立的、低优先级的Finalizer线程去执行。

      这里的的“执行”是指JVM会触发这个方法，但并不承诺会等待它运行结束，因为：若一个对象在finalize()中执行缓慢，或发生死循环，很可能导致F-Queue中其他对象永久处于等待，甚至导致整个内存回收系统崩溃。

2. 如果对象要在finalize()中拯救自己，只要重新与引用链上的任何对象建立关联即可，比如把this关键字赋值给某个变量或者对象的成员变量，那在第二次标记时它将被移除“即将回收”的集合。

3.2.5 回收方法区

永久代的GC主要回收两部分：

1. 废弃常量，没有任何String对象引用，也没有其它地方引用时，如果这时发生内存回收，且必要的话，该常量就会被清理
2. 无用的类：满足以下条件
   1. 该类所有实例都已经被回收
   2. 加载该类的ClassLoader已经被回收
   3. 该类对应的Class对象没有被引用，无法在任何地方通过反射访问该类的方法

3.3 垃圾收集算法

3.3.1 标记-清除算法

算法分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。

不足：

1. 效率问题，标记和清除两个过程的效率都不高
2. 空间问题，标记清除后产生大量不连续的内存碎片，空间碎片太多可能导致以后再程序运行过程中需要分配较大对象时，无法找到足够的连续内存而提前触发另一次GC。

3.3.2 复制算法

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

代价是将内存缩小为原来的一半。

3.3.3 标记-整理算法

标记过程与“标记-清除”算法一样，但后续步骤是让所有存活对象都像一端移动，然后直接清理掉端边界以外的内存。

3.3.4 分代收集算法

根据对象存活周期不同将内存划分为几块。

一般是分为：

1. 新生代，每次垃圾收集时都有大量对象死去，只有少量存活，使用复制算法，只需要付出少量存活对象的复制成本就可以完成收集
2. 老年代，对象存活率高、没有额外空间对它进行分配担保，就使用“标记-清理”或“标记-整理”进行回收

3.5 垃圾收集器

3.5.1 Serial收集器

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

JVM在Client模式下的默认新生代收集器，与其他收集器的单线程比简单而高效，对于限定单个CPU环境，没有线程交互的开销

3.5.2 ParNew收集器

Serial收集器的多线程版本。

许多JVM在Server模式下中首选的新生代收集器，因为目前除了Serial收集器外，只有它能与CMS配合工作

3.5.3 Parallel Scavenge收集器

新生代收集器，使用复制算法，并行的多线程收集器。

目标是达到一个可控制的吞吐量。

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

高吞吐量可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务

GC自适应调节策略：JVM根据当前系统的运行情况收集性能监控信息，动态调整参数以提供最合适的停顿时间或最大吞吐量

3.5.4 Serial Old 收集器

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

主要意义：Client模式下的JVM使用

Server模式下用途：

1. JDK1.5及之前的版本中与Parallel Scanvenge收集器搭配使用
2. 作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用

3.5.5 Parallel Old收集器

Parallel Scanvenge收集器的老年代版本，使用多线程和“标记-整理”算法

与Parallel Scanvenge配合使用

3.5.6 CMS收集器

以获取最短回收停顿时间为目标，有并发收集、低停顿的优点

基于“标记-清除”算法，整个过程分为四个步骤：

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

其中，初始标记、重新标记仍然需要“Stop The World”。

1. 初始标记只是标记一下GC Roots能直接关联的对象，速度很快；
2. 并发标记就是进行GC Roots Tracing过程；
3. 重新标记是为了修正并发标记期间因用户程序继续运行继续运作而导致标记产生变动的那部分对象的标记记录该阶段停顿时间一般会比初始标记稍长，但远比并发标记短

耗时最长的并发标记与并发清除过程，收集器线程都可以与用户线程一起工作，所以，总体上来说，CMS收集器的内存回收是与用户线程一起并发执行的。

缺点：

1. 对CPU资源非常敏感。在并发阶段虽然不会导致用户线程停顿，但是会因为占用了一部分CPU资源而导致应用程序变慢，总吞吐量降低
2. 无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。
   1. 浮动垃圾：CMS并发清理阶段用户线程还在运行，自然就还会与新的垃圾产生，这部分垃圾出现在标记过程之后，就无法再当次收集中处理掉，只能留到下一次
   2. Concurrent Mode Failure：CMS运行期间预留的内存无法满足程序需要时出现，此时会临时起用Serial Old来重新进行老年代的垃圾收集，这样停顿时间就很长了
3. 基于”标记-清除“的CMS会导致收集结束时有大量空间碎片产生。往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一侧Full GC

3.5.7 G1收集器

Garbage-First收集器面向服务端应用，具备以下特点：

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

G1中将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，他们都是一部分Region（不需要连续）的集合。

G1跟踪各个Region中垃圾堆积的价值大小（回收所获得的空间预计回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。这种方式保证了G1在有限的时间内可以获取尽可能高的效率。

G1的运作大致可划分为以下几个步骤：

1. 初始标记：标记一下GC Roots能直接关联到的对象，并修改NAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这阶段需要停顿线程，但耗时很短
2. 并发标记：从GC Roots开始对堆中对象进行可达性分析，找出存活对象，这阶段耗时较长，但可与用户程序并发执行
3. 最终标记：修正在并发标记期间因用户线程继续运作而导致标记产生变动的那一部分标记记录，这阶段需要停顿线程，但是可并行执行
4. 筛选回收：先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划，也可以做到与用户程序一起并发执行

3.6 内存分配与回收策略

3.6.1 对象优先在Eden分配

大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间时，JVM将发起一次Minor GC

新生代GC（Minor GC）：指发生在新生代的GC，因对象大多都朝生夕灭，所以MinorGC非常频繁，一般回收速度也比较快

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

3.6.2 大对象直接进入老年代

大对象指需要大量连续内存空间的对象

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

JVM给每个对象定义了一个对象年龄计数器。

如果对象在Eden出生并经过第一次Minor GC后仍存活，且能被Survivor容纳的话，将被移动到Survivor空间，并将对象年龄设为1。对象在Survivor区中每“熬过”一次Minor GC，年龄就增加1岁，当年龄增加到一定程度（默认15，可设置），就会被加入到老年代中。

3.6.4 动态对象年龄判定

为了更好地适应不同程序的内存状况，JVM并不是永远要求对象年龄必须达到一定值才能进入老年代，如果Survivor中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象可直接进入老年代。

3.6.5 空间分配担保

在发生Minor GC前，JVM会先检查老年代最大可用连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC是安全的；

如果不成立，则JVM会查看HandlePromotionFailure设置值是否允许担保失败

如果允许，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代对象的平均大小

如果大于，将尝试进行一次Minor GC（有风险）

如果小于，或者HandlePromotionFailure设置不允许冒险，此时也要改为进行一次Full GC