《深入理解java虚拟机》读书笔记（二）：垃圾收集和内存分配策略

适用人群

jvm小白和复习本书内容的同学。

对象死亡否？

引用计数算法

很多教科书判断对象是否存活的算法是这样的：给对象中添加一个引用计数器，每当有 一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0 的对象就是不可能再被使用的。客观地说，引用计数算法（Reference Counting）的实现简单，判定效率也很高，在大部 分情况下它都是一个不错的算法，但是，至少主流 的Java虚拟机里面没有选用引用计数算法来管理内存，其中最主要的原因是它很难解决对象 之间相互循环引用的问题（比如：对象objA和objB都有字段 instance，赋值令objA.instance=objB及objB.instance=objA）。

可达性分析

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

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

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

1.2之后，Java对引用的概念进行了扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）4种，这4种引用强度依次逐渐减弱。

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

死缓

即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处 于“缓刑”阶段。
这时只有一种方法可以逃离被回收的命运：覆盖了finalize（）方法，并且该方法没有被调用过，并且在finalize()中重新与引用链上的任何对象建立起关联（譬如把自己this关键字赋值给某个类变量或者对象的 成员变量）。其余情况一律被回收。
注意：

• finalize（）方法只会被直行一次，如果对象面临下一次被回收，此时finalize（）方法将不会被调用。
• finalize（）它的运行代价高昂，不确定性大，无法保证各个对象的调用顺序。它能做的所有工作，使用try-finally或者其他方式都可以做得更好、更及时。大家完全可以忘掉Java语言中有这个方法的存在。

回收方式：如果这个对象被判定为有必要执行finalize（）方法，那么这个对象将会放置在一个叫做 F-Queue的队列之中，并在稍后由一个由虚拟机自动建立的、低优先级的Finalizer线程去执行 它。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束，这样做 的原因是，如果一个对象在finalize（）方法中执行缓慢，或者发生了死循环（更极端的情 况），将很可能会导致F-Queue队列中其他对象永久处于等待，甚至导致整个内存回收系统 崩溃。如果对象在finalize（）中成功拯救自己（见前文），它将被移除出“即将回收”的集合；如果对象这时候还没有逃 脱，那基本上它就真的被回收了。

垃圾收集算法

清除标记算法

首先标记出所有需要回收的对象，在标记完成后统一回收所有 被标记的对象。
不足：

• 一个是效率问题，标记和清除两个过程的效率都不高；
• 另一个是 空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程 序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
  

复制算法

为了解决效率问题，一种称为“复制”（Copying）的收集算法出现了，它将可用内存按容 量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着 的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

• 好处：内存分配时也就不用考虑内存碎片等复杂情况。实现简单，运行高效。
• 的代价是将内存缩小为了原 来的一半，未免太高了一点。
  
  IBM公司的专门研究表明，新生代中的对象98%是“朝生夕死”的，所以并不需要按照1:1的比例来划分内存空间，而是将内存 分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中一块Survivor[1]。

标记-整理算法

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

分代收集算法

一般是把Java堆 分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。如新生代使用复制算法，老年代采用标记-清理/整理算法。

HotSpot算法实现

在进行可达性分析时，不可以出现分析过程中对象引用关系还在不断变化的情况。
可作为GC Roots的节点主要在全局性的引用（例如常量或类静态属性）与执行上下文（例如栈帧中的本地变量表）中。在 HotSpot的实现中，是使用一组称为OopMap的数据结构来达到这个目的的，在类加载完成的 时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用。
HotSpot确没有为每条指令都生成OopMap，只是在“特定的 位置”记录了这些信息，这些位置称为安全点（Safepoint）。即程序执行时并非在所有地方都 能停顿下来开始GC，只有在到达安全点时才能暂停。
如何在GC发生时让所有线程（这里不包括执行 JNI调用的线程）都“跑”到最近的安全点上再停顿下来？
这里有两种方案可供选择：抢先式 中断（Preemptive Suspension）和主动式中断（Voluntary Suspension）。

• 抢占式中断（已经几乎不用了）： 其中抢先式中断不需 要线程的执行代码主动去配合，在GC发生时，首先把所有线程全部中断，如果发现有线程 中断的地方不在安全点上，就恢复线程，让它“跑”到安全点上。
• 主动式中断（Voluntary Suspension）：主动式中断的思想是当GC需要中断线程的时候，不直接对线程操作，仅仅简单地设 置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起。 轮询标志的地方和安全点是重合的。
  安全区域是指在一段代码片段之中，引用关系不会发生变化。在这个区域中的任意地方 开始GC都是安全的。在线程执行到Safe Region中的代码时，首先标识自己已经进入了Safe Region，那样，当 在这段时间里JVM要发起GC时，就不用管标识自己为Safe Region状态的线程了。在线程要离 开Safe Region时，它要检查系统是否已经完成了根节点枚举（或者是整个GC过程），如果完 成了，那线程就继续执行，否则它就必须等待直到收到可以安全离开Safe Region的信号为 止

垃圾收集器

直到现在为止还没有最好的收集器 出现，更加没有万能的收集器，所以我们选择的只是对具体应用最合适的收集器。

Serial收集器

这个收集器是一个单线程的收集器，但它 的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作， 更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。

对于限定单个 CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最 高的单线程收集效率。Serial收集器对于运行在Client模式下的虚拟机来说是一个很好的选择。（每次只停顿毫秒级所以可以接受）

ParNew收集器

ParNew收集器其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之 外，其余行为包括Serial收集器可用的所有控制参数。

ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果，甚至由于存在 线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地保 证可以超越Serial收集器。

Parallel Scavenge 收集器

Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行 的多线程收集器。Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点 是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到 一个可控制的吞吐量（Throughput）。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总 消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚 拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。
停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高 吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不 需要太多交互的任务。

Serial Old收集器

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

CMS收集器

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

• 初始标记（CMS initial mark） “Stop The World”：初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快。
• 并发标记（CMS concurrent mark）：
• 重新标记（CMS remark）“Stop The World”：为了修正并发标记期间因用户程序继续运作而导致标记产生变 动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些。
• 并发清除（CMS concurrent sweep）
  由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起 工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
  
  CMS收集器对CPU资源非常敏感。其实，面向并发设计的程序都对CPU资源比较敏感。
  CMS收集器对CPU资源非常敏感。其实，面向并发设计的程序都对CPU资源比较敏感。
  也是由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留有足够的内存空间 给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进 行收集，需要预留一部分空间提供并发收集时的程序运作使用。

G1收集器（后续再补充吧）

内存分配与回收策略

对象优先在Eden分配

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

• 新生代GC（Minor GC）：指发生在新生代的垃圾收集动作，因为Java对象大多都具备朝 生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。
• 老年代GC（Major GC/Full GC）：指发生在老年代的GC，出现了Major GC，经常会伴 随至少一次的Minor GC。Major GC的速度一般会比Minor GC慢10倍以上。

大对象直接进入老年代

所谓的大对象是指，需要大量连续内存空间的Java对象，最典型的大对象就是那种很长 的字符串以及数组。这样做的目的是避免在Eden区及两个Survivor区之间发生大量的内存复制。

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

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

动态对象年龄判定

虚拟机并不是永远地要求对象的年龄必须达到 了MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总 和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。

空间分配担保

在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有 对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。如果不成立，则虚拟机 会查看HandlePromotionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代 最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行 一次Minor GC，尽管这次Minor GC是有风险的；如果小于，或者HandlePromotionFailure设置 不允许冒险，那这时也要改为进行一次Full GC。
下面解释一下“冒险”是冒了什么风险，前面提到过，新生代使用复制收集算法，但为了 内存利用率，只使用其中一个Survivor空间来作为轮换备份，因此当出现大量对象在Minor GC后仍然存活的情况（最极端的情况就是内存回收后新生代中所有对象都存活），就需要 老年代进行分配担保，把Survivor无法容纳的对象直接进入老年代。