★ FEATURED ARTICLE 做后端开发和底层基础设施这些年我几乎每次排查线上性能问题最后都会绕回同一个话题垃圾回收机制。不管你是写Java、Go、Python还是Rust只要用了带GC的运行时垃圾回收机制就决定了你的应用能扛多大流量、峰值时会不会突然卡顿甚至决定了你年底运维汇报时是“稳定运行”还是“频繁优化”。很多人对GC的印象停留在“自动管理内存不用手动释放”这句话上但真到线上出了问题调优无从下手日志看不懂参数不敢动最后只能重启大法。这篇博文我就把这个话题彻底拆开讲透覆盖核心算法、分代思想、并发标记、参数调优和实战排障目标是不管你偏应用开发还是偏系统底层读完都能对GC有一套自己的分析框架。1. 垃圾回收机制到底在解决什么问题1.1 内存管理的前世手动分配与释放在GC出现之前程序内存需要开发者手动管理。C语言里malloc对应freeC里new对应delete听起来很直接但代价极高。你不仅要记住每块内存是在哪个分支、哪个函数里分配的还要保证所有退出路径上都正确释放哪怕异常提前返回、循环提前break漏一次就是内存泄漏多释放一次就是野指针和崩溃。我早期维护过一个用C写的网关模块线上跑了两个月后内存翻了三倍查了很久才发现是某个超时分支里少写了一个释放语句。这类问题极难复现因为触发条件是特定时序下才会走的冷门路径。手动内存管理最大的问题不是“难”而是“不可持续”——模块越多、业务越复杂人对内存生命周期的把控就越不可靠。垃圾回收机制解决的就是这个根本矛盾把“内存什么时候释放”从开发者手里收回来交给运行时自动判断。代价是牺牲一部分CPU和停顿时间换取开发效率和稳定性。用一句话概括GC就是用确定的、可控的性能开销换取程序内存安全的确定性。1.2 垃圾回收的核心判断标准对象到底“死没死”GC要回收内存第一件事是判定哪些对象是“垃圾”。这个判定标准不能靠名称、不能靠大小只能靠“可达性”。一个对象只要还能被当前存活的对象、寄存器、栈帧中的局部变量等方式引用到它就不是垃圾反过来从根集合出发遍历所有引用链遍历不到的对象就是垃圾可以回收。根集合具体包括哪些东西线程栈上的局部变量、静态变量引用、JNI句柄、当前正在执行的方法参数等。这里有一个容易忽略的点被局部变量引用的对象并不一定在整个方法执行期间都“存活”。JVM有栈上分配和标量替换优化某些对象甚至不会真正在堆上创建。理解可达性分析是后续理解三色标记、分代回收、GC Roots遍历的基础。还有一个经常被误解的概念引用计数不等于可达性分析。Python的GC用引用计数为主当一个对象的引用计数降为0时立即回收但引用计数解决不了循环引用问题所以Python还需要额外的标记-清除和分代收集来兜底。这也是为什么“GC”在工程上是一整套机制的统称而不是某个单一算法。2. 三大基础算法的原理拆解与适用场景2.1 标记-清除最简单也最“暴力”的方案标记-清除算法分两个阶段先遍历所有可达对象把存活对象做上标记再遍历整个内存区域把未标记的对象内存回收。听起来简单但它在两个硬伤。第一个硬伤是内存碎片化。回收后的内存是不连续的大量细碎的空闲块散落在堆里。后续分配一个较大的对象时如果没有连续空闲区域即使总空闲空间足够也不得不提前触发另一次GC甚至直接OOM。这就像你家里衣柜腾出了很多空隙但每道空隙只够塞袜子放不下一件大衣。第二个硬伤是标记和清除两个阶段都要全程暂停业务线程也就是Stop-The-WorldSTW。当堆内存越大、存活对象越多的时候全称扫描耗时越长。早期的JVM用这个方案跑小型应用还行放到今天动辄几十GB的堆上一次Full GC停顿几十秒都是有可能的。不过标记-清除的思想是后续所有追踪式GC的基础。正是在它的基础上演进出了复制算法和标记-整理算法分别解决碎片化和STW时间这两个痛点。2.2 复制算法以空间换时间复制算法的核心思路把内存分成大小相等的两块区域每次只使用其中一块。GC发生时把存活对象从当前使用的区域复制到另一块空闲区域然后整块清空原区域。复制过程中对象被紧密排列在新区天然解决了碎片问题。更重要的是复制算法的效率跟存活对象数量成正比而不是跟整个堆大小成正比。对象存活率低的时候需要复制的对象很少效率极高。这特别符合“朝生夕灭”的年轻对象特征——大部分对象创建后很快就变成垃圾。但代价也很明显可用内存缩小了一半。如果存活率很高复制开销会极大而且需要一个额外的空间来容纳复制的对象。正因如此复制算法在工程里几乎不会独立用于老年代而是被嵌入到分代回收里专门服务新生代。2.3 标记-整理兼顾内存利用率与碎片问题标记-整理算法是对标记-清除的改进。标记阶段一样整理阶段不再直接清空垃圾对象而是把存活对象向内存一端移动然后直接清理掉边界以外的整段内存。这样做的好处是一次GC之后存活对象连续紧凑排列新对象分配时可以用指针碰撞的方式快速找到空闲位置。缺点同样来自移动性对象地址变了所有指向这些对象的引用都要同步更新。如果对象被很多地方引用更新引用的开销也不小。而且整理阶段一般仍需要STW老年代一次GC的时间依然可观。到这里你会发现没有哪个算法是全能的。实际工程里的垃圾回收器从来都是组合使用的。新生代用复制老年代用标记-整理或标记-清除再配合分代思想把频率和成本拆开这就是下一节要讲的重点。3. 工程实践中的核心实现分代与并发3.1 分代回收为什么“朝生夕灭”的对象要特殊处理统计了大量应用之后业界得出两个经验规律绝大多数对象存活时间极短比如方法里的临时变量方法栈弹出后立即变成垃圾而存活下来的对象往往会存活更久甚至整个程序生命周期都不消失。有了这两个规律堆内存被划分成新生代和老年代。新生代里对象的GC非常频繁但因为存活对象少复制算法效率极高熬过若干次GC仍然存活的对象年龄逐步增长最终被晋升到老年代老年代的GC频率低用标记-整理或标记-清除来处理。新生代内部还会继续细分比如经典的Eden区和两个Survivor区比例通常是8:1:1。Eden区是大头新对象一律在Eden分配GC时Eden和Survivor中存活的对象被复制到另一个Survivor区并清空Eden和旧Survivor。Survivor区设计两个是为了让复制算法有完整的“目的空间”避免对象被覆盖同时通过Age阈值控制晋升。这里有个实操中常见的坑如果Survivor空间太小存活对象放不下会直接晋升到老年代。大量短命对象进入老年代后老年代很快被塞满导致Full GC频繁。所以新生代的比例不是拍脑袋定的要结合业务对象存活情况观察GC日志调整。3.2 并发标记与三色算法如何不让GC卡住业务分代解决了频率问题但GC过程中的STW仍然是硬伤。为了减少停顿现代垃圾回收器都在追求并发——让GC线程和业务线程尽量同时运行。这里面的核心算法就是三色标记法。三色标记把对象分成三种颜色白色表示尚未访问过、灰色表示自身被访问到但引用到的子对象还没处理完、黑色表示自身和子对象都已处理完。初始时所有对象是白色从根集合开始把所有直接引用的对象置为灰色然后不断从灰色对象中取出一个把它引用的白色对象置灰自己置黑当所有灰色对象都处理完时剩下的白色对象就是不可达对象可以被回收。并发标记最大的难点在于GC线程标记的同时业务线程还在修改引用关系。某个对象被标成黑色后如果业务线程往它身上新挂了一个白色对象而这个黑色对象后续不会再被扫描那个新挂的对象就会因为“漏标”被错误回收引发严重的内存安全问题。解决方案要么是写屏障在引用被修改时记录信息然后重新标记增量要么是原始快照遍历开始时保存对象引用图的快照新产生的引用后续再找出来处理。工程回收器具体用哪种方案各有取舍这也是不同垃圾回收器行为差异的重要来源。3.3 实现语言差异对比引用计数 vs 追踪式很多初学者会问Java的GC和Python的GC能不能用一套参数调答案是不能。Java的HotSpot虚拟机采用的是追踪式垃圾回收核心就是可达性分析加分代收集Python则默认以引用计数为主每个对象被引用时计数加一解除引用时计数减一计数归零就立即回收内存。引用计数的优势是实时性好没有周期性STW内存能立刻释放。缺点也很致命循环引用会让引用计数永远不为0导致内存泄漏。比如两个对象互相引用外部引用又被切断后它们彼此持有对方计数都归不了零。所以Python还要在引用计数之上叠加一个循环检测器定期扫描容器对象找出循环引用并解除。这也意味着Python的GC机制是两层结构的底层的即时回收加周期性的收集循环。Go的GC又是另一套思路它采用并发的标记-清除回收器不进行分代。Go更强调低延迟牺牲了一部分吞吐量换取了可预期的微秒级或毫秒级停顿。所以不同语言的GC设计背后都是对吞吐量、延迟、内存占用这三点的取舍没有绝对的好坏只有适不适合你的业务场景。4. 垃圾回收调优与实战参数4.1 关键参数的选择逻辑调GC参数之前必须先问一个问题你的业务的瓶颈到底是吞吐量还是延迟批处理任务希望单位时间处理更多请求能忍受偶尔的长停顿在线交易系统恰恰相反宁可整体吞吐量稍微降一点也要保证单次请求延迟可控。Java虚拟机中不同的垃圾回收器本质上是对吞吐和延迟的不同权衡。比如Parallel Scavenge追求高吞吐适合后台计算任务CMS和G1追求低停顿适合交互式应用ZGC更进一步把停顿时间控制在极短范围内适合大堆低延迟场景。选GC器不是选“最新的”而是选“最匹配的”。常用参数里新生代大小、堆大小、晋升阈值、GC触发比例是最核心的四个。堆大小决定了GC的频率和单次耗时新生代越大短命对象在新生代内被回收的概率越高晋升到老年代的垃圾就越少晋升阈值决定了对象要熬过多少次GC才进老年代。这些参数相互耦合调一个往往影响另一个所以每次调优只动一个变量通过对比GC日志确认效果再渐进调整。实操中最稳的做法是先不加任何参数跑一段时间的业务收集完整GC日志作为基线。然后针对日志里的规律做小幅度调整。很多线上事故都是“调优”调出来的盲目抄网上配置堆大小设置不合业务场景反而导致GC更频繁。4.2 停顿时间与吞吐量的权衡调优之前理解两个核心指标很重要平均GC停顿时间Average GC Pause和吞吐量Throughput。吞吐量的定义是应用运行时间除以应用运行时间加GC总时间。如果一个应用运行了100秒GC花了1秒吞吐量就是99%。这两者是典型的跷跷板关系。要缩短单次停顿时间一个直观办法是缩小堆因为堆越小扫描越快但堆小了GC就更频繁总GC时间上升吞吐量反而下降。要提升吞吐量可以放大堆减少GC次数但每次GC的停顿又更长。所以调优本质上是在同一条曲线上找一个业务能接受的点并不是某个参数越大越好。举个例子某数据统计服务把堆从4GB调大到16GB后Full GC次数从每小时30次降到每小时2次吞吐量明显提升但每次Full GC停顿从40毫秒涨到350毫秒。批处理场景完全无感因为停顿不感知但如果这是一条支付链路的核心节点350毫秒的停顿就不可接受。所以我常说调优的目标是“刚刚好”不是“最好”。5. 常见问题排查与避坑实录5.1 内存泄漏GC看着正常内存却持续上涨内存泄漏不等于内存疯狂增长。很多时候GC日志里回收都很正常但堆占用还是缓慢往上爬每天涨一点一周后触发OOM。这种问题最隐蔽因为根集合里一直有对象引用着它们GC永远认为它们是存活的。典型的泄漏场景包括静态集合类缓存了对象但没清、监听器注册了没注销、线程池上下文对象被误持有、数据库连接没关闭导致连接对象被长期引用。排查思路不能靠猜要周期性打印堆转储文件用内存分析工具对比快照找出哪些对象实例数量异常增长再顺着引用链定位到持有者。我印象很深的一个案例是某个定时任务框架频繁创建新的调度器实例旧实例被全局注册表引用无法释放堆里积累了上万份副本。从GC参数角度怎么调都无效真正的解法是修正生命周期管理逻辑。所以在遇到内存增长问题时永远先排查逻辑层面的持有关系再去碰GC参数。5.2 GC停顿超时STW太长的排查思路Full GC单次停顿超过数秒通常是老年代里存活对象太多标记或整理阶段要处理大量对象。查看GC日志时注意两个信息老年代已使用空间在GC前后的变化以及停顿时间分布。如果老年代占用常年很高说明晋升量超出了预期要么是存活的业务对象确实太多要么是Survivor区太小导致短期对象被提前晋升。另一个高频原因是堆外内存和元空间压力。很多人只盯着堆却忽略了直接内存和元数据区。某些框架大量使用堆外内存做缓存元空间加载了过多类这些区域满了也会触发全局GC甚至进程退出。排查时不要只裁剪堆参数还要看JVM启动参数里元空间上限、直接内存容量是否合理。这里分享一个排查技巧给垃圾回收器开启详细日志记录每次GC前后的各区域占用、停顿原因和耗时。对比多次GC日志找出触发规律。很多看似随机的问题在日志里会呈现明显的周期性或与特定业务操作关联。有了数据支撑才能定性地判断是参数问题、代码问题还是外部依赖问题。5.3 高并发场景下的分配压力与GC频率在高并发场景下每秒都会创建海量临时对象GC线程几乎停不下来应用吞吐被大幅拖垮。这类问题的根源通常不在GC参数而在代码侧的分配行为。例如循环体内频繁拼接字符串、大量使用包装类型、不必要的事件对象反复创建这些都会直接抬高分配速率。解决思路有三层。最低层的是优化代码减少对象分配比如使用基本类型代替包装类型、复用缓冲区、使用字符串构建器代替字符串拼接。中间层是调整参数适当增大新生代让短命对象在新生代内完成回收减少晋升。最高层是使用TLAB、栈上分配、标量替换等运行时优化让一部分对象根本不进入堆直接在线程栈上“消灭”掉。还有一个容易被忽略的点业务线程数目越多GC线程调度和内存竞争越剧烈。线程数设置为CPU核心数的数倍分配压力会成倍放大。高并发应用的线程池大小最好经过压测验证不是越大越好。压测时使用GC日志分析工具观察分配速率和GC频率可以比较直观地定位到是代码分配问题还是参数不匹配问题。5.4 常见问题速查表问题现象常见原因排查方向与建议GC日志显示Old区持续增长频繁Full GC短命对象晋升过多、内存泄漏查看Survivor区容量与晋升阈值转储堆分析对象引用链单次GC停顿时间超过数秒老年代存活对象太多、堆过大调整堆大小与回收器类型检查元空间和堆外内存占用内存缓慢增长后OOM全局缓存或监听器未释放周期性堆转储对比分析实例数量增长曲线高并发下GC极其频繁临时对象分配速率过高优化代码减少分配适当加大新生代合理设置线程池GC后应用并发度下降明显并发收集器与业务线程竞争加剧调整GC线程数评估停顿时间与吞吐量权衡最后再分享一个原则任何GC调优都必须建立在监控数据之上。没有日志和指标做支撑所有参数改动都只是碰运气。先装好监控收集一周基线数据再针对性调整少量参数每一次改动都能从数据上看到效果排障能力就是这样一步步积累起来的。遇到无法从参数层面解释的堆增长问题时多从代码生命周期管理里找答案那里面藏的问题往往比GC本身更大。
阅读完成 · 觉得有帮助？
