哪些内存需要回收
程序计数器、虚拟机栈、本地方法栈三个区域随线程生而生，随线程死而死。而且每一个栈桢中分配多少内存基本上是在类结构确定下来的时候就已知的，当方法结束或线程结束内存自然而然就回收了
而堆和方法区这两个区域则有着很显著的不确定性
- 一个接口的多个实现类需要的内存可能会不一样
- 一个方法所执行的不同条件分支所需要的内存也可能不一样
- 只有处于运行期间，我们才能知道程序究竟会创建哪些对象，创建多少个对象，这部分内存的分配和回收是动态的。垃圾收集器所关注的也正是这部分内存应该如何管理
是否回收方法区
方法区的垃圾一共有 1.废弃的常量 2.不再使用的类型
判断一个常量是否“废弃”相对简单，但要判断一个类型是否属于“不再使用的类”的就比较苛刻了
- 该类的所有实例都已经被回收了（包括派生类、子类）
- 加载该类的类加载已经被回收
- 该类对应的堆空间中的java.lang.Class对象没有在任何地方被引用
在大量使用反射、动态代理、CGLib等字节码框架，动态生成JSP以及OSGi这类频繁自定义类加载器的场景中，通常需要Java虚拟机具备类型卸载的能力，保证不会对方法区造成太大压力
##如何判断对象已经死亡
####引用计数算法
在对象中添加一个引用计数器，每当有一个地方可以引用他时，计数器的值就加一；当引用失效时，计数器值就减一。任何时刻计数器为零的对象就是不可能再被使用的
- 优点：原理简单，判断效率高
- 缺点：无法解决相互循环引用的问题、占用空间
可达性分析算法
可达性分析算法的基本思想为通过一系列称之为“GC Roots”的根对象作为起始节点集，从这些节点开始，根据引用关系向下搜索，搜索过程中所走过的路径称为“引用链”，如果某个对象到GC Roots间没有任何引用链相连，也就是不可达时，此对象是不可能再被使用的。
在Java体系中，固定可作为GC Roots的对象包括以下几种
- 在虚拟机栈（栈桢中的本地变量表）中引用的对象，如正在运行的方法所使用的的参数、局部变量、临时变量等
- 在方法区中类静态属性引用的对象，如Java类的引用类型静态变量
- 在方法区中常量引用的对象，如字符串常量池（String Table）里的引用
- 在本地方法栈中JNI（Native方法）引用的对象
- 在虚拟机内部的引用，如基本类型对应的Class对象，一些常驻的对象、系统类加载器等
- 所有被同步锁（synchronized关键字）持有的对象
除了这些固定的GC Roots集合以外，根据用户所选的垃圾回收器以及当前回收的内存区域不同，还可以有其他对象临时性的加入，共同构成完整的GC Roots集合
四种引用
- 强引用
强引用是最传统的“引用的定义”，是指在程序代码之中普遍存在的引用赋值，用=赋值的都是引用关系，只要有强引用存在，对象就永远不会被回收 - 软引用
只有内存不够才会被回收 - 弱引用
只要有垃圾回收发生，就会被回收 - 虚引用
“幽灵引用”或“幻影引用”，虚引用存在的意义就是当对象被回收时可以收到一个系统通知
什么时候回收
即使在可达性分析算法中判断为不可达的对象，也不是“非死不可”的，这时候他们暂时还处于“缓刑状态”。如果要真正宣布一个对象死亡，最多会经历两次标记过程
- 如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那么它将会被第一次标记
- 随后会进行一次筛选，条件为是否有比较执行finalize()方法。如果对象没有覆盖finalize()方法，或者已经被调用过一次，则认为没必要执行方法，直接回收。如果判定为有必要执行，则会将该对象放置于F-Queue的队列之中，并由虚拟机自动建立的低调度优先级的Finalizer线程去执行他们的finalize()方法。如果对象在finalize()方法中成功拯救自己，重建被引用了，那么就会移除出这个队列，重新存活，在下一次回收时由于已经调用过一次，就会被直接回收
如何回收
分代收集理论
当前的虚拟机大多遵循了“分代收集”理论。建立在两个假说之上
- 弱分代假说：绝大多数对象都是朝生夕死的
- 强分代假说：熬过多次垃圾收集过程的对象就越难易死亡
所以需要将堆空间按照其年龄划分为不同的区域：年轻代，老年代；
其中 Minnor GC 针对年轻代； Major GC 针对老年代， Full GC 全局回收 - 跨代引用假说：跨代引用相对于同代引用来说仅仅占少数（存在相互引用关系的两个对象，是应该倾向于同时生存或者同时消亡的）
依据这条假说，我们就不应该再为了少量的跨代引用去扫描整个老年代，也不必浪费空间专门记录每一个对象是否存在以及存在哪些跨代引用，只需要在新生代上建立一个全局的数据结构（记忆集），这个结构把老年代划分为若干小块，标识出老年代的哪一块内存会存在跨代引用，以后当发生Minor GC的时候，只有包含了跨代引用的小块内存里的对象才会被加入到GC Roots进行扫描。虽然这种方法需要在对象改变引用关系时维护记录数据的正确性，会增加一些运行时的开销，但比起收集时扫描整个老年代来说仍然是划算的（解决了跨代引用的效率问题）
针对不同代的收集
- 部分收集
新生代收集：Minor GC
老年代收集：Major GC
混合收集：Mixed GC - 整堆收集：Full GC
标记-清除算法
算法分为标记和清除两个阶段：首先需要标记出所有需要回收的对象，在标记完成后，统一回收掉所有被标记的对象；或者反过来标记存活的对象，统一回收所有未被标记的对象。需要维护一个空闲链表
优点：基础简单
缺点：1.执行效率不稳定 2.内存的碎片化问题，影响大对象分配
标记-复制算法（适合存活对象少）
复制算法是一种“半区复制”的垃圾收集算法，它将可用内存按照容量划分为大小相等的两块，每次只使用其中的一块。当一块内存用完了，就将存活对象复制到另外一块上面，再将已经使用过的内存空间一次性清理掉。
这种算法适用于需要复制的对象数量很少的情况，也就是复制少量存活的对象，同时不会产生空间碎片的问题，利用指针碰撞法分配内存
年轻代被分为8:1:1。当Survivor空间不足以容纳一次Minor GC之后存活的对象是，就需要依赖其他的内存区域（老年代）进行分配担保策略。
标记-整理算法（适用于老年代）
标记整理算法在标记阶段和标记-清除算法一样，但后续的步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向内存空间的一端移动，然后直接清理掉边界以外的内存。
与非移动式的标记-清除算法不同，标记-整理算法是移动式的。
如果移动存活对象，尤其是在老年代这种每次回收都有大量对象存货区域，移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作，必须暂停用户的应用线程才能进行，这种情况称之为Stop The World。
这时面临一个矛盾：如果移动对象则回收时更复杂，不移动则分配时更复杂。从垃圾收集的角度看不移动更好，但是从整个程序的吞吐量来看，移动对象更划算
HotSpot的算法细节实现
根节点枚举
在可达性分析算法中从GC Roots集合找引用链的过程中，固定可作为GC Roots的节点主要在全局性引用（例如常量或类静态属性）和执行上下文（栈桢中的本地变量表）中。
迄今为止所有的收集器在根节点枚举这一步骤时都是必须暂停用户线程的，所以也会和整理内存碎片一样面临Stop The Word的问题。尽管现在可达性分析算法耗时最长的查找引用链的过程已经可以做到与用户线程一起并发，但根节点枚举还是始终必须在一个能保障一致性的快照中才得以进行。
其实当用户线程停下来后，其实并不需要一个不漏的检查完所有执行上下文和全局的引用位置，虚拟机有办法直接得到哪些地方存放着对象引用。在HotSpot虚拟机中，使用一组OopMap的数据结构来达到这个目的
安全点
在OopMap的协助下，HotSpot虚拟机可以快速的完成GC Roots枚举，但如果为每一条指令都生成对应的OopMap，那么将会消耗大量的额外的空间。
实际上，HotSpot虚拟机没有为每条指令都生成OopMap，而是在“特定的位置”记录了这些信息，这些位置被称为安全点（Safepoint）。有了安全点的设定，也就决定了用户线程在执行时并非在代码指令的任意位置都能停下来开始垃圾收集，而是强制要求必须达到安全点后才能暂停
因此安全点的选定既不能太少以至于让收集器等待的时间过长，也不能太过频繁以至于过分增大运行时的内存符合。安全点的位置选取是以“是否具有让程序长时间执行”为标准进行选定的。“长时间执行”的最明显特征就是指令序列的复用，例如方法调用、循环跳转、异常跳转等都属于指令序列复用，所以会产生安全点
对于安全点，线程停顿下来有两种方案：1.抢先式中断 2.主动式中断
- 抢先式中断：在垃圾收集发生时系统先将所有的线程全部中断，如果有线程不在安全点上，则会恢复这条线程的执行，直到走到安全点上。属于一种被动的终端
- 主动式中断：在垃圾收集器需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志位（红灯）,各个线程执行过程时会不停地主动去轮询这个标志，一旦发现中断标记为真时就自己在最近的安全点上主动中断挂起
安全区域
安全点机制保证了程序执行时，在不太长的时间内就会遇到可进入垃圾收集过程的安全点。但是当程序不执行的时候（如sleep）这时候线程无法响应虚拟机的中断请求，不能再走到安全点去中断挂起自己，这时就出现了安全区域
安全区域是指能够确保在一段代码片段之中，引用关系不会发生变化，因此在这个区域中任意地方开始垃圾收集都是安全的，我们也可以把安全区域看成是被扩展拉伸了的安全点
当用户线程执行到安全区域里面的代码时，首先会标识自己已经进入了安全区域，这样在这段时间内虚拟机要发起垃圾收集时就不必去管这些已经处于安全区域的线程了。
当线程要离开安全区域时，它要检查虚拟机是否已经完成了根节点枚举，如果完成了就当无事发生，继续执行；否则这时他就要在安全点内躲着，直到收到可以离开安全区域的信号为止
记忆集与卡表
为解决跨代引用的问题，垃圾收集器在新生代中建立了名为记忆集（Remembered Set）的数据结构，用以避免将整个老年代都加进GC Roots扫描范围。事实上并不只是新生代、老年代之间才会有跨代引用的问题，所有涉及部分区域收集（Partial GC）行为的垃圾收集器，如G1都会面临相同的问题。
记忆集是一种用于记录从非收集区域指向收集区域的指针集合的抽象数据结构
Class RememberSet {
Object[] set[OBJECT-INTERGENERATIONAL_REFERENCE_SIZE];
}
这种记录全部含有跨代引用对象的实现方案，无论是空间占用还是维护成本都相当高昂。而在垃圾收集的场景中，收集器只需要通过记忆集判断出某一块非收集区域是否存在有指向了收集区域的指针就可以了，而不需要了解这些跨代引用指针的全部细节。那么这记者在实现记忆集的时候，便可以选择更粗犷的记录粒度来节省记忆集的存储和维护成本，下面列举了一些可供选择的记忆精度
- 字长精度：每个记录精确到一个机器字长（32或64位）
- 对象精度：每个记录精确到一个对象，该对象里有字段含有垮代指针
- 卡精度：每个记录精确到一块内存区域，该区域内有对象含有垮代指针
其中第三种“卡精度”所指的是一种称为“卡表（Card Table）”的方式去实现记忆集，这也是目前最常用的一种记忆集的实现形式。
卡表是记忆集的一种具体实现，它定义了记忆集的记录精度、与堆内存的映射关系等。卡页最简单的形式可以只是一个字节数组，如
CARD_TABLE[this address >> 9] = 1// 一个卡页512Byte
CARD_TABLE[this address / 512] = 0或1
字节数组CARD_TABLE的每一个元素都对应着其标识的内存区域中一块特定大小的内存块，这个内存块称为“卡页”，一般来说卡页的大小都是2的N次幂。
一个卡页的内存中通常包含不止一个对象，只要卡页内有一个或多个对象的字段存在着跨代引用，那就将对应卡表的数组元素标识为1，称为这个元素变脏（Dirty），没有则标识为0.在垃圾收集发生时，只要筛选出卡表中变脏的元素，就能轻易得出哪些卡页内存块中包含垮代指针，把他们加入GC Roots中一起扫描
写屏障
现在我们已经通过记忆集来缩短GC Roots扫描范围的问题，但是现在我们仍需解决卡表的维护问题，包括何时变脏、谁来把它们变脏等
- 如果有其他分代区域中的对象引用了本区域对象，那么其对应的卡表元素就变脏，变脏的时间点原则上应该发生在引用类型字段赋值的那一刻。是在机器码层面，把维护卡表的动作放到每一个赋值操作之中
- 在HotSpot虚拟机里是通过写屏障技术来维护卡表状态的。
写屏障可以看做在虚拟机层面对“引用类型字段赋值”这个动作的AOP切面，在引用对象赋值时会产生一个唤醒通知，供程序执行额外的动作，也就是说复制的前后都在写屏障的覆盖范畴内。在赋值之前的部分写屏障叫做写前屏障，在赋值后的则叫做写后屏障
并发的可达性分析
可达性分析算法理论上要求全过程都基于一个能保障一致性的快照中才能够进行分析，这意味着必须全程冻结用户线程的运行。
标记阶段是所有追踪式垃圾收集算法的共同特征，如果这个阶段会随着堆空间的变大而等比例增加停顿时间，其影响就会波及几乎所有的垃圾收集器，所以引入三色标记工具来辅助推导，把遍历对象图的过程遇到的对象按照“是否访问过”标记为以下三种颜色
- 白色：尚未被垃圾收集器访问过
- 黑色：已经被垃圾收集器访问过，而且对象所有的引用也都访问过，如果有新对象指向黑色，黑色不会被重新扫描
- 灰色：对象已经被垃圾收集器访问过，还这个对象上还有至少一个引用没有被扫描过
如果用户线程和垃圾收集器并发工作，可能会出现以下两种后果
- 把原本消亡的对象错误标记为存活 —— 产生逃过本次收集的浮动垃圾
- 把原本存活的对象错误标记为死亡 —— 程序报错
这种将存活对象标记为死亡也称之为“对象消失问题”，需要同时满足以下两点要求
- 1.赋值器插入了一条或多条由黑色对象到白色对象的新引用 —— 需要添加，但不能由本人来做
- 2.赋值器删除了全部从灰色对象到该白色对象的直接或间接引用 —— 其他人也不能帮忙
为了解决并发扫描时的对象消失问题，只需要破坏这两个条件的任意一个即可，因此产生了两种解决方案：增量更新（Incremental Update）和原始快照（Snapshot At The Beginning，SATB）
- 增量更新：破坏第一个条件，在黑色对象插入新的指向白色对象的引用关系时，就将这个引用记录下来，在扫描完成后，重新扫描一次。可以理解为，在黑色对象插入一个白色对象的时候，他就变成了灰色对象。
- 原始快照：破坏第二个条件，当灰色对象要删除指向白色对象的引用关系时，就要将这个要删除的引用记录下来，当并发扫描结束之后，再将这些记录过的引用关系中的灰色对象为根，重新扫描一次。这也可以简化理解为，无论引用关系删除与否，都会按照刚开始扫描那一刻的对象图快照来进行搜索。
