深入理解JAVA虚拟机（垃圾收集器与内存分配）-读书笔记

3.1 概述

• 哪些内存需要回收

• 什么时候回收

• 如何回收

• 程序计数器，虚拟机栈，本地方法栈随着线程而生而灭，栈中栈帧随着方法进入和退出而进行出栈和进栈，这几个地方的内存分配和回收具有确定性，，java堆和方法区不一样，只有程序运行时才知道创建哪些对象，内存分配和回收都是动态的；

3.2 对象已死吗

• 怎样确定？

3.2.1 引用计数法

• 给对象一个引用计数器，有地方引用就加1，引用失效就减1，为0时就不会再使用；

• 弊端:两个对象相互引用，会导致计数器永远不会为0

3.2.2 可达性分析算法

• GC Roots的对象作为起始点，向下搜索，搜索走过的路径叫做引用链，当一个对象到GC Roots没有任何引用链则此对象不可用；他们到GC Roots是不可达的，会被判定为可回收对象；

• GC Roots根包含虚拟机栈（栈帧中局部变量表）引用的对象，方法区中静态属性引用的对象，方法区中常量引用的对象，本地方法栈中引用的对象；

3.2.3 再谈引用

• 强引用：垃圾收集器永远不会回收，最常见的引用，Object obj = new Object();

• 软引用:有用但不是必须的对象，当要发生内存溢出时，会对这些对象进行二次回收，内存还不够才发生内存溢出；SoftReference

• 弱引用：非必需的对象，只能生存在下一次垃圾回收之前，垃圾回收时不管是否内存足够，都会进行回收；WeekReference

• 虚引用:又叫幽灵引用或者幻影引用，无法根据引用获取到对象实例，唯一作用在垃圾回收时收到一个系统通知；PhantomReference

3.2.4 生存还是死亡

• 通过可达性分析算法确定后不可达的对象，也不一定立马死亡，需要进行2次标记，当对象没有与GC Roots存在引用链时，则会进行第一次标记和第一次筛选，筛选的条件是是否有必要执行finalize()方法，当对象没有覆盖finalize()方法和虚拟机已经执行过此方法，则都认为没必要再执行；

• 若对象被判定为有必要执行finalize()方法时，则会加入一个F-queue队列中，并启动一个低优先级的定时任务去执行队列中的任务，在这里会进行第二次规模的标记，若在执行finalize()方法时，对象重新与GC Roots存在引用链，则移除即将回收的集合；注意⚠️不建议在finalize()中做一些操作；

3.2.5 回收方法区

• 包含两部分：废弃常量和无用的类

• 废弃常量：没有任何地方引用到这个常量；

• 无用的类：类的所有实例都被回收，加载该类的classLoader被回收，该类对应的java.lang.Class对象没有任何地方引用，无法在任何地方通过反射访问到该类的方法；

• 虚拟机可以对满足以上条件的无用类进行垃圾回收，但是不是必须回收，可以通过一些参数进行配置；

3.3 垃圾收集算法

3.3.1 标记-清除算法

• 分为标记和清除两步骤，通过对象标记（可达性分析算法）将回收的对象进行标记，再进行清除；

• 弊端：1.标记和清除两个步骤效率都不高；2会产生大量的空间碎片，导致再有大对象需要存放时，会再一次触发垃圾回收；

3.3.2 复制算法

• 将内存划分为容量相等的两块，每次只使用一块，当这一块内存用完后，就将还活着的对象复制到另一块内存中，当前这块内存全部进行清空；

• 优点：解决了效率问题和内存不连续的问题；

• 缺点：内存利用率不高，每次只用一半；

• 目前的商业虚拟机都使用复制算法来回收新生代，研究表明新生代的虚拟机98%对象都是朝生夕死，所以新生代包含一块Eden和两小块S urvivor，Eden：Survivor= 8:1,每次只用Eden和其中一块Survivor，垃圾回收将Eden和Survivor剩余存活的对象放到另一个Survivor中，所以利用率有90%，只有10%空间浪费，但是也无法保证每次垃圾回收都剩余10%以下，当超过另一个Survivor空间时，需要分配担保机制直接进入老年代；

3.3.3 标记-整理算法

• 复制算法在对象存活率高的地方需要多多复制，效率低，而且极端情况下100%对象存活，需要更高的分配担保的空间，所以在老年代-采用标记-整理算法，也是先进行标记，后将存活的对象向一端挪动，清除端界之外的对象；

3.3.4 分代收集算法

• 新生代使用复制算法；老年代使用标记-清除算法或者标记-整理算法；

3.4 HotSpot的算法实现

3.4.1 枚举根节点

• 在实际项目中GCRoots根有很多，逐个检查引用很消耗时间，而且这项分析检查要在一致性的情况下进行（停止所有线程），所以GC要stop the world的原因，HotSpot使用一组OopMap的结构，在类加载和编译时，在特定的位置，记录下信息，所有引用的位置；

3.4.2 安全点

• 在特定的位置记录下信息，这些位置称为安全点，一般以是否具有让程序长时间执行的特征为标准选定；

• 如何让线程跑到最近的安全点停顿下来？

• 抢断式中断：GC发生时，让所有线程全部中断，没有跑到安全点的恢复线程，跑到安全点再中断，一般不使用这个；

• 主动式中断：GC需要中断线程时，不进行线程操作，设置一个标志，各个线程轮训中断标志为真则挂起线程；

3.4.3 安全区域

• 当线程处于睡眠状态，未分配CPU,无法去轮训标志位，所以无法走到安全点，所以需要安全区域；

• 是指一段代码片段之中，引用关系不会发生变化，在这个区域任意位置开始GC都是安全的，当线程执行到安全区域中的代码时，要先进行标识，当这段时间要进行GC,则不会关心标识过安全区域状态的线程了，当线程要离开时，要查看GC是否回收完成，GC完成后才可以离开；

3.5 垃圾收集器

• 收集算法是方法论，垃圾收集器则是实现；

3.5.1 Serial 收集器

• 单线程收集器，在它进行垃圾回收时，需要停止其他工作线程；默认的新生代收集器，简单而高效，没有线程交互的开销；收集几十兆，一两百兆的新生代，停顿几十毫秒最多一百多毫秒以内；

3.5.2 ParNew 收集器

• parNew是serial的多线程版本（复制算法），目前只用parNew和Serial作为新生代垃圾收集器，与CMS作为老年代收集器合作使用；

• 并行：多条垃圾收集线程并行工作，用户线程仍旧是等待状态；

• 并发：用户和垃圾收集线程同时执行（但不一定是并行，可能交替执行），用户线程继续执行，垃圾收集线程在另一个CPU执行；

3.5.3 Parallel Scavenge 收集器

• 新生代收集器也是复制算法，并行的多线程收集器；特点：主要关注于吞吐量（运行用户代码时间/cpu运行用户代码时间+垃圾回收时间）；CMS收集器则关注于停顿时间，停顿时间越短，越适合用于用户交互，高吞吐量则更高效利用CPU,适合后台运算；

• 可以自己设置吞吐量大小-XX:GCTimeRatio，停顿时间-XX:MaxGCPauseMillis,停顿时间也不是设置越小越好，是牺牲吞吐量和新生代空间换的；当-XX:UseAdaptiveSizePolicy参数打开后，就不需要手动执行新生代大小，eden与SurvivorRatio比例等细节参数，虚拟机会动态调整，这种调节方式叫GC自适应调节策略

3.5.4 Serial old 收集器

• 老年代使用的收集器，单线程的标记-整理算法，垃圾收集线程工作时也会停止其他工作线程；可与parallel 合作使用；

3.5.5 Parallel Scavenge old 收集器

• 老年代使用的收集器，多线程的标记整理算法，由于之前parallel只能与Serial old一起使用，老年代收集只能单线程，所以吞吐量并没有真正表现出来，所以出现Parallel old，Parallel old + Parallel，在注重吞吐量和CPU资源敏感的场合推荐使用；

3.5.6 CMS收集器

• CMS是以获取最低停顿时间为目标的收集器，标记-清除算法，采用四个步骤：

• 初始标记：停止用户线程，标记一下GCRoot关联的对象，比较快

• 并发标记：不停止用户线程，并发标记，时间长一点

• 重新标记：停止用户线程，重新标记，时间比初始标记长，比并发标记短

• 并发清除：不停止用户线程，清除被标记的对象

• 三个缺点：

• 1.对CPU资源很敏感；并发虽然不会导致用户线程停顿，但是会导致程序变慢，吞吐量降低，默认启动的回收线程是（CPU数量+3）/4，当cpu四个以上，垃圾回收线程会占用25%的CPU资源，若不足4个，影响更大；

• 2.无法处理浮动垃圾，导致下一次full GC,并发清理时存在新的垃圾的产生，无法当次处理他们，只能等下一次垃圾回收，且CMS收集器不能等到老年代填满时，再进行垃圾回收，因为要给并发清理时运行着的用户线程流出内存空间，jdk1.5是68%就激活垃圾回收，jdk1.6是92%，要是CMS预留的空间不够，则虚拟机启动备案，使用Serial old进行垃圾收集，会造成更长时间的停顿；

• 3.使用标记-清除算法，产生大量垃圾碎片；没有存够空间存储大对象，只能提前出发full GC，为解决这个问题，CMS给了个参数配置，来控制每次full GC要不要碎片整理（不能并发，停顿时间会变长），默认是0，每次都整理；

3.5.7 G1收集器

• 优点：

• 并行与并发：利用多CPU和多核更缩短停顿时间，其他收集器无法并发执行的，G1可以；

• 分代收集：依旧保留分代概念，不需要与其他收集器配合，独立管理；

• 空间整合：整体采用标记-整理算法，局部（Region）采用复制算法，不会产生大碎片；

• 可预测停顿：使用者可以设定停顿时间；

• G1原理

• G1将整个java堆划分成多个Region小块，依旧保留着新生代老年代的概念，但是不是物理隔离，而都是一部分Region不连续的集合；

• G1之所以可以可预测停顿，因为有计划的避免全区域垃圾回收，G1知道各个region里面垃圾堆积价值大小，后台维护优先列表，每次根据允许收集时间，回收最大价值的region；

• 一个region中的对象如何知道有哪些其他的引用呢？还需要扫描其他全部的region? 不，G1维护了每个region都有一个Remembered Set来避免，引用信息存储在set中；

• G1运行步骤：

• 初始标记：很快，标记一下GCRoot直接关联的对象，并修改TAMS的值，让下一阶段运行的用户线程在正确的region创建新对象，此阶段停顿用户线程；

• 并发标记：对堆中对象进行可达性分析，找出存活对象，与用户线程并发执行；

• 最终标记：将并发标记时的用户线程继续运行导致标记变化的进行记录，存到Remembered Set log中，再合到Remembered Set中，需停顿用户线程，但是可并行执行回收线程；

• 筛选回收：对region的回收成本和价值进行排序，根据用户填写的预测停顿时间进行回收，停顿用户线程（其实也可以并发执行，但是只回收部分region比较快，且停顿用户线程提高回收效率）

• 如果你的应用追求低停顿，G1是个好选择，如果追求高吞吐，G1并不会带来什么帮助；

3.6 内存分配与回收策略

3.6.1 对象优先在Eden分配

• 新生代空间不够会进行Minor GC，相对比较快，若新生代没有可以清理的对象，则会直接通过分配担保机制进入老年代；-XX:+PrintGCDetails，收集器日志参数；

3.6.2 大对象直接进入老年代

• 大对象：需要大量连续连续内存空间的JAVA对象（很长的字符串和数组）；程序中应避免短命大对象，容易造成内存还有不少空间就要提前触发垃圾回收来获得足够空间；

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

• 为区分新生代和老年代的对象存放，给每个对象一个年龄计时器，经过一次minor GC年龄+1，年龄到15（默认，由-XX:MaxTenuringThreshold控制）存放老年代；

3.6.4 动态年龄判定

• 如果Servivor空间中相同年龄所有对象大小总和大于Servivor一半，年龄大于等于该年龄的对象直接进入老年代；

3.6.5 空间担保分配

每次minor GC前，会先检查老年代所有连续空间是否大于新生代所有对象总和，若大于则直接minor GC,若小于检查HandlePromotionFailure设置值是否允许担保失败？允许?，则继续检查老年代所有连续空间是否大于历次晋升老年代对象的平均大小。如果大于？，则尝试一次minor GC（尝试失败则进行full GC）,若不允许，则直接进行full GC;

（jdk6不再关注HandlePromotionFailure，只要老年代所有连续空间是否大于新生代所有对象总和/大于历次晋升老年代对象的平均大小就直接minor GC,否则full GC）