《深入理解Java虚拟机》读书笔记3

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

3.1

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

2. 程序计数器、虚拟机栈、本地方法栈三个区域 随线程而生，随线程而灭 ；栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作。这几个区域的内存分配和回收都具备稳定性，无需过多考虑回收问题，因为方法结束或线程结束时，内存自然就跟着回收了。

3. 垃圾收集器所关注的是J ava堆和方法区的内存回收 ，这部分内存的分配和回收是动态的。

 

3.2

1、垃圾收集器在对堆进行回收前，首要事件是判断对象是否已经“死去”（即不可能再被任何途径使用的对象）。

判断方法：

引用技术算法 ——（ 给对象添加一个引用计数器，每当有一个地方引用它，计数器就+1,；当引用失效时，计数器就-1；任何时刻计数器都为0的对象就是不能再被使用的。 ）不被Java所选择使用的主要原因：很难解决对象之间的 相互循环引用问题 。

例子： 举个简单的例子：对象A和B分别有字段b、a，令A.b=B和B.a=A，除此之外这2个对象再无任何引用，那实际上这2个对象已经不可能再被访问，但是引用计数算法却无法回收他们。 

根搜索算法 (GC Roots Tracing)——Java、C#、古老的Lisp都选择使用根搜索算法判定对象是否存活。

1) 算法基本思路：通过一系列名为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称为引用链，当一个对象到GC Roots无任何引用链（不可达）时，则证明此对象是不可用的，即为可回收对象。

2) Java中，可作为GC Roots对象的包括：

a. 虚拟机栈（栈帧中的本地变量表）中的引用的对象

b. 方法区中的类静态属性引用的对象

c. 方法区中常量引用对象

d. 本地方法栈JNI（即Native方法）的引用对象

2、再谈引用

1) 判断对象是否存活都与“引用”有关。

2) 希望可以描述这样一类对象：若内存空间还足够时，则保留在内存之中；若内存在进行垃圾收集后还是非常紧张，则可以抛弃这些对象。

3)  引用可分为（强度依次减弱） ：

①　强引用Strong Reference——程序代码中普遍存在，类似“Object obj = new Object()”。

②　软引用Soft Reference——描述还有用但非必须的对象，被软引用关联的对象，在系统将要发生溢出异常之前，会被列进回收范围之内并进行第二次回收，若该次回收内存依旧不足，才会抛出内存溢出异常。 SoftReference类 来实现软引用。

③　弱引用Weak Reference——描述非必须引用，被弱引用关联的对象只能生存到 下一次垃圾收集发生之前 。

④　虚引用Phantom Reference——也称幽灵引用或幻影引用；设置虚引用关联的目的：希望该对象被回收时收到一个 系统通知 。PhantomReference类来实现虚引用。

 

3、 根搜索算法 中的不可达对象并非是“非死不可”的，处于“缓刑”阶段，真正宣告一个对象死亡，至少经历 两次标记 过程：

1) 进行根搜索后未发现与GC Roots相连接的引用链，则被第一次标记并进行筛选， 筛选条件：此对象是否有必要执行finalize()方法

（判定为没必要：该对象没有覆盖finalize方法，或finalize()方法已被虚拟机调用过）

（若有必要，则该对象被置在F-Queue队列中，并在稍后由一条虚拟机自动建立的、低优先级的Finalizer线程去执行。）

2) Finalize()方法是对象逃脱死亡的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模标记，若自救，则被移除“即将回收”的集合，若没有，则离死不远了。

3) 注意：finaliz()方法代价昂贵、不确定性大

 

4、回收方法区（永久代）

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

2) 判定一个类是“无用的类”必须同时满足以下三个条件：

①　该类所有的实例都已被收回，也就是java堆中不存在该类的实例；

②　加载该类的ClassLoader已经被收回；

③　该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

3) 虚拟机可以对满足以上三个条件的类进行回收，但和对象不一样， 不使用了就必然回收 ；是否对此类进行回收，虚拟机提供了-Xnoclassgc参数进行控制。

 

3.3垃圾收集算法

1. 标记-清除算法 ：标记所有需要回收的对象>统一清除

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

2. 复制算法 ：为解决效率问题而提出，实现简单、运行高效。

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

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

现在的商业虚拟机都采用这种方法 回收新生代 。

复制收集算法在对象存活率较高是就要执行多次复制操作，降低效率。

3. 标记-整理算法 ：根据老年代特点提出的算法，与“标记-清除”算法一样，但后续步骤不是直接清除可回收对象，而是让所有存活对象都向一端移动，然后 清除掉端边界以外的内存。

4. 分代收集算法 ： 当前商业虚拟机的垃圾收集都采用“分代收集”算法， 根据各个对象的存活周期不同 将内存划分为几块 ，一般是把java堆分成新生代和老年代再 根据各个年代的特点采用最适当的收集算法 。

a) 新生代：大批对象死去，少量存活——复制算法

b) 老年代：对象存活率高、没有额外空间对它进行分配担保——“标记-清理”或者“标记-整理”

 

3.4垃圾收集器（基于SunHotSpot虚拟机1.6版Update22进行讨论）

 

1. Serial收集器（ 单线程 ）

1) 在进行垃圾收集时，会 暂停其他所有的工作线程 直到它收集结束“Stop the world！”；这项工作实际上是由虚拟机在后台自动发起自动完成的。

2) 目前为止，它依然是虚拟机运行在Client模式下的 默认新生代收集器 。

3) 优于其它收集器的地方：简单而高效（与其他收集器的单线程比）

 

2. ParNew收集器

1) 是Serial收集器的 多线程 版本

2) 它是许多运行在Server模式下的虚拟机首选的 新生代收集器 ，其中有一个与性能无关但很重要的原因：除了Serial收集器外，只有它能和CMS收集器配合工作。

3) 它 默认开启的收集线程数与CPU的数量相同 ；在CPU非常多的情况下，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。

3. Parallel Scavenge收集器（也称“吞吐量优先”收集器）

1) 也是一个新生代收集器，使用复制算法，并行的 多线程 收集器。

2) 特点：其关注点与其他收集器不一样，CMS等收集器的关注点尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge的目的是 达到一个可控制的吞吐量 。

3) 停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提高用户的体验；而高吞吐量则可以最高效率地利用CPU时间，尽快地完成程序的运算任务，主要适合在 后台运算而不需要太多交互的任务 。

4) 两个用于精确控制吞吐量的参数：

-XX:MaxGCPauseMillis参数：控制最大垃圾收集停顿时间（大于0的毫秒数）

-XX:GCTimeRatio参数：直接设置吞吐量大小（大于0小于100的整数）

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

补充：

开关参数：-XX:+UseAdptiveSizePolicy；这个参数打开后不需要手工指定新生代的大小等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整参数以提供最合适的停顿时间或最大吞吐量，称为GC自适应的调节策略。

 

4. Serial Old收集器： 单线程， 使用“标记-整理”算法

1) 主要意义：被Client模式下的虚拟机使用

2) Server模式下的两大用途：在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用；作为CMS收集器的后背预案，在并发收集器发生Concurrent Mode Failure时使用。

 

5. Parallel Old收集器：多线程，“标记-整理”

1) 直到它的出现，“吞吐量优先”收集器终于有了比较名副其实的应用组合。

2) 在注重吞吐量及CPU资源敏感场合，都可以优先考虑Parallel Old和Parallel Scavenge收集器。

 

6. CMS收集器（也称“并发低停顿收集器”）：“标记-清除”

是一种以获取最短回收停顿时间为目的的收集器。

步骤： 初始标记 》并发标记》 重新标记 》并发清除（3次标记，1次清除）

注意： 初始、重新 标记仍旧需要“Stop the world”

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

三个显著缺点：

对CPU资源非常敏感。（CMS默认启动的回收线程数是（CPU数量+3）/4，当CPU数量不足4个时，可能导致用户程序的执行速度忽然降低了50%，为解决该问题，虚拟机提供了一种“增量式并发收集器i-CMS”,但不再提倡用户使用）

无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。（CMS并发清理阶段用户线程还在运行着会有新的垃圾不断产生，这一部分垃圾出现在标记之后，CMS在本次无法集中处理掉他们，只好留待下一次GC时再将其清除掉——浮动垃圾）

收集结束时会产生大量空间碎片，无法找到足够大的连续空间时，不得不提前触发一次Full GC。（为解决此问题，CMS提供了一个开关参数：-XX:+UseCMSCompactAtFullCollection，用于在“享受”完Full GC服务之后额外免费附送一个碎片整理过程，内存整理的过程是无法并发的。）

 

7. G1（Garbage First）收集器

1) 相比较CMS收集器的两个改进：

①　它基于“标记-整理”算法，不会产生空间碎片；

②　它可以非常精确的控制停顿，即能让使用者明确指定在一个长度为M毫秒的时间片段捏，消耗在垃圾收集上的时间不得超过N毫秒。

2) G1收集器可以实现在基本不牺牲吞吐量的前提下完成低停顿的内存回收，这是由于它能够极力避免全区域的垃圾收集。G1将整个Java堆划分为多个大小固定的独立区域，在后台维护一个优先劣别，根据允许的收集时间，优先回收垃圾最多的区域。

注意并发（Concurrent）和并行（Parallel）的区别：

     并发 是指用户线程与GC线程同时执行（不一定是并行，可能交替，但总体上是在同时执行的），不需要停顿用户线程（其实在CMS中用户线程还是需要停顿的，只是非常短，GC线程在另一个CPU上执行）；

     并行 收集是指多个GC线程并行工作，但此时用户线程是暂停的；

所以，Serial和Parallel收集器都是并行的，而CMS收集器是并发的.

3.5 内存分配和回收策略

1. 对象优先在新生代Eden分配 （当Eden区没有足够的空间进行分配时，虚拟机将发生一次Minor GC）

2. 大对象直接进入老年代

1) 大对象是指：需要大量连续内存空间的Java对象（ 最典型的是很长的字符串及数组 ）

2) 虚拟机提供参数：-XX:PretensureSizeThreshold，令大于这个设置值的对象直接在老年代中分配。（该参数只对Serial和ParNew收集器有效）

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

1) 对象年龄计数器

2) 若对象在Eden出生并经过一次Minor GC后仍存活，并且被Survivor容纳的话，将被移动到Survivor空间中，并将对象年龄设为1。

3) 对象在Survivor区中每熬过一次Minor GC，年龄就增加1岁，默认增加到15岁（ 年龄阈值 ：通过参数-XX:MaxTenuringThreshold设置）的时候，晋升到老年代。

4. 动态对象年龄判断

为更好地适应不同程度的内存状况，若在Survivor空间中相同年龄所有对象的总和大于Survior空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无需等到年龄阈值。

5. 空间分配担保

在发生Minor GC时，虚拟机会检测之前每次晋升到老年代的平均大小是否大于老年代的剩余空间大小，若大于，则改为直接进行一次Full GC。若小于，则查看HandlePromotionFailure设置是否允许担保失败，若允许，只会进行Minor GC，若不允许，则也要修改为Full GC.

 

Minor GC 和 Full GC有什么区别？

Minor GC ：新生代 GC，指发生在新生代的垃圾收集动作，因为 Java 对象大多死亡频繁，所以 Minor GC 非常频繁，一般回收速度较快。 

Full GC ：老年代 GC，也叫 Major GC，速度一般比 Minor GC 慢 10 倍以上。