1. 项目概述深入JVM垃圾回收的底层世界在Java开发的世界里JVMJava虚拟机就像一位不知疲倦的管家默默打理着程序运行过程中产生的“垃圾”——那些不再被使用的对象。很多开发者尤其是刚入行的朋友对JVM的了解可能停留在“它会自动回收内存”这个模糊的概念上。但当你开始面对高并发场景下的性能瓶颈或者准备一场严肃的技术面试时你会发现对垃圾回收Garbage Collection, GC机制的深入理解是从“会用Java”到“懂Java”的关键分水岭。最近在社区和面试准备中关于JVM垃圾回收算法、机制以及调优的话题热度一直居高不下从基础的“标记-清除”到复杂的调优参数都成了必须啃下的硬骨头。这篇文章我们就来彻底拆解JVM的四种经典垃圾回收算法并理清其背后的工作机制。这不仅仅是应付面试题的背诵更是为了让你在遇到“应用卡顿”、“内存泄漏”甚至“服务崩溃”时能有一个清晰的排查思路。我们会从最基础的算法原理讲起结合内存布局一步步看到它们是如何在JVM中协作最终构成完整的垃圾回收机制的。无论你是正在准备面试还是希望优化自己的应用性能这些内容都将提供直接的帮助。2. JVM内存布局与垃圾回收的基石要理解垃圾回收算法首先得知道垃圾在哪里以及JVM是如何管理内存的。JVM的内存区域划分是垃圾回收活动发生的舞台。2.1 核心内存区域解析JVM运行时数据区主要分为线程共享和线程私有两大类。对于垃圾回收而言我们重点关注线程共享区域尤其是堆Heap。堆Heap这是垃圾回收的主战场几乎所有对象实例和数组都在这里分配内存。堆也是GC管理的主要区域。为了更高效地进行垃圾回收堆空间通常被进一步细分新生代Young Generation绝大多数新创建的对象首先在这里分配。新生代的特点是“朝生夕死”大部分对象很快变得不可达。因此新生代的垃圾回收称为Minor GC或Young GC发生非常频繁但速度也要求很快。新生代内部又通常划分为一个Eden区和两个Survivor区通常称为S0和S1或者From和To。老年代Old Generation/Tenured Generation在新生代中经历了多次垃圾回收后仍然存活的对象会被晋升Promote到老年代。此外一些大对象也可能直接分配在老年代。老年代的对象生命周期较长因此针对老年代的垃圾回收称为Major GC或Full GC发生频率较低但一旦发生耗时通常较长对应用停顿的影响也更大。方法区Method Area用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码缓存等数据。在HotSpot虚拟机中方法区的具体实现被称为“永久代”JDK 7及之前或“元空间”JDK 8及之后。这个区域也会发生垃圾回收主要是针对废弃的常量和不再使用的类但条件苛刻回收效率低。虚拟机栈、本地方法栈、程序计数器这些是线程私有的区域其生命周期与线程相同。栈帧随着方法调用而创建方法结束而销毁内存的分配和回收具备确定性因此不属于垃圾回收管理的范畴。2.2 对象存亡的判定如何定义“垃圾”在回收之前必须明确哪些对象是“垃圾”即不再被任何地方引用的对象。JVM主要使用两种算法来判定对象存亡引用计数算法在对象中添加一个引用计数器每当有一个地方引用它时计数器加1当引用失效时计数器减1。任何时刻计数器为0的对象就是不可能再被使用的。这个方法实现简单判定效率高但它有一个致命的缺陷无法解决对象之间循环引用的问题。例如对象A和对象B互相引用除此之外再无其他引用实际上它们已经无法被访问但它们的引用计数都不为0导致无法被回收。因此主流的Java虚拟机都没有选用引用计数算法来管理堆内存。可达性分析算法这是当前主流JVM使用的算法。它的基本思路是通过一系列称为“GC Roots”的根对象作为起始节点集从这些节点开始根据引用关系向下搜索搜索过程所走过的路径称为“引用链”。如果某个对象到GC Roots间没有任何引用链相连则证明此对象是不可能再被使用的。那么哪些对象可以作为GC Roots呢主要包括以下几种在虚拟机栈栈帧中的本地变量表中引用的对象例如当前正在运行的方法中的参数、局部变量等。在方法区中类静态属性引用的对象例如Java类的引用类型静态变量。在方法区中常量引用的对象例如字符串常量池里的引用。在本地方法栈中JNI即Native方法引用的对象。Java虚拟机内部的引用如基本数据类型对应的Class对象一些常驻的异常对象等。所有被同步锁synchronized关键字持有的对象。可达性分析算法有效地解决了循环引用的问题是垃圾回收器工作的理论基础。3. 四种经典垃圾回收算法深度剖析垃圾回收算法是方法论它定义了如何找到垃圾并回收内存空间。下面我们深入每一种算法的内部。3.1 标记-清除算法这是最基础、最直观的垃圾收集算法分为“标记”和“清除”两个阶段。标记阶段首先通过可达性分析遍历所有GC Roots标记出所有存活的对象。清除阶段再次遍历整个堆回收所有未被标记的对象所占用的内存。优点原理简单是后续很多算法的基础思想。缺点也非常明显执行效率不稳定标记和清除两个过程的效率都会随着堆中对象数量的增长而下降。内存空间碎片化标记清除后会产生大量不连续的内存碎片。当程序以后需要分配一个较大对象时可能无法找到足够的连续内存从而不得不提前触发另一次垃圾收集。注意你可以把堆内存想象成一个巨大的棋盘。标记-清除算法就像把棋盘上还有用的棋子存活对象标记出来然后把所有没标记的空白格子垃圾对象清空。问题是清空后的空白格子是散乱分布的当你想放一个需要连续3个格子的“大棋子”时可能找不到一排连续的3个空位尽管总的空位数量是够的。这就是内存碎片。3.2 复制算法为了解决标记-清除算法面对大量可回收对象时的效率问题和碎片问题复制算法出现了。它将可用内存按容量划分为大小相等的两块每次只使用其中的一块。工作流程当正在使用的那块内存称为From空间用尽时就启动垃圾回收。将From空间中所有存活的对象复制到另一块空闲的内存称为To空间上。复制完成后清空整个From空间。最后将From空间和To空间的角色交换。下次垃圾回收时新的From空间即原来的To空间重复此过程。优点高效对于存活对象比例较低的新生代每次只需要复制少量存活对象效率很高。无碎片每次复制后存活对象都被紧凑地排列在To空间的一端解决了内存碎片化问题。分配新对象时只需要移动堆顶指针速度极快这种分配方式称为“指针碰撞”。缺点内存代价高昂可用的内存空间直接被缩小为原来的一半空间利用率低。对象存活率高时效率低下如果绝大多数对象都是存活的那么复制的开销会变得非常大。正因为这些特点复制算法非常适合“朝生夕死”的新生代。在实际的JVM实现中并不需要按照1:1的比例来划分新生代空间。HotSpot虚拟机默认的Eden和Survivor区大小比例是8:1:1即每次新生代中可用内存空间为整个新生代容量的90%Eden 一个Survivor只有10%的空间会被“浪费”。当回收时将Eden和From Survivor中存活的对象一次性复制到To Survivor区然后清理掉Eden和From Survivor。这样只有10%的空间是闲置的提高了内存利用率。3.3 标记-整理算法复制算法在对象存活率高时要进行较多的复制操作效率会降低。更关键的是如果不想浪费50%的空间就需要有额外的空间进行分配担保以应对所有对象都存活的极端情况。所以在老年代这种对象存活率高的区域一般不能直接选用复制算法。标记-整理算法应运而生其标记过程与“标记-清除”算法一样但后续步骤不是直接清除而是让所有存活的对象都向内存空间的一端移动然后直接清理掉边界以外的内存。优点无内存碎片整理后存活对象占据内存的一端空闲内存集中在另一端是连续的空间。空间利用率高无需像复制算法那样预留一半空间。缺点效率问题移动存活对象并更新所有引用这些对象的指针是一个开销较大的操作而且这种移动操作必须全程暂停用户应用程序即“Stop The World”延迟会比标记-清除算法更高。3.4 分代收集算法当前商业虚拟机的垃圾收集器几乎都采用了分代收集算法。它并非一种全新的算法而是上述三种基础算法的组合运用其核心思想是根据对象存活周期的不同将堆内存划分为几块主要是新生代和老年代然后根据各个年代的特点采用最适合的垃圾收集算法。在新生代中对象的特点是“朝生夕死”每次垃圾回收时都有大量对象死去只有少量存活。因此复制算法是最佳选择只需要付出少量存活对象的复制成本且回收后内存排列整齐分配高效。在老年代中对象存活率高没有额外的空间对它进行分配担保。因此通常采用标记-清除或标记-整理算法进行回收。标记-清除CMS收集器在并发标记阶段使用以减少停顿时间但会产生碎片。标记-整理Parallel Old和G1等收集器使用避免碎片但停顿时间可能稍长。分代收集算法是理论与实践结合的完美典范它通过差异化的策略在整体上达到了时间回收效率和空间内存利用率的平衡。4. 垃圾回收机制与经典收集器实现算法是理论而垃圾收集器是算法的具体实现。HotSpot JVM提供了多种收集器适用于不同的应用场景。4.1 垃圾收集器分类与组合关系垃圾收集器可以按照不同维度分类按线程数可分为串行收集器单线程和并行收集器多线程。按工作模式可分为并发收集器垃圾回收线程与用户线程大部分时间同时工作和独占式收集器垃圾回收时需完全暂停用户线程即Stop-The-World。按处理内存区间可分为新生代收集器和老年代收集器。在JDK 8及之前HotSpot虚拟机中常见的收集器组合如下表所示虚线表示已废弃实线表示常用组合新生代收集器老年代收集器组合说明SerialSerial Old客户端模式下的默认组合简单高效。SerialCMS不常见CMS通常与ParNew配合。ParNewCMS服务端模式下常见的组合追求低停顿。ParNewSerial Old不常见备用方案。Parallel ScavengeParallel OldJDK 8服务端模式默认组合追求高吞吐量。Parallel ScavengeSerial OldParallel Scavenge的备用老年代方案。G1G1JDK 9及之后的默认全堆收集器不分新生代老年代。4.2 经典收集器工作原理简述Serial / Serial Old收集器特点单线程工作的收集器。进行垃圾回收时必须暂停所有其他工作线程Stop The World直到收集结束。应用Serial用于新生代采用复制算法Serial Old用于老年代采用标记-整理算法。它们是虚拟机在客户端模式下的默认收集器简单而高效对于内存不大、单核处理器的环境没有线程交互开销专心做垃圾回收效率很高。ParNew收集器特点本质上是Serial收集器的多线程并行版本除了使用多条线程进行垃圾收集外其余行为与Serial完全一致。应用新生代收集器复制算法。它是许多运行在服务端模式下的虚拟机中首选的新生代收集器一个重要原因是除了Serial只有它能与CMS收集器配合工作。Parallel Scavenge / Parallel Old收集器特点吞吐量优先收集器。目标是达到一个可控制的吞吐量。吞吐量 运行用户代码时间 / (运行用户代码时间 垃圾收集时间)。Parallel Scavenge用于新生代复制算法Parallel Old用于老年代标记-整理算法。应用JDK 8服务端模式的默认组合。适合后台运算、科学计算等不需要太多交互、关注任务尽快完成的应用。CMS收集器特点低停顿优先的收集器以获取最短回收停顿时间为目标。它允许垃圾收集线程与用户线程并发工作。工作流程比前几种复杂初始标记Stop The World仅标记GC Roots能直接关联到的对象速度很快。并发标记与用户线程并发从GC Roots开始进行可达性分析标记所有存活对象。耗时较长。重新标记Stop The World修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。比初始标记长但远比并发标记短。并发清除与用户线程并发清除死亡对象。缺点对处理器资源敏感无法处理“浮动垃圾”采用标记-清除算法会产生内存碎片。G1收集器特点面向服务端应用的垃圾收集器是JDK 9及之后的默认收集器。它开创了基于Region的堆内存布局和可预测的停顿时间模型。核心思想将整个Java堆划分为多个大小相等的独立区域Region虽然还保留新生代和老年代的概念但已不再是物理隔离而是一系列Region的集合。G1跟踪各个Region的垃圾堆积“价值”大小即回收所获得的空间大小以及回收所需时间的经验值在后台维护一个优先列表每次根据允许的收集时间优先回收价值最大的Region。优点可以指定最大垃圾收集停顿时间从整体看是基于标记-整理算法从局部两个Region之间看是基于复制算法都不会产生内存碎片。5. 内存分配、回收策略与调优核心理解了算法和收集器我们来看看对象在堆中是如何“走完一生”的以及我们如何干预这个过程。5.1 对象的内存分配与晋升对象的内存分配往大方向讲就是在堆上分配。但细节上主要分配在新生代的Eden区。如果启动了本地线程分配缓冲TLAB则会优先在TLAB上分配。少数情况下也可能直接分配在老年代。对象优先在Eden分配大多数情况下对象在新生代Eden区中分配。当Eden区没有足够空间时虚拟机将发起一次Minor GC。大对象直接进入老年代大对象如很长的字符串或元素数量庞大的数组需要大量连续内存空间容易导致提前触发垃圾收集。虚拟机提供了-XX:PretenureSizeThreshold参数令大于此阈值的对象直接在老年代分配避免在Eden和Survivor区之间来回复制。长期存活的对象将进入老年代虚拟机给每个对象定义了一个对象年龄计数器。对象在Eden出生并经过第一次Minor GC后仍然存活并且能被Survivor容纳则被移动到Survivor区年龄设为1。对象在Survivor区中每“熬过”一次Minor GC年龄就增加1岁。当年龄增加到一定程度默认15岁可通过-XX:MaxTenuringThreshold设置就会被晋升到老年代。动态对象年龄判定为了能更好地适应不同程序的内存状况虚拟机并不总是要求对象年龄必须达到MaxTenuringThreshold才能晋升。如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半年龄大于或等于该年龄的对象就可以直接进入老年代。5.2 空间分配担保与Full GC在发生Minor GC之前虚拟机必须先检查老年代最大可用的连续空间是否大于新生代所有对象总空间。如果这个条件成立那么Minor GC可以确保是安全的。如果不成立虚拟机会查看-XX:HandlePromotionFailure参数的设置JDK 6 Update 24之后规则有变此参数不再影响策略。当前的策略是只要老年代的连续空间大于新生代对象总大小或者历次晋升到老年代对象的平均大小就会进行Minor GC否则将进行Full GC。实操心得频繁的Full GC往往是性能问题的直接表现。你可以通过GC日志添加JVM参数-XX:PrintGCDetails来观察。如果发现每次Minor GC后老年代的使用率都有显著且异常的增长或者频繁触发“Allocation Failure”导致Full GC就需要警惕了。这可能意味着存在内存泄漏对象无法被回收或者新生代Survivor区太小/晋升年龄阈值太低导致“短命”对象过早进入老年代最终引发老年代过早被填满。5.3 关键JVM参数与调优思路调优没有银弹必须结合具体应用场景。以下是一些核心参数和思路堆内存相关-Xms/-Xmx设置堆的初始大小和最大大小。通常设为相同值避免堆动态扩容收缩带来的性能损耗。-Xmn设置新生代大小。增大新生代能减少Minor GC频率但会缩小老年代可能增加Full GC风险。需要权衡。-XX:NewRatio设置老年代与新生代的比例默认2即老年代:新生代2:1。-XX:SurvivorRatio设置Eden区与一个Survivor区的比例默认8即Eden:Survivor8:1。GC日志与监控-XX:PrintGCDetails打印详细的GC日志。-XX:PrintGCDateStamps/-XX:PrintGCTimeStamps在GC日志中增加时间戳。-Xloggc:file将GC日志输出到文件。使用jstat、jmap、jstack等命令行工具或VisualVM、JProfiler、Arthas等图形化/命令行工具进行实时监控和分析。收集器选择吞吐量优先并行处理、科学计算任务。可选用-XX:UseParallelGCParallel Scavenge Parallel OldJDK 8默认或-XX:UseG1GCG1JDK 9默认并调整目标吞吐量参数。低延迟优先Web服务、GUI应用。可选用-XX:UseConcMarkSweepGCParNew CMSJDK 8及之前或-XX:UseG1GC并设置最大停顿时间目标-XX:MaxGCPauseMillis。调优基本步骤监控分析首先通过GC日志和监控工具了解应用的GC频率、各代内存占用、停顿时间等现状。确定目标明确调优目标是降低延迟减少GC停顿时间还是提高吞吐量增加业务处理时间占比。参数调整根据目标和监控数据有方向地调整参数。例如若频繁Minor GC且对象存活率高可尝试增大新生代若Full GC频繁检查是老年代过小还是存在内存泄漏。对比验证每次只调整1-2个关键参数进行压测对比观察效果。调优是一个迭代和权衡的过程。6. 常见问题排查与实战经验在实际开发和运维中你会遇到各种各样与GC相关的问题。这里分享几个典型场景和排查思路。6.1 CPU占用过高排查现象服务器CPU使用率长时间接近100%应用响应变慢。排查思路使用top命令找到CPU占用最高的Java进程PID。使用top -Hp [PID]查看该进程下所有线程的CPU占用情况。将占用最高的线程ID转换为16进制printf “%x\n” [TID]。使用jstack [PID] stack.log导出线程堆栈信息。在stack.log中搜索刚刚转换的16进制线程ID找到对应的线程堆栈。可能原因GC线程繁忙如果高CPU线程是VM Thread或GC task thread说明垃圾回收非常频繁可能是内存设置过小或存在内存泄漏导致GC线程不断尝试回收内存。此时需要结合GC日志分析。业务线程死循环如果是业务线程检查堆栈中是否在执行某个循环或阻塞操作。6.2 频繁Full GC与内存泄漏定位现象GC日志显示Full GC发生极其频繁甚至几分钟一次且每次Full GC后老年代内存回收效果甚微使用率居高不下。排查步骤确认现象通过jstat -gcutil [PID] 1000每秒打印一次GC情况观察老年代O使用率是否在每次Full GC后只下降一点点然后很快又涨回去。生成堆转储在问题发生时使用jmap -dump:live,formatb,fileheap.hprof [PID]命令生成堆内存快照Heap Dump。注意此命令会触发Full GC生产环境慎用或在低峰期操作。分析堆转储使用MATMemory Analyzer Tool、JProfiler或VisualVM加载heap.hprof文件。寻找嫌疑对象查看Histogram直方图按对象数量或占用内存大小排序找到占比异常大的类。使用Dominator Tree支配树找到那些持有大量内存的GC Roots路径。重点检查无法被回收的集合类如HashMap、ArrayList、缓存、静态集合、线程局部变量ThreadLocal等常见的内存泄漏源头。结合代码根据分析工具提供的线索定位到具体的业务代码检查对象的生命周期管理是否有误例如对象被放入全局静态Map后从未移除。6.3 应用长时间停顿Stop-The-World分析现象应用偶尔会出现长达数秒甚至数十秒的完全卡顿。可能原因及排查Full GC导致这是最常见的原因。检查GC日志确认停顿时间是否与Full GC时间吻合。如果是则按上述“频繁Full GC”的思路排查。元空间Metaspace溢出如果永久代/元空间设置过小或存在类加载器泄漏如频繁动态生成类且不卸载会导致Full GC并卸载类可能引起长时间停顿。监控元空间使用情况jstat -gcutil中的M列适当调大-XX:MetaspaceSize和-XX:MaxMetaspaceSize。大对象分配失败尝试分配一个超大对象如大数组老年代没有足够连续空间容纳即使触发Full GC也无法回收出足够空间会导致分配失败和长时间停顿。考虑优化代码避免一次性分配超大内存。System.gc()调用代码中显式调用了System.gc()可能会触发一次全堆回收造成不可控的停顿。可以通过JVM参数-XX:DisableExplicitGC来禁止显式GC调用但需注意某些NIO框架如Netty会依赖此调用管理堆外内存需谨慎。6.4 新生代参数设置不当的典型症状症状Minor GC非常频繁但每次回收后存活对象很少。可能原因新生代特别是Eden区设置过小导致新对象很快占满频繁触发GC。调整适当增大-Xmn新生代大小或调整-XX:SurvivorRatio增大Eden区比例。但要注意增大新生代会挤占老年代空间。症状Minor GC后有大量对象晋升到老年代导致老年代快速增长频繁触发Full GC。可能原因Survivor区空间不足或者-XX:MaxTenuringThreshold设置过小。调整增大Survivor区调整-XX:SurvivorRatio减小比值或适当增大晋升年龄阈值让对象在新生代多“熬”几次GC充分释放短生命周期对象。理解JVM垃圾回收是一个从理论到实践再从实践反馈加深理论理解的过程。它没有一成不变的最优解最好的调优策略永远是贴合你的具体应用负载、硬件环境和性能目标的那一个。从看懂GC日志开始结合监控工具大胆假设、小心验证你就能逐渐掌控这门“内存管理的艺术”。 
长河君 · 2026/8/15 4:50:32 · 阅读 1.2k 深入解析JVM垃圾回收：从算法原理到性能调优实战
1. 项目概述深入JVM垃圾回收的底层世界在Java开发的世界里JVMJava虚拟机就像一位不知疲倦的管家默默打理着程序运行过程中产生的“垃圾”——那些不再被使用的对象。很多开发者尤其是刚入行的朋友对JVM的了解可能停留在“它会自动回收内存”这个模糊的概念上。但当你开始面对高并发场景下的性能瓶颈或者准备一场严肃的技术面试时你会发现对垃圾回收Garbage Collection, GC机制的深入理解是从“会用Java”到“懂Java”的关键分水岭。最近在社区和面试准备中关于JVM垃圾回收算法、机制以及调优的话题热度一直居高不下从基础的“标记-清除”到复杂的调优参数都成了必须啃下的硬骨头。这篇文章我们就来彻底拆解JVM的四种经典垃圾回收算法并理清其背后的工作机制。这不仅仅是应付面试题的背诵更是为了让你在遇到“应用卡顿”、“内存泄漏”甚至“服务崩溃”时能有一个清晰的排查思路。我们会从最基础的算法原理讲起结合内存布局一步步看到它们是如何在JVM中协作最终构成完整的垃圾回收机制的。无论你是正在准备面试还是希望优化自己的应用性能这些内容都将提供直接的帮助。2. JVM内存布局与垃圾回收的基石要理解垃圾回收算法首先得知道垃圾在哪里以及JVM是如何管理内存的。JVM的内存区域划分是垃圾回收活动发生的舞台。2.1 核心内存区域解析JVM运行时数据区主要分为线程共享和线程私有两大类。对于垃圾回收而言我们重点关注线程共享区域尤其是堆Heap。堆Heap这是垃圾回收的主战场几乎所有对象实例和数组都在这里分配内存。堆也是GC管理的主要区域。为了更高效地进行垃圾回收堆空间通常被进一步细分新生代Young Generation绝大多数新创建的对象首先在这里分配。新生代的特点是“朝生夕死”大部分对象很快变得不可达。因此新生代的垃圾回收称为Minor GC或Young GC发生非常频繁但速度也要求很快。新生代内部又通常划分为一个Eden区和两个Survivor区通常称为S0和S1或者From和To。老年代Old Generation/Tenured Generation在新生代中经历了多次垃圾回收后仍然存活的对象会被晋升Promote到老年代。此外一些大对象也可能直接分配在老年代。老年代的对象生命周期较长因此针对老年代的垃圾回收称为Major GC或Full GC发生频率较低但一旦发生耗时通常较长对应用停顿的影响也更大。方法区Method Area用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码缓存等数据。在HotSpot虚拟机中方法区的具体实现被称为“永久代”JDK 7及之前或“元空间”JDK 8及之后。这个区域也会发生垃圾回收主要是针对废弃的常量和不再使用的类但条件苛刻回收效率低。虚拟机栈、本地方法栈、程序计数器这些是线程私有的区域其生命周期与线程相同。栈帧随着方法调用而创建方法结束而销毁内存的分配和回收具备确定性因此不属于垃圾回收管理的范畴。2.2 对象存亡的判定如何定义“垃圾”在回收之前必须明确哪些对象是“垃圾”即不再被任何地方引用的对象。JVM主要使用两种算法来判定对象存亡引用计数算法在对象中添加一个引用计数器每当有一个地方引用它时计数器加1当引用失效时计数器减1。任何时刻计数器为0的对象就是不可能再被使用的。这个方法实现简单判定效率高但它有一个致命的缺陷无法解决对象之间循环引用的问题。例如对象A和对象B互相引用除此之外再无其他引用实际上它们已经无法被访问但它们的引用计数都不为0导致无法被回收。因此主流的Java虚拟机都没有选用引用计数算法来管理堆内存。可达性分析算法这是当前主流JVM使用的算法。它的基本思路是通过一系列称为“GC Roots”的根对象作为起始节点集从这些节点开始根据引用关系向下搜索搜索过程所走过的路径称为“引用链”。如果某个对象到GC Roots间没有任何引用链相连则证明此对象是不可能再被使用的。那么哪些对象可以作为GC Roots呢主要包括以下几种在虚拟机栈栈帧中的本地变量表中引用的对象例如当前正在运行的方法中的参数、局部变量等。在方法区中类静态属性引用的对象例如Java类的引用类型静态变量。在方法区中常量引用的对象例如字符串常量池里的引用。在本地方法栈中JNI即Native方法引用的对象。Java虚拟机内部的引用如基本数据类型对应的Class对象一些常驻的异常对象等。所有被同步锁synchronized关键字持有的对象。可达性分析算法有效地解决了循环引用的问题是垃圾回收器工作的理论基础。3. 四种经典垃圾回收算法深度剖析垃圾回收算法是方法论它定义了如何找到垃圾并回收内存空间。下面我们深入每一种算法的内部。3.1 标记-清除算法这是最基础、最直观的垃圾收集算法分为“标记”和“清除”两个阶段。标记阶段首先通过可达性分析遍历所有GC Roots标记出所有存活的对象。清除阶段再次遍历整个堆回收所有未被标记的对象所占用的内存。优点原理简单是后续很多算法的基础思想。缺点也非常明显执行效率不稳定标记和清除两个过程的效率都会随着堆中对象数量的增长而下降。内存空间碎片化标记清除后会产生大量不连续的内存碎片。当程序以后需要分配一个较大对象时可能无法找到足够的连续内存从而不得不提前触发另一次垃圾收集。注意你可以把堆内存想象成一个巨大的棋盘。标记-清除算法就像把棋盘上还有用的棋子存活对象标记出来然后把所有没标记的空白格子垃圾对象清空。问题是清空后的空白格子是散乱分布的当你想放一个需要连续3个格子的“大棋子”时可能找不到一排连续的3个空位尽管总的空位数量是够的。这就是内存碎片。3.2 复制算法为了解决标记-清除算法面对大量可回收对象时的效率问题和碎片问题复制算法出现了。它将可用内存按容量划分为大小相等的两块每次只使用其中的一块。工作流程当正在使用的那块内存称为From空间用尽时就启动垃圾回收。将From空间中所有存活的对象复制到另一块空闲的内存称为To空间上。复制完成后清空整个From空间。最后将From空间和To空间的角色交换。下次垃圾回收时新的From空间即原来的To空间重复此过程。优点高效对于存活对象比例较低的新生代每次只需要复制少量存活对象效率很高。无碎片每次复制后存活对象都被紧凑地排列在To空间的一端解决了内存碎片化问题。分配新对象时只需要移动堆顶指针速度极快这种分配方式称为“指针碰撞”。缺点内存代价高昂可用的内存空间直接被缩小为原来的一半空间利用率低。对象存活率高时效率低下如果绝大多数对象都是存活的那么复制的开销会变得非常大。正因为这些特点复制算法非常适合“朝生夕死”的新生代。在实际的JVM实现中并不需要按照1:1的比例来划分新生代空间。HotSpot虚拟机默认的Eden和Survivor区大小比例是8:1:1即每次新生代中可用内存空间为整个新生代容量的90%Eden 一个Survivor只有10%的空间会被“浪费”。当回收时将Eden和From Survivor中存活的对象一次性复制到To Survivor区然后清理掉Eden和From Survivor。这样只有10%的空间是闲置的提高了内存利用率。3.3 标记-整理算法复制算法在对象存活率高时要进行较多的复制操作效率会降低。更关键的是如果不想浪费50%的空间就需要有额外的空间进行分配担保以应对所有对象都存活的极端情况。所以在老年代这种对象存活率高的区域一般不能直接选用复制算法。标记-整理算法应运而生其标记过程与“标记-清除”算法一样但后续步骤不是直接清除而是让所有存活的对象都向内存空间的一端移动然后直接清理掉边界以外的内存。优点无内存碎片整理后存活对象占据内存的一端空闲内存集中在另一端是连续的空间。空间利用率高无需像复制算法那样预留一半空间。缺点效率问题移动存活对象并更新所有引用这些对象的指针是一个开销较大的操作而且这种移动操作必须全程暂停用户应用程序即“Stop The World”延迟会比标记-清除算法更高。3.4 分代收集算法当前商业虚拟机的垃圾收集器几乎都采用了分代收集算法。它并非一种全新的算法而是上述三种基础算法的组合运用其核心思想是根据对象存活周期的不同将堆内存划分为几块主要是新生代和老年代然后根据各个年代的特点采用最适合的垃圾收集算法。在新生代中对象的特点是“朝生夕死”每次垃圾回收时都有大量对象死去只有少量存活。因此复制算法是最佳选择只需要付出少量存活对象的复制成本且回收后内存排列整齐分配高效。在老年代中对象存活率高没有额外的空间对它进行分配担保。因此通常采用标记-清除或标记-整理算法进行回收。标记-清除CMS收集器在并发标记阶段使用以减少停顿时间但会产生碎片。标记-整理Parallel Old和G1等收集器使用避免碎片但停顿时间可能稍长。分代收集算法是理论与实践结合的完美典范它通过差异化的策略在整体上达到了时间回收效率和空间内存利用率的平衡。4. 垃圾回收机制与经典收集器实现算法是理论而垃圾收集器是算法的具体实现。HotSpot JVM提供了多种收集器适用于不同的应用场景。4.1 垃圾收集器分类与组合关系垃圾收集器可以按照不同维度分类按线程数可分为串行收集器单线程和并行收集器多线程。按工作模式可分为并发收集器垃圾回收线程与用户线程大部分时间同时工作和独占式收集器垃圾回收时需完全暂停用户线程即Stop-The-World。按处理内存区间可分为新生代收集器和老年代收集器。在JDK 8及之前HotSpot虚拟机中常见的收集器组合如下表所示虚线表示已废弃实线表示常用组合新生代收集器老年代收集器组合说明SerialSerial Old客户端模式下的默认组合简单高效。SerialCMS不常见CMS通常与ParNew配合。ParNewCMS服务端模式下常见的组合追求低停顿。ParNewSerial Old不常见备用方案。Parallel ScavengeParallel OldJDK 8服务端模式默认组合追求高吞吐量。Parallel ScavengeSerial OldParallel Scavenge的备用老年代方案。G1G1JDK 9及之后的默认全堆收集器不分新生代老年代。4.2 经典收集器工作原理简述Serial / Serial Old收集器特点单线程工作的收集器。进行垃圾回收时必须暂停所有其他工作线程Stop The World直到收集结束。应用Serial用于新生代采用复制算法Serial Old用于老年代采用标记-整理算法。它们是虚拟机在客户端模式下的默认收集器简单而高效对于内存不大、单核处理器的环境没有线程交互开销专心做垃圾回收效率很高。ParNew收集器特点本质上是Serial收集器的多线程并行版本除了使用多条线程进行垃圾收集外其余行为与Serial完全一致。应用新生代收集器复制算法。它是许多运行在服务端模式下的虚拟机中首选的新生代收集器一个重要原因是除了Serial只有它能与CMS收集器配合工作。Parallel Scavenge / Parallel Old收集器特点吞吐量优先收集器。目标是达到一个可控制的吞吐量。吞吐量 运行用户代码时间 / (运行用户代码时间 垃圾收集时间)。Parallel Scavenge用于新生代复制算法Parallel Old用于老年代标记-整理算法。应用JDK 8服务端模式的默认组合。适合后台运算、科学计算等不需要太多交互、关注任务尽快完成的应用。CMS收集器特点低停顿优先的收集器以获取最短回收停顿时间为目标。它允许垃圾收集线程与用户线程并发工作。工作流程比前几种复杂初始标记Stop The World仅标记GC Roots能直接关联到的对象速度很快。并发标记与用户线程并发从GC Roots开始进行可达性分析标记所有存活对象。耗时较长。重新标记Stop The World修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。比初始标记长但远比并发标记短。并发清除与用户线程并发清除死亡对象。缺点对处理器资源敏感无法处理“浮动垃圾”采用标记-清除算法会产生内存碎片。G1收集器特点面向服务端应用的垃圾收集器是JDK 9及之后的默认收集器。它开创了基于Region的堆内存布局和可预测的停顿时间模型。核心思想将整个Java堆划分为多个大小相等的独立区域Region虽然还保留新生代和老年代的概念但已不再是物理隔离而是一系列Region的集合。G1跟踪各个Region的垃圾堆积“价值”大小即回收所获得的空间大小以及回收所需时间的经验值在后台维护一个优先列表每次根据允许的收集时间优先回收价值最大的Region。优点可以指定最大垃圾收集停顿时间从整体看是基于标记-整理算法从局部两个Region之间看是基于复制算法都不会产生内存碎片。5. 内存分配、回收策略与调优核心理解了算法和收集器我们来看看对象在堆中是如何“走完一生”的以及我们如何干预这个过程。5.1 对象的内存分配与晋升对象的内存分配往大方向讲就是在堆上分配。但细节上主要分配在新生代的Eden区。如果启动了本地线程分配缓冲TLAB则会优先在TLAB上分配。少数情况下也可能直接分配在老年代。对象优先在Eden分配大多数情况下对象在新生代Eden区中分配。当Eden区没有足够空间时虚拟机将发起一次Minor GC。大对象直接进入老年代大对象如很长的字符串或元素数量庞大的数组需要大量连续内存空间容易导致提前触发垃圾收集。虚拟机提供了-XX:PretenureSizeThreshold参数令大于此阈值的对象直接在老年代分配避免在Eden和Survivor区之间来回复制。长期存活的对象将进入老年代虚拟机给每个对象定义了一个对象年龄计数器。对象在Eden出生并经过第一次Minor GC后仍然存活并且能被Survivor容纳则被移动到Survivor区年龄设为1。对象在Survivor区中每“熬过”一次Minor GC年龄就增加1岁。当年龄增加到一定程度默认15岁可通过-XX:MaxTenuringThreshold设置就会被晋升到老年代。动态对象年龄判定为了能更好地适应不同程序的内存状况虚拟机并不总是要求对象年龄必须达到MaxTenuringThreshold才能晋升。如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半年龄大于或等于该年龄的对象就可以直接进入老年代。5.2 空间分配担保与Full GC在发生Minor GC之前虚拟机必须先检查老年代最大可用的连续空间是否大于新生代所有对象总空间。如果这个条件成立那么Minor GC可以确保是安全的。如果不成立虚拟机会查看-XX:HandlePromotionFailure参数的设置JDK 6 Update 24之后规则有变此参数不再影响策略。当前的策略是只要老年代的连续空间大于新生代对象总大小或者历次晋升到老年代对象的平均大小就会进行Minor GC否则将进行Full GC。实操心得频繁的Full GC往往是性能问题的直接表现。你可以通过GC日志添加JVM参数-XX:PrintGCDetails来观察。如果发现每次Minor GC后老年代的使用率都有显著且异常的增长或者频繁触发“Allocation Failure”导致Full GC就需要警惕了。这可能意味着存在内存泄漏对象无法被回收或者新生代Survivor区太小/晋升年龄阈值太低导致“短命”对象过早进入老年代最终引发老年代过早被填满。5.3 关键JVM参数与调优思路调优没有银弹必须结合具体应用场景。以下是一些核心参数和思路堆内存相关-Xms/-Xmx设置堆的初始大小和最大大小。通常设为相同值避免堆动态扩容收缩带来的性能损耗。-Xmn设置新生代大小。增大新生代能减少Minor GC频率但会缩小老年代可能增加Full GC风险。需要权衡。-XX:NewRatio设置老年代与新生代的比例默认2即老年代:新生代2:1。-XX:SurvivorRatio设置Eden区与一个Survivor区的比例默认8即Eden:Survivor8:1。GC日志与监控-XX:PrintGCDetails打印详细的GC日志。-XX:PrintGCDateStamps/-XX:PrintGCTimeStamps在GC日志中增加时间戳。-Xloggc:file将GC日志输出到文件。使用jstat、jmap、jstack等命令行工具或VisualVM、JProfiler、Arthas等图形化/命令行工具进行实时监控和分析。收集器选择吞吐量优先并行处理、科学计算任务。可选用-XX:UseParallelGCParallel Scavenge Parallel OldJDK 8默认或-XX:UseG1GCG1JDK 9默认并调整目标吞吐量参数。低延迟优先Web服务、GUI应用。可选用-XX:UseConcMarkSweepGCParNew CMSJDK 8及之前或-XX:UseG1GC并设置最大停顿时间目标-XX:MaxGCPauseMillis。调优基本步骤监控分析首先通过GC日志和监控工具了解应用的GC频率、各代内存占用、停顿时间等现状。确定目标明确调优目标是降低延迟减少GC停顿时间还是提高吞吐量增加业务处理时间占比。参数调整根据目标和监控数据有方向地调整参数。例如若频繁Minor GC且对象存活率高可尝试增大新生代若Full GC频繁检查是老年代过小还是存在内存泄漏。对比验证每次只调整1-2个关键参数进行压测对比观察效果。调优是一个迭代和权衡的过程。6. 常见问题排查与实战经验在实际开发和运维中你会遇到各种各样与GC相关的问题。这里分享几个典型场景和排查思路。6.1 CPU占用过高排查现象服务器CPU使用率长时间接近100%应用响应变慢。排查思路使用top命令找到CPU占用最高的Java进程PID。使用top -Hp [PID]查看该进程下所有线程的CPU占用情况。将占用最高的线程ID转换为16进制printf “%x\n” [TID]。使用jstack [PID] stack.log导出线程堆栈信息。在stack.log中搜索刚刚转换的16进制线程ID找到对应的线程堆栈。可能原因GC线程繁忙如果高CPU线程是VM Thread或GC task thread说明垃圾回收非常频繁可能是内存设置过小或存在内存泄漏导致GC线程不断尝试回收内存。此时需要结合GC日志分析。业务线程死循环如果是业务线程检查堆栈中是否在执行某个循环或阻塞操作。6.2 频繁Full GC与内存泄漏定位现象GC日志显示Full GC发生极其频繁甚至几分钟一次且每次Full GC后老年代内存回收效果甚微使用率居高不下。排查步骤确认现象通过jstat -gcutil [PID] 1000每秒打印一次GC情况观察老年代O使用率是否在每次Full GC后只下降一点点然后很快又涨回去。生成堆转储在问题发生时使用jmap -dump:live,formatb,fileheap.hprof [PID]命令生成堆内存快照Heap Dump。注意此命令会触发Full GC生产环境慎用或在低峰期操作。分析堆转储使用MATMemory Analyzer Tool、JProfiler或VisualVM加载heap.hprof文件。寻找嫌疑对象查看Histogram直方图按对象数量或占用内存大小排序找到占比异常大的类。使用Dominator Tree支配树找到那些持有大量内存的GC Roots路径。重点检查无法被回收的集合类如HashMap、ArrayList、缓存、静态集合、线程局部变量ThreadLocal等常见的内存泄漏源头。结合代码根据分析工具提供的线索定位到具体的业务代码检查对象的生命周期管理是否有误例如对象被放入全局静态Map后从未移除。6.3 应用长时间停顿Stop-The-World分析现象应用偶尔会出现长达数秒甚至数十秒的完全卡顿。可能原因及排查Full GC导致这是最常见的原因。检查GC日志确认停顿时间是否与Full GC时间吻合。如果是则按上述“频繁Full GC”的思路排查。元空间Metaspace溢出如果永久代/元空间设置过小或存在类加载器泄漏如频繁动态生成类且不卸载会导致Full GC并卸载类可能引起长时间停顿。监控元空间使用情况jstat -gcutil中的M列适当调大-XX:MetaspaceSize和-XX:MaxMetaspaceSize。大对象分配失败尝试分配一个超大对象如大数组老年代没有足够连续空间容纳即使触发Full GC也无法回收出足够空间会导致分配失败和长时间停顿。考虑优化代码避免一次性分配超大内存。System.gc()调用代码中显式调用了System.gc()可能会触发一次全堆回收造成不可控的停顿。可以通过JVM参数-XX:DisableExplicitGC来禁止显式GC调用但需注意某些NIO框架如Netty会依赖此调用管理堆外内存需谨慎。6.4 新生代参数设置不当的典型症状症状Minor GC非常频繁但每次回收后存活对象很少。可能原因新生代特别是Eden区设置过小导致新对象很快占满频繁触发GC。调整适当增大-Xmn新生代大小或调整-XX:SurvivorRatio增大Eden区比例。但要注意增大新生代会挤占老年代空间。症状Minor GC后有大量对象晋升到老年代导致老年代快速增长频繁触发Full GC。可能原因Survivor区空间不足或者-XX:MaxTenuringThreshold设置过小。调整增大Survivor区调整-XX:SurvivorRatio减小比值或适当增大晋升年龄阈值让对象在新生代多“熬”几次GC充分释放短生命周期对象。理解JVM垃圾回收是一个从理论到实践再从实践反馈加深理论理解的过程。它没有一成不变的最优解最好的调优策略永远是贴合你的具体应用负载、硬件环境和性能目标的那一个。从看懂GC日志开始结合监控工具大胆假设、小心验证你就能逐渐掌控这门“内存管理的艺术”。