对象存活判断
- 引用记数算法
- 可达性分析算法
引用计数算法
给对象中添加一个引用计数器，每当一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器为0的对象就是不可能再被使用的。
很难解决对象之间循环引用的问题
可达性分析算法
通过一系列的称为GC ROOTS 的对象作为起点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC ROOTS 没有任何引用链相连时，证明此对象是不可用的
可作为GC ROOTS 的对象
- 虚拟机栈(栈帧中的本地变量表)中引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象
- 本地方法栈中JNI(即一般说的Native方法)引用的对象
JDK1.2之后，将引用分为引用、软引用、弱引用、虚引用
- 强引用：垃圾收集器永远不会回收掉被引用的对象
- 软引用：对于软引用关联的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收，若这次回收过后还是没有足够的内存，才会抛出内存一次异常。使用SoftReference类来实现软引用
- 弱引用也是描述非必须对象，只能存活到下一次垃圾回收之前，使用WeakReference来实现弱引用
- 虚引用：一个对象是否有虚引用完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。唯一目的就是能在这个对象被垃圾收集器回收时收到一个系统通知，使用PhantomReference类来实现
真正判断一个对象死亡，至少需要经历两次标记过程：如果对象在进行可达性分析后发现没有与GC Roots相连的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为没有必要执行。
若有必要执行finalize()方法，这个对象会被放在一个F-Queue对列中，并由另外一个低优先级的Finalizer线程去执行。执行只是只会触发，并不保证会等待其运行结束。若在执行finalize()方法过后，此对象与引用链上的任何一个对象关联起来，它就会被移除“即将回收”的集合；若还是没有关联，他就会被回收了
回收方法区
永久代的垃圾收集主要回收两部分类容：废弃常量和无用的类。回收废弃常量与回收Java堆中的对象非常类似。以常量池中字面量的回收为例，假如一个字符串“abc”已经进入了常量池，但是当前系统没有任何一个String对象是叫做“abc”的，也没有其他地方引用了这个字面量，若此时发生内存回收，这个常量就会被系统清理出常量池。常量池中其他的类、接口、方法、字段的符号引用也与此类似。
判断一个常量是否是废弃常量比较简单，而要判定一个类是否是无用的类的条件相对苛刻：
- 该类所有的实例都已经被回收，也就是java堆中不存在该类的任何实例
- 加载该类的ClassLoader已经被回收
- 该类对应的java.lang.Class对象没有任何地方被引用，无法在任何地方通过反射访问该类的方法。
垃圾收集算法
- 标记-清除算法(先标记、后清楚，时间长，空间碎片)
- 复制算法(将内存分为大小相等的块，每次将存活的对象复制到另外一块上面)，现在商业虚拟机都采用这种收集算法来回收新生代，因为其对象死的快，而且基本上都会死，所以不需要按照1:1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间。每次使用Eden和一块Survivor。HotSpot虚拟机默认Eden和Survivor的大小比例是8:1。
- 标记-整理算法。使所有对象都像一边移动，然后清楚掉边界外的内存，这样清理过后内存就是规整的里
枚举根节点
判断对象是否存活有两种方法，引用计数和可达性分析，一般采用可达性分析。可达性分析对执行时间是非常敏感的，在它分析的过程中，整个系统必须确保像被冻结再某个时间上才行，不能出现分析过程中对象引用关系还在不断变化的情况。所以，GC进行时，必须停顿所有JAVA执行线程。就算是CMS，在枚举根节点的时候也需要停顿
当前主流虚拟机都采用准确式GC,再HotSpot到实现中，是使用一组称为OopMap的数据结构来达到这个目的的，再类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，再JIT编译过程中，也会再特定的位置记录下栈和寄存器中哪些位置是引用。再GC的时候就能知道特定的位置是啥信息了。
HotSpot不会为每一条指令都生成OopMap，只有再特定位置记录。这些位置称为安全点。安全点的选择不能太少以致于让GC等待时间太长，也不能太多，增大运行时符合。安全点的选择是是否具有让程序长时间执行的特征选定的，最明显的特征就是指令序列复用，例如方法调用、循环跳转、异常跳转。
GC的时候需要让所有线程(不包括JNI调用的线程)都跑到最近的安全点上再停顿下来。有两种方式，抢先式中断和主动式中断，抢先式中断不需要线程配合，再GC发生时，首先把所有线程全部中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让它“跑”到安全点上。现在几乎没有虚拟机实现采用抢先式中断来暂停线程从而响应GC事件
而主动式中断的思想是当GC需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起。轮询标志的地方和安全点是重合的，另外再加上创建对象需要分配内存的地方。
使用Safepoint似乎已经完美地解决了如何进入GC的问题，但实际情况却并不一定。Safepoint机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safepoint。但是，程序“不执行”的时候呢？所谓的程序不执行就是没有分配CPU时间，典型的例子就是线程处于Sleep状态或者Blocked状态，这时候线程无法响应JVM的中断请求，“走”到安全的地方去中断挂起，JVM也显然不太可能等待线程重新被分配CPU时间。对于这种情况，就需要安全区域（Safe Region）来解决。
安全区域是指在一段代码片段之中，引用关系不会发生变化。在这个区域中的任意地方开始GC都是安全的。我们也可以把SafeRegion看做是被扩展了的Safepoint。在线程执行到SafeRegion中的代码时，首先标识自己已经进入了SafeRegion，那样，当在这段时间里JVM要发起GC时，就不用管标识自己为SafeRegion状态的线程了。在线程要离开SafeRegion时，它要检查系统是否已经完成了根节点枚举（或者是整个GC过程），如果完成了，那线程就继续执行，否则它就必须等待直到收到可以安全离开Safe Region的信号为止。
垃圾收集算法具体实现-垃圾收集器
两大类：
- Yong GC : Serial、ParNew、Parallel Scavenge
- Old GC : CMS、Serial Old、Parallel Old
- Serial,单线程收集器，只会使用一个CPU或一条收集线程去完成垃圾收集，并且，收集过程中，必须暂停其他工作线程。新生代Serial采用复制算法、Serial Old老年代采用标记-整理算法。client模式下程序的选择
- ParNew,Serial的多线程版本，采用多条线程进行垃圾收集。Server模式下虚拟机的首选新生代收集器
- Parallel Scavenge 收集器的特点是它关注的与其他收集器不同，CMS等收集器关注点是尽可能缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量。吞吐量 = 运行用户代码时间 /(运行用户代码时间 + 垃圾收集时间)。它可配置参数为自适应调节策略
- Serial Old ：1.5版本之前与Parallel Scavenge收集器搭配使用，另一种用途是作为CMS收集器的后备预岸，在并发收集发生Concurrent Mode Failure时使用。
- Parallel Old，使用多线程和标记-整理算法，和Parallel Scavenge配置使用，实现吞吐量优先原则
- CMS，是一种以获取最短回收停顿时间为目标的收集器。
- 初始标记(需要 Stop The Word),仅仅标记GC Root对象能直接关联的对象
- 并发标记
- 重新标记(需要 Stop The Word)
- 并发清除
- 由于耗时最长的并发标记和并发清除可与用户线程一起工作，总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的
- 无法处理浮动垃圾(并发清除过程中产生的垃圾)。可能出现Concurrent Mode Failure失败而导致使用Serial Old进行另一次GC。采用标记清除算法，会产生空间碎片。因为无法却保使用并发-整理算法带来的内存移动准确性
G1收集器
1.7出现的
G1是一款面向服务端应用的垃圾收集器。它具有以下特点：
- 并行与并发。G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU来缩短Stop-The-World的时间，部分其他收集器原本需要停顿Java线程执行的GC，G1任然可以通过并发的方式让Java程序继续执行
- 分代收集
- 空间整合：与CMS的标记-清理不同，G1整体来看是标记-整理算法，从局部(两个Region)之间上来看是基于复制算法实现的。但不管怎样都不会产生空间不规则的情况
- 可预测停顿：这是G1相对于CMS的另一大优势，能让使用者明确指定再一个长度未M毫秒的时间片段内，消耗在垃圾收集上不得超过N秒。
G1之所以能建立可预测的机制，就是因为将内存分为了许多大小相同的Region，可以有计划的进行垃圾收集。G1跟踪各个Region里面的垃圾堆积价值大小，在后台维护一个有限列表，每次根据允许的收集时间，优先回收价值最大的Region。
G1的一个Region里面的对象可能关联到其他区域的对象，再其他分代收集中，新生代的对象也可能引用到老年代的对象，在回收新生代的时候需要考虑到这一部分，为了避免对老年代的扫描，维护了一个Remmbered Set来避免全堆扫描的。G1中每个Region都有一个与之对应的Remembered Set。当虚拟机发现程序对Refrence类型的数据进行写操作时，会检查Reference引用的对象是否处于不同的Region之中(在分代的例子中就是检查是否老年代中的对象引用了新生代的对象)，如果是，就把相关引用信息记录到被引用对象所属的Region的Rememberd Set之中。当进行内存回收时，再GC根节点的枚举范围中加入Rememberd Set即可保证不对全堆扫描也不会又遗漏
G1收集过程
- 初始标记
- 并发标记
- 最终标记(将并发标记过程中标记产生改变的那一部分标记记录，存在Remembered Set Logs中)
- 筛选回收
内存分配
Java对象主要分配在新生代的Eden区上，如果启动了本地线程缓冲，将按照线程优先在TLAB上分配，少数情况下也可能直接分配在老年代中。
- 优先在Eden区分配，如果Eden区空间不够，虚拟机将发起一次Minor GC。新生代GC(Minor GC)：指发生在新生代的垃圾收集动作。非常频繁，一般回收速度也比较快。老年代GC ：发生在老年代，出现了Major GC经常会伴随至少一次的Minor GC。速度一般比Minor GC慢10倍以上
- 大对象直接进入老年代，比如很长的字符串以及数组。虚拟机提供了-XX:PretenureSizeThreshold参数(仅对Serial和ParNew两款收集器有效)，令大于这个设置值的对象直接在老年代分配。来避免在Eden区及两个Survivor区之间的内存复制。
- 长期存活的对象将直接进入老年代。对象在Eden区产生，经过一个Minor GC过后依然存活会被移动到Survivor区，并对象年龄加1.当增加到一定程度(默认为15)就会被移动到老年代
- 动态年龄判断，若Survivor空间中相同年龄所有对象大小的总和大于Survivor空间一半，年龄大于或等于该年龄的对象可以直接进入老年队。
- 空间分配担保。JDK6 update 24之后，规则即为只要老年代的连续空间大于新生代对象大小或者历次晋升的平均大小就会进行Minor GC，否则将进行Full GC
内存工具
- jps: 虚拟机进程状况工具
- jstat: 虚拟机统计信息监视工具
- jinfo: java配置信息工具
- jmap: Java内存印象工具
- jhat: 虚拟机堆转储快照分析工具
- jstack: java堆栈跟踪工具