概述
问：垃圾收集器（GC）需要完成的三件事情：
答：1. 哪些内存需要回收？
2. 什么时候回收？
3. 如何回收？
问：为什么我们还要去了解GC和内存分配呢？
答：当需要排查各种内存溢出、内存泄露等问题时，当垃圾收集器成为系统达到更高并发量的瓶颈时，我们就需要对这些“自动化”的技术实施必要的监控和调节；
对象已死吗
在堆里面存放的几乎所有的对象实例，垃圾收集器在对堆进行回收前，第一件事就是确定这些对象中，哪些还“存活”着，哪些已经“死去”;
判断对象是否“存活”的算法：
引用计数算法（主流的虚拟机中没有选用引用计数算法进行内存管理，最主要的原因是它很难解决对象之间相互循环引用的问题）：给对象添加一个引用计数器，每当有一个地方引用它时，计数器就加1；当引用失败时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用。
!!可达性分析算法（主流的商用程序语言的主流实现中）：通过一系列的成为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径成为引用链，每当一个对象到GC Roots没有任何引用链相连时（在图论中，就是从GC Roots到这个对象不可达），则证明此对象不可用。
在Java语言中，可作为GC Roots的对象包括下面几种：
1. 虚拟机栈（栈帧中的本地变量表）中引用的对象；
2. 方法区中**类静态属性引用**的对象；
3. 方法区中**常量引用**的对象；
4. 本地方法栈中**JNI（即一般说的Native方法）引用**的对象；
- 再谈引用：JDK1.2以前，Java中的引用的定义很传统：如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就成这块内存代表着一个引用；在JDK1.2之后，将引用分为：强引用（strong reference）、软引用（Soft reference）、弱引用（Weak reference）、虚引用（Phantom reference）；
- 强引用：指在程序代码中普遍存在的，类似“Object obj = new Object（）”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象；
- 软引用：指那些还有用但并非必须的对象；在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收；
- 弱引用：描述非必须的对象，被弱引用关联的对象智能生存到下一次垃圾收集器发生之前；当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象；
- 虚引用：成为幽灵引用或幻影引用，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例；为一个对象设置虚引用关联的唯一目的就是能在这个对象被垃圾收集器回收时收到一个系统通知；
生存还是死亡：即使在可达性算法中“不可达”的对象，也并非是“非死不可”，它们暂处于“缓刑”状态，要真正宣告一个对象死亡，需要经历两次标记过程：
- 如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize（）方法；
- 如果对象被判定为有必要执行finalize（）方法，那么这个对象将放置在一个叫做F-Queue的队列之中，并在稍后由一个虚拟机自动建立的、低优先级的Finalizer线程去执行它；
- 这里的执行是指虚拟机会触发这个方法，但并不承诺会等待它运行结束，这样做的原因是，如果一个对象在finalize方法中执行缓慢，或者发生了死循环（更极端的情况），将很有可能会导致F-Queue队列中其他对象处于永久等待，甚至导致整个内存回收系统崩溃；
- finalize（）方法时对象逃脱死亡的最后一次机会，稍后GC将对F-Queue队列进行第二次小规模的标记，如果对象要在finalize（）中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可；
- 任何一个对象的finalize（）方法都只会被系统自动调用一次；
回收方法区：在Java虚拟机规范中，可以不要求虚拟机在方法区实现垃圾回收，而且在方法区中实现垃圾回收的“性价比”比较低；
永生代（方法区）的垃圾收集主要回收两部分内容：
- 废弃常量：回收废弃常量与回收Java堆中的对象非常类似，如果没有发生符号引用，并且有必要的话，就会被回收；常量池中的其他类（接口）、方法、字段的符号引用也与此类似；
- 无用的类：一个类需要满足三个条件才能被称为无用的类：
- 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例；
- 加载该类的ClassLoader已经被回收；
- 该类对应的Java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法；
- 虚拟机可以对满足上述三个条件的无用类进行回收，这里说的仅仅是“可以”，而并不是和对象一样，不使用了就必然会回收；
垃圾收集算法
- 标记-清除算法（Mark-Sweep）（最基础的收集算法，适用于老年代）：
- 算法分为标记与清除两个阶段：首先标记所有需要回收的对象，在标记完成后统一回收所有标记的对象；
- 该算法有两个不足之处：
- 效率问题：标记与清除的效率都不高；
- 空间问题：标记清除后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作；
- 复制算法（Copying）（适用于新生代较多的情况，老年代一般不选用这种算法）：
- 它将可用内存按容量分为大小相等的两块，每次只使用其中的一块；当这块内存用完了，就将还存活的对象复制到另外一块上面，然后再把已使用过得内存空间一次清理掉；
- 每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可；但这种算法的代价是将内存缩小为了原来的一半；
- IBM公司研究表明，新生代中的对象98%是“朝生夕死”的，所以不需要按照1:1比例来划分内存空间，而是将内存划分为一块较大的Eden空间和两块较小的Survivor空间，每次只使用Eden和其中一块Survivor；HotSpot虚拟机默认Eden和Survivor的大小比例是8：1；
- 不足之处：在对象存活率较高时，就要进行较多的复制操作，效率就会变低；
- 标记-整理算法（Mark—Compact）（适用于老年代）：
- 标记过程与标记-清除算法过程一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存；
- 分代收集算法（当前商业虚拟机都采用这种垃圾收集算法）：
- 根据对象的存活周期的不同将内存分为几块；一般是把Java堆分为新生代与老年代；
- 在新生代中，每次垃圾收集时发现有大批对象死去，只有少量存活，就选用复制算法；
- 在老年代中，因为对象的存活率比较高、没有额外的空间对它进行分配担保，就必须使用“标记-清除”算法或者“标记-整理”算法来进行垃圾回收；
HotSpot的算法实现
- 枚举根节点（GC Roots）：
- 可以作为GC Roots的节点主要在全局性引用（例如常量或类静态属性）与执行上下文（例如栈帧中的本地变量表）中；
- 可达性分析对执行时间的敏感还体现在GC停顿上，因为这项分析工作必须在一个能确保一致性的快照中进行；这里的“一致性”的意思是指在整个分析期间整个执行系统看起来像冻结在了一个时间点上，不可以出现分析过程中对象引用关系还在不断变化的情况，该点不满足的话分析结果的准确性将无法得到保证；该点是导致GC进行时必须停顿所有Java执行线程的其中一个重要原因，枚举根节点时都必须要停顿；
- 在HotSpot虚拟机中，使用一组称为OopMap的数据结构来使虚拟机知道哪些对象存放着对象引用；在类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用；
- 安全点（Safepoint）：
- 在OopMap的协助下，HotSpot可以快速且准地完成GC Roots枚举；
- HotSpot**没有为每条指令都生成OopMap**，只是在“特定位置”记录了这些信息，这些位置称为安全点（Safepoint），即程序执行时并非在所有地方都能停顿下来开始GC，只有达到安全点时才能暂停；Safepoint的选定不能太少以致于让GC等待时间太长，也不能过于频繁以致于过分增大运行时的负荷；
- 安全点的选定基本上是以程序“是否具有让程序长时间执行的特征”为标准进行选定的————因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度太长这个原因而过长时间运行，“长时间执行”的最明显特征就是指令序列复用（例如方法调用、循环跳转、异常跳转等），所以具有这些功能才能产生Safepoint；
- 对于Safepoint，如何让所有线程在都“跑”到最近的安全点上停顿下来；
- 两种方法：
- 抢先式中断（现在几乎没有虚拟机采用这种中断方式来暂停线程）：不需要线程的执行代码去配合，在GC发生时，首先把所有线程全部中断，如果发现线程中断的地方不在安全点上，就恢复线程，让它“跑”到安全点上；
- 主动式中断：当GC需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起，轮询标志的地方和安全点时重合的，另外在加上创建对象需要分配内存的地方；
- 两种方法：
- 安全区域（Safe Region）：在安全区域任意地方开始GC都是安全的；内存回收如何进行是由虚拟机所采用的GC收集器来决定的，而通常虚拟机往往不止有一种GC收集器；
垃圾收集器
- Serial收集器：
- 用于新生代收集；
- 是一个单线程的收集器；它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作；
- 在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束；
- 用户线程的停顿时间在不断缩短，但是仍然没有办法完全消除；
- 依然是虚拟机运行在Client模式下的默认新生代收集器；
- 优于其他收集器的地方：简单而高效（与其他收集器的单线程相比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率；
- ParNew收集器：
- 其实就是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集外，其余行为与Serial收集器的完全一样（所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等）；
- 运行在Server模式下的虚拟机中首选的新生代收集器；
- 除了Serial收集器外，目前只有它能与CMS收集器配合一起工作；
- 在单CPU的环境中绝对不会比Serial收集器有更好的效果，由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分百超越Serial收集器；
- 默认开启的收集线程数与CPU的数量一样多；
并行与并发 的概念：
- 并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程依然处于等待状态；
- 并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行执行，可能交替执行），用户线程在继续运行，而垃圾收集线程在另一个CPU上运行；
Parallel Scavenge 收集器（无法与CMS收集器配合工作）（吞吐量）：
- 是一个新生代收集器，也是使用复制算法的收集器，又是并行的多线程收集器；
- 它的特点是它的关注点与其他收集器不同，它的目标是达到一个可控制的吞吐量；所谓吞吐量就是CPU用于用户运行代码的时间与CPU总消耗的时间的比值（即吞吐量=运行用户代码的时间/（运行代码的时间+垃圾收集的时间））；高吞吐量可以高效地利用CPU的时间尽快完成任务，主要适应于后台运算且不需要太多交互的任务；
- GC的停顿时间缩短是以牺牲吞吐量和新生代空间来换取的；停顿时间在下降，吞吐量也在下降；
- 由于与吞吐量有关系，因此Parallel Scavenge也被称为“吞吐量优先”收集器；
- 虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大吞吐量，这种调节方式称为GC自适应的调节策略；
- Serial Old收集器：
- 是Serial收集器的老年代版本，是一个单线程收集器，使用“标记-整理”算法；
- 主要意义在于给Client模式下的虚拟机使用；
- 如果在Server模式下，它主要有两大用途：
- 在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用；
- 作为CMS收集器的后备预案；
- Parallel Old收集器（吞吐量）：
- 是Parallel Scavenge收集器的老年代版本，使用多线程与“标记-整理”算法；
- 在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器；
- CMS收集器（Concurrent Mark Sweep）（低停顿）：
- 是一种以获取最短回收停顿时间为目标的收集器；
- 基于“标记-清除”算法的收集器；在运作过程中，有四个步骤（初始标记与重新标记仍然需要“stop the world”）：
- 初始标记（CMS initial mark）：仅仅只是标记一下GC Roots能直接关联到的对象，速度很快；
- 并发标记（CMS concurrent mark）：进行GC Roots Tracing过程；
- 重新标记（CMS remark）：为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这一阶段的停顿时间比初始标记要长一点，但远比并发标记时间更短；
- 并发清除（CMS concurrent sweep）；
- 由于整个耗时最长的并发标记与并发清除过程收集器线程是与用户线程一起工作的，所以总体上说，CMS收集器的内存回收过程是与用户线程一起并发执行的；
- 优点：并发收集，低停顿；又被称为“并发低停顿收集器”；
- 缺点：
- CMS收集器对CPU资源特别敏感：CMS默认启动的回收线程数是（CPU数量+3）/4；（后来为了解决CPU资源的问题，提供了一种“增量式并发收集器”的CMS收集器的变种，就是在并发标记、并发清除的时候让GC线程与用户线程并发执行，使GC线程的独占资源时间减少，对整个垃圾收集的过程会更长，但对用户程序的影响会显得少一些，但后来发现该收集器效果一般，在目前版本中，不在推荐使用了）；
- CMS收集器无法处理浮动垃圾：
- 浮动垃圾：由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS**无法在当次收集中处理它们，只好等待下一次GC时再清理；这部分垃圾成为浮动垃圾**；
- CMS收集器是基于“标记-清理”算法的收集器：这意味着在收集完成之后，会有大量空间碎片产生，空间碎片过多时，将会给大对象分配带来很大麻烦，往往会在老年代有很多空间剩余，但是无法找到足够大的连续空间来分配当前的对象，不得不触发一次Full GC；
- G1收集器（低停顿）：
- 是一款面向服务端应用的垃圾收集器；
- G1具备以下特点：
- 并行与并发：充分利用CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop-The-World的停顿时间，部分收集器原本需要停顿Java线程执行的GC动作，而G1收集器仍然可以通过并发的方式让Java程序继续执行；
- 分代收集：G1收集器可以独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果；
- 空间整合：整体上看是基于“标记-整理”算法实现的收集器，从局部上看（两个Region之间）是基于“复制”算法实现的；但无论如何，这两种算法都意味着G1收集器在运作期间不会产生大量的内存空间碎片，收集后能提供规整的可用内存；
- 可预测的停顿：G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在M毫秒的时间段内，消耗在垃圾收集上的时间不得超过N毫秒；
- G1收集器将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留着新生代与老年代的概念，但新生代和老年代不再是物理隔离了，它们都是Region（不需要连续）的集合；
- G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集；G1**跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region**（这也就是Garbage-First名称的由来）；
- 在G1收集器中，Region之间的对象引用以及其他收集器的新生代与老年代之间的对象引用，虚拟机都是使用Remembered Set来避免全堆扫描的；
- 不计算维护Remembered Set的操作，G1收集器的运作分为四个步骤：
- 初始标记（Initial Marking）：仅仅只是标记一下GC Roots**直接关联到的对象，并且修改TAMS**（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这阶段需要停顿线程，但耗时很短；
- 并发标记（Concurrent Marking）：从GC Roots开始对堆中的对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户线程并发执行；
- 最终标记（Final Marking）：为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分的标记记录，虚拟机将这段时间对象变化记录在线程的Remembered Set Logs中，最终标记需要把Remembered Set Logs整合到Remembered Set中，这阶段需要停顿线程，但是可并行执行；
- 筛选回收（Live Data Counting and Evacuation）：首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来指定回收计划，停顿用户线程将大幅提高收集效率；（但这阶段是可以做到与用户线程并发执行的，时间可由用户控制的）；
理解GC日志
- 每个收集器的日志格式都不一样，每一种收集器的日志格式都是由它们自身的实现所决定的；
- GC日志最前面的数字代表了GC发生的时间，这个数字的含义是从Java虚拟机启动以来经过的秒数；
- GC日志的开头的[GC和[Full GC说明了这次垃圾收集的停顿类型，如果有“Full”说明这次GC是发生了Stop-The-World的；如果调用了System.gc()方法所触发的收集，那么在这里讲显示“[Full GC(System)”；
- GC日志的[DefNew、[Tenured、[Perm表示GC发生的区域，这里显示的区域名称与GC收集器是密切相关的；例如Serial收集器中的新生代名为“Default New Generation”，所以显示“[DefNew”；
- 方括号内部的“3224K->152K(3712K)”的含义是“GC前内存区域已使用的容量->GC后内存区域已使用的容量（该内存区域的总容量）”;
- 方括号外部的“3324K->152K(11904K)”表示“GC前Java堆已使用的容量->GC后Java堆已使用的容量（Java堆总容量）”;
- GC日志里面的user、sys、real与Linux的time命令所输出的时间含义一致，分别代表用户态消耗的CPU时间、内核态消耗的CPU时间和操作从开始到结束所经过的墙钟时间（墙钟时间包括各种非运算的等待耗时，而CPU时间不包括这些耗时，但当系统有多个CPU或者多核的话，多线程操作会叠加这些CPU时间）
内存分配与回收策略
- 自动内存管理：给对象分配内存、回收分配给对象的内存；
- 默认环境：Client模式虚拟机，使用Serial/Serial Old收集器下；
对象优先在Eden分配
- 对象在新生代Eden区中分配，当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC；
- Minor GC与Full GC的区别：
- 新生代GC（Minor GC）：发生在新生代的GC，因为Java对象大多数都具备朝生夕死的特性，所以Minor GC**非常频繁，一般回收速度比较快**；
- 老年代GC（Major GC/Full GC）：发生在老年代的GC，出现了Major GC，经常会伴随至少一次Minor GC（但非绝对的，在PS收集器的收集策略里就有直接进行Major GC的策略选择过程）,Major GC的速度一般比Minor GC慢10倍以上；
大对象直接进入老年代
- 所谓的大对象是指需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组；
- 经常出现大对象容易导致内存还有不少内存空间时就提前触发垃圾收集以获取足够的连续空间来“安置”它们；
长期存活的对象将进入老年代
- 虚拟机给每个对象定义了一个对象年龄（Age）计数器；如果对象在Eden出生并经过第一Minor GC后仍然能存活着，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象的年龄设为1；对象在Survivor区中每熬过一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度时（默认为15岁），将会被晋升为老年代中；
动态对象年龄判定
- 如果在Survivor空间中相同年龄所有对象大小的总和*大于Survivor空间的一半，年龄大于或者等于该年龄的对象就可以直接进入老年代*；
空间分配担保
- 在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间，如果这个条件成立，那么Minor GC是安全的；如果这个条件不成立，虚拟机会去查看是否允许担保失败；
- 如果允许担保失败，那么会继续检查老年代最大的可用连续空间是否大于历次晋升到老年代的对象的平均大小，如果大于，将尝试一次Minor GC，但是这次Minor GC是有风险的；如果小于，这时将进行一次Full GC；
- 如果大量对象在Minor GC后仍然存活，就需要老年代进行分配担保，把Survivor无法容纳的对象直接进入老年代中，前提是老年代本身还有容纳这些对象的剩余空间，一共有多少对象会活下来在实际完成内存回收之前是无法知道的，所以只好取每一次晋升到老年代对象容量的平均大小值作为经验值，与老年代剩余空间进行比较，决定是否进行Full GC来让老年代腾出更多的空间；
- JDK1.6Update24之后的规则变为：只要老年代的连续空间大于新生代对象的总大小或者大于历次晋升到老年代的平均大小就会进行Minor GC，否则就进行Full GC；