Java内存区域运行时，程序计数器、虚拟机栈、本地方法栈随线程而生，随线程而灭；栈中的栈帧随着方法的进入和退出而执行着出栈和入栈操作，每一个栈帧中分配多少内存在类结构确定下来时(编译期)大体上是已知的。方法结束或者线程结束时，内存自然就回收了，所以这几个区域就不需要过多考虑内存分配和回收的问题。而Java堆和方法区就不一样，我们只有在程序处于运行期间才知道会需要多少内存，这部分的内存分配和回收都是动态的，GC收集器所关注的就是这部分内存。
1、哪些对象需要回收
在堆里面存放着Java世界中几乎所有的对象实例,垃圾收集器在对堆进行回收前,第件事情就是要确定这些对象之中哪些还“存活”着,哪些已经“死去”(即不可能再被任何途径使用的对象)。
1.1、引用计数算法
给对象中添加一个引用计数器,每当有一个地方引用它时,计数器值就加1:当引用失效时,计数器值就减1:任何时刻计数器为0的对象就是不可能再被使用的。引用计数算法(Reference Counting)的实现简单,判定效率也很高,在大部分情况下它都是一个不错的算法。但是,至少主流的Java虚拟机里面没有选用引用计数算法来管理内存,其中最主要的原因是它很难解决对象之间相互循环引用的问题。
举个简单的例子，假设对象objA和objB都有字段instance,赋值令 objA.instance=objB及 objB.instance=objA,除此之外,这两个对象再无任何引用,实际上这两个对象已经不可能再被访问,但是它们因为互相引用着对方,导致它们的号用计数都不为0,于是引用计数算法无法通知GC收集器回收它们。
1.2、可达性分析算法
在主流的商用程序语言的主流实现中,都是称通过可达性分析( Reachability Analysis)来判定对象是否存活的。这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点,从这些节点开始向下搜索,搜索所走过的路径称为引用链(Reference Chain),当一个对象到 GC Roots没有任何引用链相连(用图论的话来说,就是从 GC Roots到这个对象不可达)时,则证明此对象是不可用的。如图所示,对象 object5、 object6、 object7虽然互相有关联,但是它们到 GC-Roots是不可达的,所以它们将会被判定为是可回收的对象。
在Java语言中,可作为 GC Roots的对象包括下面几种:
- 在虚拟机栈（栈帧中的本地变量表）中引用的对象，譬如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等。
- 在方法区中类静态属性引用的对象，譬如Java类的引用类型静态变量。
- 在方法区中常量引用的对象，譬如字符串常量池（String Table）里的引用。
- 在本地方法栈中JNI（即通常所说的Native方法）引用的对象。
- Java虚拟机内部的引用，如基本数据类型对应的Class对象，一些常驻的异常对象（比如NullPointExcepiton、OutOfMemoryError）等，还有系统类加载器。
- 所有被同步锁（synchronized关键字）持有的对象。
- 反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等。
除了这些固定的 GC Roots集合以外，根据用户所选用的垃圾收集器以及当前回收的内存区域不 同，还可以有其他对象 “ 临时性 ” 地加入，共同构成完整 GC Roots集合。譬如后文将会提到的分代收集和局部回收（ Partial GC ），如果只针对Java堆中某一块区域发起垃圾收集时（如最典型的只针对新生 代的垃圾收集），必须考虑到内存区域是虚拟机自己的实现细节（在用户视角里任何内存区域都是不 可见的），更不是孤立封闭的，所以某个区域里的对象完全有可能被位于堆中其他区域的对象所引 用，这时候就需要将这些关联区域的对象也一并加入 GC Roots集合中去，才能保证可达性分析的正确 性。 目前最新的几款垃圾收集器 （ 如 OpenJDK 中的 G1 、 Shenandoah 、 ZGC 以及 Azul 的 PGC 、 C4 这些收集器 ） 无一例外都具备了局部回收的特征，为了避免 GC Roots包含过多对象而过度膨胀，它们在实现上也做出了各种优化处理。
1.3、对象的引用
无论是通过引用计数算法判断对象的引用数量,还是通过可达性分析算法判断对象的引用链是否可达,判定对象是否存活都与“引用”有关。在JDK1.2以前,Java中的引用的定义很传统:如果 reference类型的数据中存储的数值代表的是另外一块内存的起始地址,就称这块内存代表着一个引用。这种定义很纯粹,但是太过狭隘,一个对象在这种定义下只有被引用或者没有被引用两种状态,对于如何描述一些“食之无味,弃之可惜”的对象就显得无能为力。我们希望能描述这样一类对象:当内存空间还足够时,则能保留在内存之中;如果内存空间在进行垃圾收集后还是非常紧张,则可以抛弃这些对象。很多系统的缓存功能都符合这样的应用场景。
在JDK1.2之后,Java对引用的概念进行了扩充,将引用分为强引用(Strong Reference)、软引用(Soft Reference)、弱引用(Weak Reference)、虚引用(Phantom Reference)。这4种引用强度依次减弱，具体参考https://blog.csdn.net/shenchaohao12321/article/details/93369858。
1.4、finalize() 方法
即使在可达性分析算法中不可达的对象,也并非是“非死不可”的,这时候它们暂时处于“缓刑”阶段,要真正宣告一个对象死亡,至少要经历两次标记过程:
- 如果对象在进行可达性分析后发现没有与 GC Roots相连接的引用链,那它将会被第一次标记并且进行一次筛选,筛选的条件是此对象是否有必要执行 finalize方法。当对象没有覆盖 finalize方法,或者 finalize方法已经被虚拟机调用过,虚拟机将这两种情况都视为“没有必要执行”，对象被回收。
- 如果这个对象被判定为有必要执行 finalized方法,那么这个对象将会放置在一个叫做F-Queue的队列之中,并在稍后由一个由虚拟机自动建立的、低优先级的 Finalizer线程去执行它。这里所谓的“执行”是指虚拟机会触发这个方法,但并不承诺会等待它运行结束,这样做的原因是,如果一个对象在 finalize方法中执行缓慢,或者发生了死循环(更极端的情况),将很可能会导致 F-Queue队列中其他对象永久处于等待,甚至导致整个内存回收系统崩溃。 finalize方法是对象逃脱死亡命运的最后一次机会,稍后GC将对F- Queue中的对象进行第二次小规模的标记,如果对象要在 finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可,譬如把自己(this关键字)赋值给某个类变量或者对象的成员变量,那在第二次标记时它将被移除出“即将回收”的集合;如果对象这时候还没有逃脱,那基本上它就真的被回收了。
另外一个值得注意的地方是,任何一个对象的 finalize方法都只会被系统自动调用一次,如果对象面临下一次回收,它的 finalize方法不会被再次执行。
1.5、回收方法区
Java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾收集,而且在方法区中进行垃圾收集的“性价比”一般比较低:在堆中,尤其是在新生代中,常规应用进行一次垃圾收集一般可以回收70%~95%的空间,相比之下，方法区回收囿于苛刻的判定条件，其区域垃圾收集的回 收成果往往远低于此。
方法区的垃圾收集主要回收两部分内容:废弃常量和无用的类。回收废弃常量与回收Java堆中的对象非常类似。以常量池中字面量的回收为例,假如一个字符串“abc”已经进入了常量池中,但是当前系统没有任何一个 String对象是叫做“abc”的,换句话说,就是没有任何 String对象引用常量池中的“abc”常量,也没有其他地方引用了这个字面量,如果这时发生内存回收,而且必要的话,这个“abc”常量就会被系统清理出常量池。常量池中的其他类(接口)、方法、字段的符号引用也与此类似。
判定一个常量是否是“废弃常量”比较简单,而要判定一个类是否是“无用的类”的条件则相对苛刻许多。类需要同时满足下面3个条件才能算是“无用的类”：
- 该类所有的实例都已经被回收,也就是Java堆中不存在该类的任何实例。
- 加载该类的 Class Loader已经被回收，这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、JSP的重加载等，否则通常是很难达成的。
- 该类对应的 java.lang.Class象没有在任何地方被引用,无法在任何地方通过反射访问该类的方法。
Java 虚拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是 “ 被允许 ”，而并不是 和对象一样，没有引用了就必然会回收。关于是否要对类型进行回收， HotSpot 虚拟机提供了-Xnoclassgc 参数进行控制，还可以使用 -verbose ： class 以及 -XX : +TraceClass-Loading 、 -XX: +TraceClassUnLoading 查看类加载和卸载信息，其中 -verbose : class 和 -XX : +TraceClassLoading可以在 Product 版的虚拟机中使用， -XX : +TraceClassUnLoading 参数需要 FastDebug 版 的虚拟机支持。 在大量使用反射、动态代理、 CGLib 等字节码框架，动态生成 JSP 以及 OSGi这类频繁自定义类加载 器的场景中，通常都需要 Java虚拟机具备类型卸载的能力，以保证不会对方法区造成过大的内存压 力。
2、垃圾收集算法
从如何判定对象消亡的角度出发，垃圾收集算法可以划分为 “ 引用计数式垃圾收集 ” （Reference Counting GC ）和 “ 追踪式垃圾收集 ” （ Tracing GC ）两大类，这两类也常被称作 “ 直接垃圾收集 ” 和 “间接垃圾收集 ” 。由于引用计数式垃圾收集算法在主流 Java虚拟机中均未涉及，所以我们暂不 把它作为正文主要内容来讲解，本节介绍的所有算法均属于追踪式垃圾收集的范畴。
2.1、分代收集理论
当前商业虚拟机的垃圾收集器，大多数都遵循了 “ 分代收集 ” （ Generational Collection）的理论进 行设计，分代收集名为理论，实质是一套符合大多数程序运行实际情况的经验法则，它建立在两个分 代假说之上： 1 ）弱分代假说（ Weak Generational Hypothesis ）：绝大多数对象都是朝生夕灭的。 2 ）强分代假说（ Strong Generational Hypothesis）：熬过越多次垃圾收集过程的对象就越难以消 亡。 这两个分代假说共同奠定了多款常用的垃圾收集器的一致的设计原则：收集器应该将Java堆划分出不同的区域，然后将回收对象依据其年龄（年龄即对象熬过垃圾收集过程的次数）分配到不同的区域之中存储。显而易见，如果一个区域中大多数对象都是朝生夕灭，难以熬过垃圾收集过程的话，那么把它们集中放在一起，每次回收时只关注如何保留少量存活而不是去标记那些大量将要被回收的对 象，就能以较低代价回收到大量的空间；如果剩下的都是难以消亡的对象，那把它们集中放在一块，虚拟机便可以使用较低的频率来回收这个区域，这就同时兼顾了垃圾收集的时间开销和内存的空间有效利用。 在 Java堆划分出不同的区域之后，垃圾收集器才可以每次只回收其中某一个或者某些部分的区域—— 因而才有了 “Minor GC”“Major GC”“Full GC”这样的回收类型的划分；也才能够针对不同的区域安排与里面存储对象存亡特征相匹配的垃圾收集算法 —— 因而发展出了 “ 标记 - 复制算法 ”“ 标记 -清除算法 ”“ 标记 - 整理算法 ”等针对性的垃圾收集算法。 把分代收集理论具体放到现在的商用 Java 虚拟机里，设计者一般至少会把 Java堆划分为新生代（ Young Generation ）和老年代（ Old Generation）两个区域。顾名思义，在新生代中，每次垃圾收集 时都发现有大批对象死去，而每次回收后存活的少量对象，将会逐步晋升到老年代中存放。 假如要现在进行一次只局限于新生代区域内的收集（ Minor GC），但新生代中的对象是完全有可 能被老年代所引用的，为了找出该区域中的存活对象，不得不在固定的GC Roots之外，再额外遍历整个老年代中所有对象来确保可达性分析结果的正确性，反过来也是一样。遍历整个老年代所有对象的方案虽然理论上可行，但无疑会为内存回收带来很大的性能负担。为了解决这个问题，就需要对分代收集理论添加第三条经验法则： 3 ）跨代引用假说（ Intergenerational Reference Hypothesis）：跨代引用相对于同代引用来说仅占极 少数。 这其实是可根据前两条假说逻辑推理得出的隐含推论：存在互相引用关系的两个对象，是应该倾向于同时生存或者同时消亡的。举个例子，如果某个新生代对象存在跨代引用，由于老年代对象难以消亡，该引用会使得新生代对象在收集时同样得以存活，进而在年龄增长之后晋升到老年代中，这时跨代引用也随即被消除了。 依据这条假说，我们就不应再为了少量的跨代引用去扫描整个老年代，也不必浪费空间专门记录每一个对象是否存在及存在哪些跨代引用，只需在新生代上建立一个全局的数据结构（该结构被称为 “ 记忆集 ” ， Remembered Set），这个结构把老年代划分成若干小块，标识出老年代的哪一块内存会存在跨代引用。此后当发生 Minor GC 时，只有包含了跨代引用的小块内存里的对象才会被加入到GC Roots进行扫描。虽然这种方法需要在对象改变引用关系（如将自己或者某个属性赋值）时维护记录数 据的正确性，会增加一些运行时的开销，但比起收集时扫描整个老年代来说仍然是划算的。
部分收集（ Partial GC ）：指目标不是完整收集整个 Java 堆的垃圾收集，其中又分为： ■ 新生代收集（ Minor GC/Young GC ）：指目标只是新生代的垃圾收集。 ■ 老年代收集（ Major GC/Old GC ）：指目标只是老年代的垃圾收集。目前只有 CMS收集器会有单独收集老年代的行为。另外请注意 “Major GC”这个说法现在有点混淆，在不同资料上常有不同所指， 读者需按上下文区分到底是指老年代的收集还是整堆收集。 ■ 混合收集（ Mixed GC ）：指目标是收集整个新生代以及部分老年代的垃圾收集。目前只有 G1收集器会有这种行为。 整堆收集（ Full GC ）：收集整个 Java 堆和方法区的垃圾收集。
[1] 值得注意的是，分代收集理论也有其缺陷，最新出现（或在实验中）的几款垃圾收集器都展现出了 面向全区域收集设计的思想，或者可以支持全区域不分代的收集的工作模式。 [2] 新生代（ Young ）、老年代（ Old ）是 HotSpot 虚拟机，也是现在业界主流的命名方式。在 IBM J9虚拟机中对应称为婴儿区（ Nursery ）和长存区（ Tenured ），名字不同但其含义是一样的。 [3] 通常能单独发生收集行为的只是新生代，所以这里 “ 反过来 ”的情况只是理论上允许，实际上除了CMS 收集器，其他都不存在只针对老年代的收集。
2.2、标记-清除算法
最基础的收集算法是“标记-清除(Mark-Sweep)”算法 。算法分为“标记”和“清除”两个阶段：标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象，也可以反过来，标记存活的对象，统一回 收所有未被标记的对象。标记过程就是对象是否属于垃圾的判定过程。
它的主要不足有两个：第一个是执行效率不稳定，如果Java堆中包含大量对象，而且其中大部分是需要被回收的，这时必须进行大量标记和清除的动作，导致标记和清除两个过程的执行效率都随对象数量增长而降低；第二个是内存空间的碎片化问题，标记、清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致当以后在程序运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
2.3、标记-复制算法
标记-复制算法常被简称为复制算法。为了解决效率问题，一种称为“复制(Copying)”的收集算法出现了。它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针按顺序分配内存即可，简单高效。它的不足，简而言之就是拿空间换时间，将内存缩小为了原来的一半，这代价未免太高了。
现在主流的商业JVM都采用这种收集算法来回收新生代，新生代中的对象98%是“朝生夕死”的，所以并不需要按照1：1的比例来划分内存空间，而是将内存分为一块儿较大的Eden空间和两块较小的Surivior空间，每次使用Eden和其中一块Survivor空间。当需要内存回收时，将Eden和Survivor中还活着的对象一次性的复制到另一块Survivor空间上，最后清理掉Eden和刚才使用过的Survivor空间。Hotspot VM默认的Eden和Survivor的大小比例是8：1，也就是每次新生代中可用内存空间为整个新生代容量的90%(80%+10%)，只有10%的内存会被“浪费”。
当然，98%的对象可回收只是在一般场景下，我们没有办法保证每次回收都只有不多于10%的对象存活，但Survivor空间不够用时，需要依赖其他内存（例如老年代）进行分配担保。内存的分配担保的意思是，如果另外一块Surivior没有足够空间存放上一次新生代收集下来的存活对象时，这些对象将直接通过分配担保机制进入老年代。
2.4、标记-整理算法
复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费掉50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代中一般不直接选用这种算法。
根据老年代的特点，新的“标记-整理(Mark-Compact)”算法出现了，标记过程仍然与“标记-清除”算法一样，但后续步骤并不直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
标记 - 清除算法与标记 -整理算法的本质差异在于前者是一种非移动式的回收算法，而后者是移动式的。是否移动回收后的存活对象是一项优缺点并存的风险决策： 如果移动存活对象，尤其是在老年代这种每次回收都有大量对象存活区域，移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作，而且这种对象移动操作必须全程暂停用户应用程序才能进行 [1] ，这就更加让使用者不得不小心翼翼地权衡其弊端了，像这样的停顿被最初的虚拟机设计者形象地描述为 “Stop The World” [2] 。 但如果跟标记 -清除算法那样完全不考虑移动和整理存活对象的话，弥散于堆中的存活对象导致的空间碎片化问题就只能依赖更为复杂的内存分配器和内存访问器来解决。譬如通过 “分区空闲分配链表 ” 来解决内存分配问题（计算机硬盘存储大文件就不要求物理连续的磁盘空间，能够在碎片化的硬盘上存储和访问就是通过硬盘分区表实现的）。内存的访问是用户程序最频繁的操作，甚至都没有之一，假如在这个环节上增加了额外的负担，势必会直接影响应用程序的吞吐量。 基于以上两点，是否移动对象都存在弊端，移动则内存回收时会更复杂，不移动则内存分配时会更复杂。从垃圾收集的停顿时间来看，不移动对象停顿时间会更短，甚至可以不需要停顿，但是从整个程序的吞吐量来看，移动对象会更划算。此语境中，吞吐量的实质是赋值器（ Mutator，可以理解为使用垃圾收集的用户程序，为便于理解，多数地方用 “ 用户程序 ” 或 “ 用户线程”代替）与收集器的效率总和。即使不移动对象会使得收集器的效率提升一些，但因内存分配和访问相比垃圾收集频率要高得多，这部分的耗时增加，总吞吐量仍然是下降的。 HotSpot 虚拟机里面关注吞吐量的Parallel Scavenge 收集器是基于标记 - 整理算法的，而关注延迟的 CMS 收集器则是基于标记 -清除算法的，这也从侧面印证这点。 另外，还有一种 “ 和稀泥式 ”解决方案可以不在内存分配和访问上增加太大额外负担，做法是让虚拟机平时多数时间都采用标记 -清除算法，暂时容忍内存碎片的存在，直到内存空间的碎片化程度已经大到影响对象分配时，再采用标记 -整理算法收集一次，以获得规整的内存空间。前面提到的基于标记 - 清除算法的 CMS 收集器面临空间碎片过多时采用的就是这种处理办法。
[1] 最新的 ZGC 和 Shenandoah 收集器使用读屏障（ Read Barrier）技术实现了整理过程与用户线程的并发 执行，稍后将会介绍这种收集器的工作原理。 [2] 通常标记 -清除算法也是需要停顿用户线程来标记、清理可回收对象的，只是停顿时间相对而言要 来的短而已。