想象你运营着一座大型共享仓库：程序里的对象就像货物，堆空间就是那一排排货架，程序员则是不断往货架上摆放箱子的搬运工。仓库里还有一支垃圾回收（GC）清理队，专门把没人认领的废弃箱子搬走。大多数时候，这套流程运转得平稳顺畅。直到某天，门口排起长队——新箱子放不进去（OOM），清理队加班到爆肝（频繁 GC），角落里还堆着一些红色包裹：没人再用它们，可包裹上仍贴着“重要待领取”的标签，清理队只能绕着走。这就是内存泄漏。 要解决这类问题，你必须学会给仓库“拍快照”：堆转储是某一瞬间的全景照片，分配追踪是门口的包裹登记记录，GC 日志是清理队每天的出工日记。Go 和 Java 各自拥有入仓审计系统：pprof 帮你看 Go 仓库，MAT 帮你看 Java 仓库。本文会用一套统一的“仓库故事”把这些工具串起来，让你从零开始掌握内存分析，快速定位性能瓶颈。

岗位关联

掌握内存分析，是后端工程师从“能跑就行”走向“系统稳定”的必备技能。当线上 OOM 和频繁 GC 出现时，你能在别人手忙脚乱时冷静给出结论。

目录
  1. 可视化演示
  2. 内存管理基础：仓库、操作台与清理队
  3. 问题症状识别：红色包裹与清扫队超载
  4. Go 内存剖析：pprof 的进销存账本
  5. Java 内存剖析：jmap、MAT 与 GC 日志
  6. 瓶颈定位方法：并排照片与引用链
  7. 优化防护体系：从救火到防火
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

对比广度优先搜索与深度优先搜索两种图遍历策略的访问顺序差异，动态展示队列与栈的不同的节点扩展机制。

本节配有交互动效（进入视口后自动加载，约 3KB）。

BFS广度优先搜索 使用队列逐层扩展邻居节点 当前正在访问的节点高亮 Q:FIFO 按层次顺序遍历全图

内存管理基础：仓库、操作台与清理队

把程序运行时想象成一座仓库。每个线程或协程都有一张自己的操作台（栈），上面放着局部变量、临时账本这类用完即扔的东西；而堆是所有人共享的大货架，任何对象都能放在上面，交给运行时统一管理。Go 的 goroutine 和 Java 的线程都有自己的操作台，区别只在于操作台的大小和生命周期。真正的难点在堆：货架多、货物杂，所以必须有一支垃圾回收（GC）清理队。

有了这个画面，再看技术定义就不难了。栈是随函数调用结束自动回收的连续空间；堆里的对象生命周期不受调用栈控制，可能被多处引用。GC 会周期性扫描堆，把不再被引用的对象标记为可回收，再统一腾出货位。Go 采用并发标记清除与混合写屏障，Java 用分代收集（新生代、老年代），本质都是让清理队更聪明地工作。

无论哪种语言，判断仓库健康状况的最直接指标是堆占用率。如果最大堆是 M_{max}，当前已用的是 M_{used}，那么占用率就是二者之比。

仓库有了货架、操作台和清理队，我们心里就有了坐标。下一节我们会看到，当清理队过度加班、新货入不了库，其实已经写满了症状。

堆占用率=MusedMmax\displaystyle \text{堆占用率} = \frac{M_{used}}{M_{max}}
堆占用率接近 1 时，表示仓库接近满仓，GC 随时可能触发，新对象甚至可能分配失败。
  1. 分子 M_used（已用内存）当前仍在货架上占位的对象大小之和，对应 pprof 的 inuse_space 或 Java 的已用堆大小。
    MusedM_{used}
  2. 分母 M_max（最大堆内存）运行时允许占据的最大内存，Java 由 -Xmx 指定，Go 由系统可用内存与 GOGC 动态决定。
    MmaxM_{max}
  3. 比值（占用率）比值越接近 1 说明仓库越满，GC 频率和分配压力越高，是后续所有分析都要盯住的“气压表”。
    MusedMmax\frac{M_{used}}{M_{max}}

问题症状识别：红色包裹与清扫队超载

仓库管理员最先感受到的往往不是哪一箱货有问题，而是整体异常：包裹入库越来越慢、清理队半夜还在加班、门口立起了“仓库已满”的牌子。内存泄漏就是角落里那批贴着“重要待领取”的红色包裹，引用一直存在，业务却再也用不到它；清理队因为包裹上有签收人，只能绕着走。

频繁 GC 是清理队被迫超负荷运转的体现。JVM 和 Go runtime 都有日志，记录清理队每次出工的耗时。如果 GC 暂停占总运行时间比例过大，说明大量 CPU 和停顿被清理动作占用，业务响应自然变慢。更直接的是 OOM（OutOfMemory），它代表仓库彻底放不下新包裹，进程只能崩溃退出。

定量判断清理队负担，看 GC 时间占比就够了：在一段观测窗口内，所有 GC 暂停之和除以总运行时长。

红色包裹不断出现，清扫队就算把灰箱子清得再勤，仓库依然会满。识别症状只是第一步，下一节我们钻进 Go 仓库，看 pprof 如何给每只包裹贴上进货记录。

RGC=TGCTtotal\displaystyle R_{GC} = \frac{T_{GC}}{T_{total}}
R_GC 超过 5% 通常值得关注；超过 20% 时，系统往往已经出现明显的长尾延迟。
  1. 分子 T_GC（GC 暂停总时长）把所有 Young GC、Full GC 或 Go 的 stop-the-world 暂停时间相加，数据来自 GC 日志。
    TGC=∑iΔtiT_{GC} = \sum_{i} \Delta t_{i}
  2. 分母 T_total（总时长）观测窗口的总运行时间，它把暂停摊到整体时间中，避免被单次大停顿误导。
    TtotalT_{total}
  3. 比值 R_GC（GC 时间占比）比例越高，清理队越疲于奔命；若此时堆占用率不高，则多半是分配速率过高，而不是泄漏。
    RGC=TGCTtotalR_{GC} = \frac{T_{GC}}{T_{total}}

Go 内存剖析：pprof 的进销存账本

Go 的运行时内置了一座进销存系统：net/http/pprof。它就像仓库大门口的摄像头加电子秤，能随时调出一张“当前货架占用”的称重单，也能显示从开仓以来总共搬过多少货物。请求 /debug/pprof/heap 会生成一份当前堆快照，这是 pprof 分析的核心入口。

当你发现内存持续上涨，通常要看快照中的 inuse_space，它表示此刻还占着货架的对象，等于仓库现在的实际库存；alloc_space 则是历史累计搬入量，更适合用来找“谁在疯狂生产箱子”，而不是找“谁没被收走”。比如某个 handler 每次请求都生成大数组，alloc_space 会清楚地展示这条高频分配路径。

使用 go tool pprof 载入 heap 快照后，可以用 top 查看占用大户，用 list 或 web 下钻到具体函数。若怀疑泄漏，隔一段时间再采一份快照，计算当前堆占用随时间的增长率。

pprof 是一本动态账本，翻一翻就能让泄漏现形。Java 世界则更像正式的审计事务所——货架照片、引用索引、清理队日记一应俱全，我们下一节去看看。

v=Minuse(t2)−Minuse(t1)t2−t1\displaystyle v = \frac{M_{inuse}(t_2) - M_{inuse}(t_1)}{t_2 - t_1}
v 持续大于 0，且两份快照中同一函数路径的对象数不断增多，这就是泄漏在慢慢胀库的指纹。
  1. M_inuse(t1)、M_inuse(t2)（两次堆快照）在 t1 和 t2 分别执行 heap profile，读出 inuse_space。
    Minuse(t1),Minuse(t2)M_{inuse}(t_1), M_{inuse}(t_2)
  2. Δt（采样时间间隔）为避免瞬时抖动，两次采样通常间隔几分钟到几十分钟，时间差越大，趋势越可信。
    Δt=t2−t1\Delta t = t_2 - t_1
  3. v（增长率）正值表示货架占用在增加；再结合两份快照中对象数量的变化，就能锁定是哪条代码在持续囤货。
    v=ΔMΔtv = \frac{\Delta M}{\Delta t}

Java 内存剖析：jmap、MAT 与 GC 日志

如果说 Go 是装上了监控摄像头的现代化仓库，Java 则更像一座流程规范的物流中心：jmap 负责拍摄 360 度全景照片（堆转储），jstat 是实时仪表盘，GC 日志是清理队每次出工的书面记录，MAT 则是持放大镜的审计师。

内存不对劲时，先用 jps 找到进程，再用 jmap -dump:live,format=b,file=heap.hprof 导出一张当前存活对象的快照。打开 MAT 后，它会给每类对象计算“保留大小”：一个经理对象背后押着整棵下属树，删除它才能释放的最大空间。这种关系通过支配树呈现，能直观看到谁在货架上“占山为王”。

与此同时，打开 -Xlog:gc* 或旧版 -verbose:gc 得到的日志，能看见每次 GC 前多少、后多少、暂停多久。堆转储告诉你谁会占地方，GC 日志告诉你仓库多久清扫一次、每次是否清干净。保留大小的计算是 MAT 最核心的操作。

审计师的报告会告诉你“谁持有谁”，但真正要回答“谁是源头”，还需要把不同时间的仓库照片并排对比。这就是下一节的破案流程。

RetainedSize(X)=Size(X)+∑Y∈subtree(X)Size(Y)\displaystyle \text{RetainedSize}(X) = \text{Size}(X) + \sum_{Y \in \text{subtree}(X)} \text{Size}(Y)
保留大小是所有被 X 支配对象的体积总和。按保留大小降序排列，能立刻看到谁持有整片货架。
  1. Size(X)（对象自身大小）对象头部、字段、数组元素等直接内存开销。
    Size(X)Size(X)
  2. subtree(X)（支配子树）以 X 为支配点的所有后代对象；若 X 被回收，这些后代也大概率会被释放。
    subtree(X)\text{subtree}(X)
  3. 求和（保留大小）把 X 自身与所有被支配对象相加，就得到 X 的保留大小，是 MAT 排序分析的关键指标。
    RetainedSize(X)=Size(X)+∑Size(Y)\text{RetainedSize}(X) = Size(X) + \sum Size(Y)

瓶颈定位方法：并排照片与引用链

内存排查很像破案：一张照片不够，要隔一段时间再拍一张。把两份堆转储或 pprof heap 快照放在一起，逐类对比对象数量与体积。若某类对象数量随请求量等比增长，且一直被强引用，它几乎就是现场唯一在场的可疑包裹。

确定可疑对象后，就要找出谁攥着它的引用。Java 里用 MAT 的 Reference Chain 或支配树查看从 GC Roots 到该对象的路径；Go 里用 pprof 的 list 与 goroutine 状态判断对象由哪个 goroutine 持有。引用链就像包裹上的层层签收条：一直追溯，总能找到某个缓存、全局 map 或没有关闭的 IO 资源。

把线索拼起来，最朴素的证据是：可疑对象的数量随时间单调增长。如果一个集合适用业务 key 不断 insert 却永不 delete，它的项数就会随时间上涨，最终覆盖大片货架。

拍完照片、读完日志、查完签收人，真正的瓶颈通常已经水落石出。最后要做的不是救火，而是给每个仓库装上护栏——优化与防护。

ΔN=N(t2)−N(t1),dΔNdt>0\displaystyle \Delta N = N(t_2) - N(t_1), \quad \frac{d\Delta N}{dt} > 0
对象数量不仅增加，而且增量始终为正，这是“结构性持有”的强线索，不是偶发抖动。
  1. N(t1)、N(t2)（两次快照中的对象数量）分别统计关键类或 Go 类型在两次快照中的实例数。
    N(t1),N(t2)N(t_1), N(t_2)
  2. 增量 ΔN对象数量的变化值，正数说明该类在增加，是可疑对象的必要条件。
    ΔN=N(t2)−N(t1)\Delta N = N(t_2) - N(t_1)
  3. 时间变化率（导数）持续为正说明它不断向货架新增红色包裹，需要沿引用链回溯到写入或缓存逻辑。
    dΔNdt>0\frac{d\Delta N}{dt} > 0

优化防护体系：从救火到防火

一次内存泄漏被定位，只代表这个仓库修好了；真正的高手会建立整套巡检机制。防火措施包括减少不必要的对象、让对象尽快失活、给缓存设置淘汰策略，以及根据业务流量评估堆大小上限。

代码层面，Go 要小心全局 map 无界增长、goroutine 泄漏和闭包捕获大变量；Java 要关注静态集合、ThreadLocal 忘记 remove、连接或流未关闭。工程上，可以把 pprof 和 MAT 分析嵌入 CI 流水线，运行压测后自动生成内存报告，在上线前就拦住红色包裹。

运行时监控同样重要。利用 Go 的 runtime.ReadMemStats 或 Java 的 jstat/Micrometer 定期采集堆使用与 GC 耗时，设置预警、告警、紧急三层阈值。要设置合理阈值，先得知道当前库容上限 M_{max}，并给短期分配洪峰留出余量。

从摸清货架规则、识别症状、用 pprof 和 MAT 破案，到最后建立监控体系，我们已经能对内存瓶颈从容下结论。希望下一次仓库告急时，你能像老练的仓库顾问一样，带着账本和照片直奔案发现场。

Mfree=Mmax−Mused,alert if Mfree<Mthreshold\displaystyle M_{free} = M_{max} - M_{used}, \quad alert \text{ if } M_{free} < M_{threshold}
可用堆余量是仓库是否即将爆仓的实时先兆；持续低于阈值时，不应直接扩容掩盖问题，而要回到分配侧分析。
  1. M_max（最大堆）Java 由 -Xmx 指定，Go 可由容器 memory limit 感知并配合 GOGC 动态调整。
    MmaxM_{max}
  2. M_free（可用余量）最大堆减去当前已用堆，得到还能容纳多少新对象。
    Mfree=Mmax−MusedM_{free} = M_{max} - M_{used}
  3. M_threshold（告警阈值）例如最大堆的 20%。当余量低于阈值时，优先检查分配速率和泄漏增长，而不是只调大堆上限。
    Mfree<MthresholdM_{free} < M_{threshold}

AI 应用场景

线上 GC 频繁告警的 Java 服务排查

阶段：运维巡检与故障诊断

解决的问题：传统方式靠人工登录服务器翻日志，信息分散且滞后。通过聚合 GC 日志和堆转储，自动计算 GC 时间占比，并把可疑对象按保留大小排序，能在几分钟内圈定根因。

具体案例：某支付网关白天每隔 30 秒出现一次 Full GC。利用日志解析脚本算得 Full GC 时间占比 23%，随后导出堆转储并用 MAT 做支配树分析，发现一个静态 ConcurrentHashMap 缓存未设上限，存了数百万订单对象。给缓存加上最大条目和过期策略后，GC 恢复正常。

Go 微服务内存持续增长定位

阶段：容量评估与性能压测

解决的问题：容器内存 RSS 持续上涨时容易触发 OOMKill；用 pprof heap 快照对比和 goroutine profile 可以区分是对象泄漏还是协程泄漏。

具体案例：某用户画像服务每次请求向全局 map 写入用户标签，value 关联大量画像对象。连续三次 pprof heap 对比后，发现 map bucket 对象 inuse 总量线性上升，同时 goroutine 数量稳定，判定为业务缓存无限增长。改为带 TTL 的 local cache 后，内存水位明显下降。

发布前的内存安全 CI 门禁

阶段：自动化测试与质量保障

解决的问题：人工审查难以发现内存回归。通过流水线自动运行压测场景，采集 pprof 或 MAT 报告，与基线比对，超过阈值就阻断合并。

具体案例：某交易系统的 CI 流水线在压测后自动生成 Java 堆转储，并运行脚本统计可疑对象增长率。凡是新出现的大型静态集合或保留大小异常的对象，都会被标记为阻断项，显著减少了线上内存事故。

Python 演示

python41 行
import re def parse_gc_log(lines):    stats = {'count': 0, 'full_count': 0, 'pause_ms': [], 'total_pause_s': 0.0}    pattern = re.compile(r'GC\((\d+)\).*?(Full GC)?.*?(\d+)M->(\d+)M\((\d+)M\),\s*([0-9.]+)s')    for line in lines:        m = pattern.search(line)        if not m:            continue        stats['count'] += 1        if m.group(2):            stats['full_count'] += 1        pause_s = float(m.group(6))        stats['pause_ms'].append(pause_s * 1000)        stats['total_pause_s'] += pause_s    return stats def summarize(lines, window_s=600):    stats = parse_gc_log(lines)    if stats['count'] == 0:        return '未解析到 GC 日志'    avg_pause = stats['total_pause_s'] / stats['count'] * 1000    gc_ratio = stats['total_pause_s'] / window_s * 100    return {        'gc次数': stats['count'],        'full_gc次数': stats['full_count'],        '平均暂停(ms)': round(avg_pause, 2),        '最慢暂停(ms)': round(max(stats['pause_ms']), 2),        'GC时间占比(%)': round(gc_ratio, 3),        '最近一条日志': lines[-1].strip()    } if __name__ == '__main__':    sample = [        '[2025-01-01T12:00:00.000+0000][gc,info] GC(0) Pause Young (G1 Evacuation Pause) 128M->80M(1024M), 0.0132342s',        '[2025-01-01T12:05:00.000+0000][gc,info] GC(1) Pause Young (G1 Evacuation Pause) 256M->200M(1024M), 0.0215871s',        '[2025-01-01T12:10:00.000+0000][gc,info] GC(2) Pause Full (System.gc()) 800M->512M(1024M), 0.5093176s'    ]    result = summarize(sample, window_s=600)    for k, v in result.items():        print(f'{k}: {v}')
目的：用正则解析 Java GC 日志，自动汇总 GC 次数、Full GC 次数、平均暂停、最慢暂停和 GC 时间占比，快速判断清理队是否超负荷。
  1. pattern = re.compile(...)用一条正则匹配 GC 日志中的堆前后占用、最大堆和暂停时间，是后续统计的入口。
  2. if m.group(2): stats['full_count'] += 1捕捉行中是否出现 "Full GC"，Full GC 往往是系统压力的红标。
  3. pause_s = float(m.group(6))取出停顿秒数并转成浮点数，才能参与平均与占比计算。
  4. gc_ratio = stats['total_pause_s'] / window_s * 100把总暂停时间除以观测窗口，得到 GC 时间占比，对应正文中的 R_GC。
  5. if __name__ == '__main__':让模块既能被 import 复用，也能直接运行示例数据，便于本地验证。

常见误区

误区我用 `top` 看到进程 RSS 8G，可 JVM 堆上限只有 4G，这一定是堆内存泄漏。

正解RSS 包含堆、Metaspace、线程栈、JIT 编译产物、DirectByteBuffer 等所有进程内存。Java 进程 RSS 大于 -Xmx 是常态，不能直接画等号。要看实时堆占用需用 jstat、堆转储，要查 Native 内存则用 JVM 的 NMT 功能。类比仓库：RSS 是整片园区面积，堆只是其中一间货架库房。

为何常见：运维最熟悉 top，RSS 是默认指标，容易下意识与 JVM 参数对比。

误区Go 程序 GC 之后 RSS 一直不降，内存线持续高，肯定有 goroutine 泄漏。

正解Go 运行时会在 GC 后保留一部分空闲内存，用于后续分配复用，未必立刻归还操作系统。判断是否泄漏要看 pprof heap 的 inuse_space 是否持续上升，再结合 runtime.MemStats.Sys 确认运行时到底维护了多少内存。类比：仓库清掉废纸箱后，闲置的托盘不会马上变卖，而是留着下一次进货用。

为何常见：GC 回收了逻辑对象，但操作系统层面的 RSS 没有明显下降，观察者容易误以为内存没有释放。

误区进程 OOM 了，我每次都直接上 MAT 找泄漏，因为报告里总有一个大对象。

正解OOM 还可能来自单次超大对象分配、堆上限设置过小、碎片化或 native 内存耗尽。Java 频繁创建短命大数组也能触发 OOM，但本身不是泄漏。正确做法是先看多份堆快照的存活对象总量是否持续上升，再决定是修泄漏还是调参数。类比：仓库进不了货，有时是货太多，有时只是配送通道太窄。

为何常见：泄漏是高频 OOM 原因，久而久之人们容易把相关关系当成因果关系。

误区Go 程序 pprof 里 alloc_space 非常大，我断定一定存在内存泄漏。

正解alloc_space 是程序启动以来的累计分配总字节，它一定随时间增长，正常程序也会很大。泄漏要关注 inuse_space 是否持续上升；alloc_space 更多用于定位高频分配路径。类比：仓库累计搬入量再大都正常，关键要看此刻有哪些箱子还赖在货架上。

为何常见：很多新手拿到 pprof 报告先看最大数字，却忽略了“总额”和“当前存量”是完全不同的两个维度。

误区我有堆转储就够了，GC 日志没什么用，又看不懂。

正解堆转储只是某个瞬间的快照，反映的是“现在有什么”；GC 日志反映的是“多久清一次、有没有清干净”。两者结合才能区分是“涨得快”还是“清不掉”。类比：警察只看案发现场照片，不看监控录像，很难判断凶手何时来过、从哪里逃跑。

为何常见：堆转储文件可以直接用 MAT 打开，获取成本低；GC 日志看起来格式复杂，容易被跳过。

面试题

Q1. Go 内存泄漏排查应优先关注 pprof 的哪个指标？

单选题 · easy

  • A.当前堆占用快照← 正确答案
  • B.历史累计分配
  • C.运行总时长的秒数
  • D.系统内存总容量

答案：A。inuse_space 表示当前仍存活并占着堆的对象，泄漏的本质就是这些对象没有被回收；alloc_space 是历史累计总量，用于发现高频分配路径，却不直接反映泄漏。

Q2. Java 中导出堆转储用哪个命令？

单选题 · easy

  • A.jmap -dump 生成堆文件← 正确答案
  • B.jstack 输出线程转储
  • C.jps 列出可用进程
  • D.jinfo 调整系统属性

答案：A。jmap 是 Java 内存映射工具，jmap -dump 能导出堆转储；jstack 查看线程栈，jps 列出进程，jinfo 查看或调整参数，都不负责堆转储。

Q3. 内存泄漏的本质是什么？

单选题 · easy

  • A.对象失去引用但仍占堆
  • B.对象仍被引用但不再使用← 正确答案
  • C.堆总大小被设置过小
  • D.GC 线程被暂停执行

答案：B。泄漏是“不再需要的对象仍被强引用”，因此 GC 无法回收。A 中失去引用的对象会被正常回收；C 是配置问题，D 是停顿现象，都不是泄漏本质。

Q4. GC 日志 800M->512M(1024M), 0.5s 表示什么？

单选题 · mid

  • A.GC 后老年代存活 512M
  • B.GC 后堆占用降到 512M← 正确答案
  • C.GC 后将堆扩大到 1024M
  • D.GC 耗时 512 毫秒

答案：B。-> 前是 GC 前占用，后是 GC 后占用，括号内是最大堆，0.5s 是暂停时间。因此堆占用从 800M 降到 512M，最大堆仍是 1024M，停顿为 500ms。

Q5. MAT 的支配树主要用来做什么？

单选题 · mid

  • A.找出对象间的支配与保留关系← 正确答案
  • B.恢复已被 GC 回收的对象
  • C.统计代码执行时间
  • D.检查线程死锁状态

答案：A。支配树展示对象之间“谁支配谁”，并据此计算保留大小，帮助分析哪个对象持有整片内存；它不能恢复对象，也不负责代码执行时间和死锁检测。

Q6. 两份 heap dump 相隔 10 分钟，哪类对象最可能是泄漏？

单选题 · hard

  • A.数量从一万涨到二十万且被强引用← 正确答案
  • B.数量从二十万降到五万且被弱引用
  • C.数量保持不变且被软引用
  • D.数量随机波动且无引用

答案：A。泄漏对象会随时间持续增长，并且仍被强引用；弱引用和软引用都可能被 GC 清理，数量下降或波动都不符合泄漏特征。

Q7. Go 中连续两次 heap profile 显示 inuse_space 线性上升，首选排查动作是什么？

单选题 · hard

  • A.沿引用链找持有者← 正确答案
  • B.调大 GOGC 值掩盖
  • C.观察 CPU 使用率
  • D.删除 pprof 采样

答案：A。inuse_space 持续上升说明当前堆中对象越积越多，必须找到谁一直引用这些对象；调大 GOGC 不是定位手段，CPU 使用率关联不直接，删除采样更不可取。

Q8. 以下哪些可能是 Java 老年代持续增长的正常原因？

多选题 · mid

  • A.业务需要长期存活对象← 正确答案
  • B.大对象频频晋升← 正确答案
  • C.缓存未设置为有界缓存← 正确答案
  • D.年轻代回收耗时过长

答案：ABC。长生命周期对象、大对象直接晋升、无界缓存累积都会让老年代增长；D 是回收耗时问题，不是老年代占用的原因。

Q9. 定位 Go 内存泄漏可用哪些手段？

多选题 · mid

  • A.对比多次 pprof 堆快照← 正确答案
  • B.查看 goroutine 数量变化← 正确答案
  • C.分析 alloc_space 分布← 正确答案
  • D.调大 GOGC 后重启验证

答案：ABC。对比 heap 快照能看到对象增长，goroutine profile 能发现协程泄漏，alloc_space 可辅助定位分配路径；调整 GOGC 只是缓解手段，不能定位根因。

Q10. GC 时间占比高达 25%，但堆占用率始终不高，可能的原因有？

多选题 · hard

  • A.对象分配速率极高← 正确答案
  • B.堆最大上限设置过小← 正确答案
  • C.大对象频繁触发 GC← 正确答案
  • D.系统 CPU 核数过多

答案：ABC。分配速率高、堆上限小、大对象频繁晋升都会导致 GC 频繁，但堆可能还没来得及用满就被回收；CPU 核数不影响 GC 暂停占比。