在C语言中,有些由内存需要程序员在代码中进行手动回收，但是在Java中，没有这样的声明式操作。有没有人有去想过，Java到底做了什么可以自动进行垃圾回收呢？Java中的垃圾回收，是一点都不需要程序员关心，万无一失的吗？

本文将从：Jvm中的垃圾收集器和内存分配策略。虚拟机中对已经死亡的对象都有哪些垃圾回收是算法，两部分和大家谈谈Java虚拟机的垃圾收集器与内存分配策略。

重垃圾收集器和内存分配策略

垃圾收集（Garbage Collection，GC），并不是随着Java一起诞生的。GC的历史比Java来得更加久远，早在1960年的时候，MIT的Lisp是第一门真正使用内存动态分配和垃圾收集技术的语言。当Lisp还在胚胎时期时，人们就在思考GC需要完成的三件事情：哪些内存需要回收？什么时候回收？如何回收？

在经过半个世纪的发展后，对于这三个问题的答案越来越清晰，总结成就是：当需要排查各种内存溢出、内存泄漏问题时，当垃圾收集成为系统达到更高并发量的瓶颈时，我们就需要对这些“自动化”的技术实施必要的监控和调节。

在Java程序编写的过程中，我们可以知道代码的逻辑是怎样的，但是具体的分支只有在运行过程中才能知道。而这部分的内存分配和回收也是动态进行的，垃圾收集器主要关注的就是这部分内存。

那么实际中，一个需要解决的问题就是，如何判断对象是否存活，对于不再存活的对象，进行垃圾回收。

在经过漫长的发展后，目前主要有下面几种算法来进行对象存活判断。

▐ 引用计数算法

算法的定义为：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器都为0的对象就是不可能再被使用的。

这是实现简单，且效率非常高效的一种算法。在redis、python的虚拟机、FlashPlayer等应用中，也都有采用这样的算法。但是Java中并没有采用这样的算法实现，主要原因是其存在相互循环引用的问题。

简单来说，A对象引用B对象，B对象引用A对象的情况下。A和B互相引用，于是他们的计数器都不会为0，于是GC收集器便就永远无法回收他们。

▐ 根搜索算法

算法的定义为：通过一系列名为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain）,当一个对象到GC Roots没有任何引用链相连，或者说不可达的时候，则证明此对象不可用。

在Java语言中，可以作为GC Roots的对象包括下面几种：

• 虚拟机栈（栈帧中的本地变量表）中的引用的对象。
• 方法区中的类静态属性引用的对象。
• 方法区中的常量引用的对象。
• 本地方法栈中JNI（即一般说的Native方法）的引用的对象

▐ 引用

在早期的JDK定义中，引用的定义为，如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称这块内存代表着一个引用。但这样的定义方式过于纯粹，一个对象只有两种状态，即被引用或者没有被引用两种。对于一些缓存类型的数据，则显得有些鸡肋，更无法体现内存分配的价值。

之后JDK对于引用进行了概念扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）四种，这四种引用强度依次逐渐减弱。

• 强引用就是指在程序代码之中普遍存在的，类似“Object obj = new Object()”这类的引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。
• 软引用用来描述一些还有用，但并非必需的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中并进行第二次回收。如果这次回收还是没有足够的内存，才会抛出内存溢出异常。在JDK 1.2之后，提供了SoftReference类来实现软引用。
• 弱引用也是用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。在JDK 1.2之后，提供了WeakReference类来实现弱引用。
• 虚引用也称为幽灵引用或者幻影引用，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是希望能在这个对象被收集器回收时收到一个系统通知。在JDK 1.2之后，提供了PhantomReference类来实现虚引用。

▐ 是否死亡

在根搜索算法中，在GCRoots没有可以到达的引用链之后，就一定会“死亡”吗？其实也不一定，要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行根搜索后发现没有与GCRoots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法，或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”。

当这个对象需要执行finalize()方法时，这个对象会被放置在一个名为F-Queue的队列中，并稍后由一条虚拟机自动建立的、低优先级的Finalizer线程去执行。这里的“执行”是虚拟机会触发这个方法，但并不一定会等待它运行结束。因为如果对象在finalize()方法中死循环或者超长时间执行，可能导致F-Queue队列中的其他对象永久处于等待状态，甚至可能导致内存回收系统奔溃。

finalize()方法是对象可以存活的最后一次机会，在这里可以将自己和引用链上的任何一个对象建立关联即可，否则就会进入到垃圾回收的系统中。但finalize()依旧是一种充满不确定性的方法，在诞生之初亦是为了C/C++程序员的更容易接受的一种妥协，推荐目前的try-finally方法处理更加优雅，也更安全可靠。

接着我们一起来看看虚拟机中对已经死亡的对象都有哪些垃圾回收是算法。

▐ 标记-清除算法

标记-清除算法（Mark-Sweep）可以说应该是最基础的收集算法了。从字面意思很好理解，算法的过程分为标记过程和清楚过程。首先标记出所有需要回收的对象，在标记完了之后，对标记对象进行统一的回收工作。哪些对象需要标记，哪些对象不需要标记，这个再上一篇文章中进行了详细的介绍，可以回顾再了解下。

这个算法的缺点也非常明显，内存中的被标记的数据不一定都是连续，因此标记清楚之后，内存中会产生大量的内存碎片，碎片的存在也会导致在后续分配较大对象时候找不到足够的连续空间，导致内存不足。还有一个问题，便是标记和清楚的效率都不高。

但之所以说这是最基础的收集算法，是因为后续是算法基本上都是由此改进得来的。

▐ 复制算法

为了解决效率问题，诞生了一种叫复制（Copying）的算法。该算法将可以用的内存空间划分为两大块，每次只使用其中的一块。当这块内存使用完了之后，就将还存活的对象复制到另一块空间中去。这样就不需要考虑内存碎片的问题，只需要移动堆顶指针，按顺序分配内存即可，简单高效。同样缺点也很明显，这样做了之后很明显，我们只能使用内存中的一半内存。代价还是比较高。

那么目前的虚拟机新生代中，就采用了这种回收算法。新生代的空间相对较小，内存空间由Eden，和两块Survivor空间组成，分配比例为8:1:1，也就是最多只有10%的空间是处于空闲的。当进行回收时，将新生代的Eden和其中一块的Survivor中的还存活的对象一次性拷贝到另一块Survivor的空间上，然后清理掉Eden和刚才用过的Survivor的空间。如果当Survivor的无法存放时候，就会进入老年代存放。

▐ 标记-整理算法

复制算法在对象存活较高的时候，就会执行较多的复制操作，从而降低整体的回收效率，还有存在50%的空间浪费。基于这种情况，有人对标记-清楚算法进行改进，从而衍生出标记-整理（Mark-Compact）算法。

这种算法的标记过程和”标记-清楚“算法一致，不同的是标记完成之后，让所有存活的对象都移动到内存的一端，然后清理掉边界外面的内存。

▐ 分代收集算法

当前商业虚拟机的垃圾收集都采用“分代收集”（Generational Collection）算法，这种算法并没有什么新的思想，只是根据对象的存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或“标记-整理”算法来进行回收。

哪些垃圾回收是算法？

▐ 垃圾收集器

收集算法是用以支撑内存回收的理论，在虚拟机中对应的具体实现就是垃圾收集器。不同的厂商和开发者，可以依据自己的应用特点来实现对应的收集器，因此不同版本之间的收集器可能存在较大的差别。
以下收集器内容摘录自参考书籍《深入理解Java虚拟机》

▐ Serial垃圾收集器

Serial是最基本、历史最悠久的垃圾收集器，使用复制算法，曾经是JDK1.3.1之前新生代唯一的垃圾收集器。

Serial是一个单线程的收集器，它不仅仅只会使用一个CPU或一条线程去完成垃圾收集工作，并且在进行垃圾收集的同时，必须暂停其他所有的工作线程，直到垃圾收集结束。

Serial垃圾收集器虽然在收集垃圾过程中需要暂停所有其他的工作线程，但是它简单高效，对于限定单个CPU环境来说，没有线程交互的开销，可以获得最高的单线程垃圾收集效率，因此Serial垃圾收集器依然是java虚拟机运行在Client模式下默认的新生代垃圾收集器。

▐ ParNew垃圾收集器

ParNew垃圾收集器其实是Serial收集器的多线程版本，也使用复制算法，除了使用多线程进行垃圾收集之外，其余的行为和Serial收集器完全一样，ParNew垃圾收集器在垃圾收集过程中同样也要暂停所有其他的工作线程。

ParNew收集器默认开启和CPU数目相同的线程数，可以通过-XX:ParallelGCThreads参数来限制垃圾收集器的线程数。

ParNew虽然是除了多线程外和Serial收集器几乎完全一样，但是ParNew垃圾收集器是很多java虚拟机运行在Server模式下新生代的默认垃圾收集器。

▐ Parallel Scavenge收集器

Parallel Scavenge收集器也是一个新生代垃圾收集器，同样使用复制算法，也是一个多线程的垃圾收集器，它重点关注的是程序达到一个可控制的吞吐量（Thoughput，CPU用于运行用户代码的时间/CPU总消耗时间，即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)），高吞吐量可以最高效率地利用CPU时间，尽快地完成程序的运算任务，主要适用于在后台运算而不需要太多交互的任务。

Parallel Scavenge收集器提供了两个参数用于精准控制吞吐量：

• XX:MaxGCPauseMillis：控制最大垃圾收集停顿时间，是一个大于0的毫秒数。
• XX:GCTimeRation：直接设置吞吐量大小，是一个大于0小于100的整数，也就是程序运行时间占总时间的比率，默认值是99，即垃圾收集运行最大1%（1/(1+99)）的垃圾收集时间。

Parallel Scavenge是吞吐量优先的垃圾收集器，它还提供一个参数：-XX:+UseAdaptiveSizePolicy，这是个开关参数，打开之后就不需要手动指定新生代大小(-Xmn)、Eden与Survivor区的比例(-XX:SurvivorRation)、新生代晋升年老代对象年龄(-XX:PretenureSizeThreshold)等细节参数，虚拟机会根据当前系统运行情况收集性能监控信息，动态调整这些参数以达到最大吞吐量，这种方式称为GC自适应调节策略，自适应调节策略也是ParallelScavenge收集器与ParNew收集器的一个重要区别。

▐ Serial Old收集器

Serial Old是Serial垃圾收集器年老代版本，它同样是个单线程的收集器，使用标记-整理算法，这个收集器也主要是运行在Client默认的java虚拟机默认的年老代垃圾收集器。

在Server模式下，主要有两个用途：

• 在JDK1.5之前版本中与新生代的Parallel Scavenge收集器搭配使用。
• 作为年老代中使用CMS收集器的后备垃圾收集方案。

▐ Parallel Old收集器

Parallel Old收集器是Parallel Scavenge的年老代版本，使用多线程的标记-整理算法，在JDK1.6才开始提供。

在JDK1.6之前，新生代使用ParallelScavenge收集器只能搭配年老代的Serial Old收集器，只能保证新生代的吞吐量优先，无法保证整体的吞吐量，Parallel Old正是为了在年老代同样提供吞吐量优先的垃圾收集器，如果系统对吞吐量要求比较高，可以优先考虑新生代Parallel Scavenge和年老代Parallel Old收集器的搭配策略。

▐ CMS收集器

Concurrent mark sweep(CMS)收集器是一种年老代垃圾收集器，其最主要目标是获取最短垃圾回收停顿时间，和其他年老代使用标记-整理算法不同，它使用多线程的标记-清除算法。

最短的垃圾收集停顿时间可以为交互比较高的程序提高用户体验，CMS收集器是Sun HotSpot虚拟机中第一款真正意义上并发垃圾收集器，它第一次实现了让垃圾收集线程和用户线程同时工作。

CMS工作机制相比其他的垃圾收集器来说更复杂，整个过程分为以下4个阶段：

• 初始标记：只是标记一下GC Roots能直接关联的对象，速度很快，仍然需要暂停所有的工作线程。
• 并发标记：进行GC Roots跟踪的过程，和用户线程一起工作，不需要暂停工作线程。
• 重新标记：为了修正在并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，仍然需要暂停所有的工作线程。
• 并发清除：清除GC Roots不可达对象，和用户线程一起工作，不需要暂停工作线程。

由于耗时最长的并发标记和并发清除过程中，垃圾收集线程可以和用户现在一起并发工作，所以总体上来看CMS收集器的内存回收和用户线程是一起并发地执行。

CMS收集器有以下三个不足：

• CMS收集器对CPU资源非常敏感，其默认启动的收集线程数=(CPU数量+3)/4，在用户程序本来CPU负荷已经比较高的情况下，如果还要分出CPU资源用来运行垃圾收集器线程，会使得CPU负载加重。
• CMS无法处理浮动垃圾(Floating Garbage)，可能会导致Concurrent ModeFailure失败而导致另一次Full GC。由于CMS收集器和用户线程并发运行，因此在收集过程中不断有新的垃圾产生，这些垃圾出现在标记过程之后，CMS无法在本次收集中处理掉它们，只好等待下一次GC时再将其清理掉，这些垃圾就称为浮动垃圾。
  CMS垃圾收集器不能像其他垃圾收集器那样等待年老代机会完全被填满之后再进行收集，需要预留一部分空间供并发收集时的使用，可以通过参数-XX:CMSInitiatingOccupancyFraction来设置年老代空间达到多少的百分比时触发CMS进行垃圾收集，默认是68%。

如果在CMS运行期间，预留的内存无法满足程序需要，就会出现一次ConcurrentMode Failure失败，此时虚拟机将启动预备方案，使用Serial Old收集器重新进行年老代垃圾回收。

• CMS收集器是基于标记-清除算法，因此不可避免会产生大量不连续的内存碎片，如果无法找到一块足够大的连续内存存放对象时，将会触发因此Full GC。CMS提供一个开关参数-XX:+UseCMSCompactAtFullCollection，用于指定在Full GC之后进行内存整理，内存整理会使得垃圾收集停顿时间变长，CMS提供了另外一个参数-XX:CMSFullGCsBeforeCompaction，用于设置在执行多少次不压缩的Full GC之后，跟着再来一次内存整理。

▐ G1收集器

Garbage first垃圾收集器是目前垃圾收集器理论发展的最前沿成果，相比与CMS收集器，G1收集器两个最突出的改进是：

• 基于标记-整理算法，不产生内存碎片。
• 可以非常精确控制停顿时间，在不牺牲吞吐量前提下，实现低停顿垃圾回收。

G1收集器避免全区域垃圾收集，它把堆内存划分为大小固定的几个独立区域，并且跟踪这些区域的垃圾收集进度，同时在后台维护一个优先级列表，每次根据所允许的收集时间，优先回收垃圾最多的区域。

区域划分和优先级区域回收机制，确保G1收集器可以在有限时间获得最高的垃圾收集效率。

总结

其实相对于C和C++语言，Java程序员依赖JVM的强大内存管理能力，已经不再需要对内存进行分配或者释放等操作。所以Java程序员往往很少关注内存中潜在的泄露和溢出等问题。但当这个问题出现时候，如果对虚拟机内存管理机制没有足够多的掌握，会难以定位和解决问题。去了解虚拟机的发展历程以及现有的管理机制，可以更好地理解为什么这样设计，同样能提高自己的问题解决能力。

淘系技术部-天猫奢侈品团队

我们是一支支撑天猫奢侈品、品牌客户、淘宝心选等大店数据化经营解决方案的技术团队，依托于阿里大中台推动品牌经营解决方案升级，不断提升客户经营的效率，持续提升业务价值赋能业务。

如果您有兴趣可讲简历发至：gangmin.zgm@alibaba-inc.com，期待您的加入!

关注「淘系技术」微信公众号，一个有温度有内容的技术社区~