设想你是一家小餐馆的老板老王。午市刚开张，后厨就乱了套：出菜口压单、师傅满头大汗、每周二还得停业做大扫除，连冷库都爆过一回。你翻值班本、清冷库、查谁借了东西不还，最后重新规划后厨、盯着流水确认改善——这一整套“后厨体检+整改”的流程，就是JVM的GC调优。本文把GC、堆、日志、Dump、内存泄漏、Full GC这些概念全部放进这间餐馆里讲，用一条故事线走完“发现→诊断→开方→复查”的全流程。读完你会理解：GC调优不是背参数，而是像经营餐馆一样，先看数据、再找病因、最后小步改进并验证。

岗位关联

对AI从业者的价值：LLM/RAG服务、推理网关、特征平台的Java进程常因GC问题拖慢响应，掌握这套诊断与优化方法论，能让你在生产事故中快速定位、从容救火。

目录
  1. 可视化演示
  2. 性能问题识别
  3. GC日志分析
  4. 堆Dump解析
  5. 内存泄漏排查
  6. Full GC调优
  7. 调优效果验证
  8. 工具与经验
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示GC调优实战的核心机制，通过输入/处理/存储/输出四种模式展示关键概念与交互流程。

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

GC调优实战：GC问题 GC问题诊断与GC日志分析 堆内存分析与内存泄漏排查 核心机制可视化 GC调优实战整体架构与关键组件

性能问题识别

老王开了家“老王私房菜馆”，最近午市高峰顾客催单越来越凶。他跑到后厨一看，三个信号异常扎眼：出菜口压了一排订单（接口响应时间上升）、大厨满头大汗翻勺（CPU飙高）、每周二都得停业半天做大扫除（频繁Full GC），前阵子连冷库都爆了一次（OOM告警）。这就是GC调优的起点——不是上来改参数，而是先确认“现象”到底长什么样。

Java应用的JVM就是那座后厨，堆内存是冷藏柜，垃圾回收是清洁工。GC调优是一条从发现症状开始的流水线，第一步是做好“问题识别”。常见的报警信号有四类：接口RT的P99持续上涨，可以用APM（应用性能监控）观测；CPU使用率中GC线程占比偏高，相当于大扫除队伍占据了后厨大部分人力；jstat工具显示Full GC次数频繁，说明老年代经常被打满；日志里出现OutOfMemoryError，相当于冷库彻底爆仓。收集这些症状要靠监控系统（如Grafana+Prometheus盯JVM指标）和JDK自带的jstat做实时交叉验证。

识别阶段要完成一次“分诊”：到底是大扫除太频繁（GC频率高），还是单次大扫除太久（单次暂停长），或是冷库本身布局不合理（堆配置问题）？这三类方向的证据完全不同，决定了后续该翻值班本、清点库存还是调整仓库布局。

老王先拿出小本子，记下“什么时候堵、一次堵多久、堵的时候在忙什么”。有了这份初步记录，他才知道该不该请清洁大队进场——这就是用数据代替直觉的第一步。

GC日志分析

老王开始在值班本上做详细记录：每次清洁工来清扫，清掉哪些菜、存放空间变化多少、花了多少分钟。GC日志就是JVM的“后厨值班本”，里面记录了每一次垃圾回收的来龙去脉。想拿到这本账，得先在启动参数里请JVM“记账”：JDK 11+用-Xlog:gc*:file=gc.log:time,uptime,level，老版本用-verbose:gc -XX:+PrintGCDetails。

一行典型的GC日志长这样：

解读它只需抓住五个要素：GC类型（是Minor GC还是Full GC）、Young区回收前后用量、整堆回收前后用量、堆总容量、暂停时长。配合jstat -gcutil可以按小时统计GC次数和平均停顿，但这还只是“看得见账本”，要判断GC是不是真凶，需要计算一个关键指标——GC开销率。

一般来说，如果GC开销率超过10%且伴随接口延迟恶化，GC就已经是业务瓶颈，值得投入调优。老王翻了两个月值班本，发现大扫除平均占用营业时间的15%——这笔时间要是省下来，能多接不少订单。

GC开销率=∑i=1nPiTend−Tstart×100%\text{GC开销率} = \dfrac{\sum_{i=1}^{n} P_i}{T_{\text{end}} - T_{\text{start}}} \times 100\%
  1. 暂停总时长（分子）把一次运行内所有GC停顿时间加总，得到“被垃圾回收偷走的时间”。
    ∑i=1nPi\sum_{i=1}^{n} P_i
  2. 运行总时长（分母）从JVM启动到统计截止的墙钟时间，代表业务可用的总时间窗。
    Tend−TstartT_{\text{end}} - T_{\text{start}}
  3. 比例换算分子分母相除并乘以100%，得到GC暂停占总运行时间的百分比，即GC开销率。
    ∑i=1nPiTend−Tstart×100%\dfrac{\sum_{i=1}^{n} P_i}{T_{\text{end}} - T_{\text{start}}} \times 100\%
text1 行
[GC (Allocation Failure) [PSYoungGen: 524288K->51200K(611840K)] 524288K->120320K(2014720K), 0.0234567 secs]

堆Dump解析

值班本只能看出“清了很久、空间老不够用”，但看不出到底是什么菜占着冰箱。于是老王决定打烊后做一次彻底盘点：把仓库里每一样东西记进一张《库存清单》。对应到JVM，这张清单就是堆Dump（heap dump）——JVM在某一瞬间的堆内存快照。

导出堆Dump的常用命令是jmap -dump:live,format=b,file=heap.hprof <pid>，也可以使用jcmd GC.heap_dump。需要注意，dump过程会暂停JVM（尤其是live模式会触发Full GC），生产环境操作要避开高峰并评估影响。拿到快照后，用Eclipse MAT或VisualVM打开，重点看三个视图。

第一个是Histogram（对象直方图），按类统计实例数量和占用总空间，相当于“哪类货品最多”；第二个是Dominator Tree（支配树），展示哪个对象“攥着”一大片内存不放，相当于“谁霸占着整排货架”；第三个是Path to GC Roots（引用链），从GC Roots出发追踪到可疑对象，相当于“这件货品是谁在台账上登记寄存的”。三者配合，能从“多”追到“根”。

盘点表一出来，老王倒吸一口凉气：三号角落堆着八千多箱“顾客寄存的旧椅子”，占了半个冷库。数量多不可怕，可怕的是它们根本不该出现在这里——这已经指向了内存泄漏。

内存泄漏排查

椅子的主人早就不来了，可仓库的入库单上还写着“已寄存”，清洁工按规矩不能扔——这就是内存泄漏的本质：对象已经没有业务价值，但依然有引用链从GC Roots连到它，导致垃圾回收无法将其清除。它最阴险的地方在于“温水煮青蛙”：系统不会立刻崩溃，而是每天多占一点空间，直到某天突然OOM。

先判断有没有泄漏，方法很简单：记录每次GC完成后的堆使用量，如果“每次大扫除完，剩余占位反而比上一次更高”，基线不断抬升，那就是泄漏。泄漏的速度可以用公式量化。

确认泄漏后，拿出两个不同时间点的dump做增量对比，重点看哪个类的实例数在稳定增长；再沿Path to GC Roots找到持有者。生产环境最常见的四种泄漏场景：static集合只增不减、ThreadLocal用完不remove、网络或文件流未关闭、无界缓存无淘汰策略。

老王拿着入库单倒查，发现是“VIP寄存区”的登记系统从不销账——某段代码里的static Map只put不remove。病因找到了，接下来就该调整后厨的规矩。

泄漏率=U(t2)−U(t1)t2−t1\text{泄漏率} = \dfrac{U(t_2) - U(t_1)}{t_2 - t_1}
  1. 采样点1的堆用量记录第一次GC完成后JVM堆的已用空间，作为基线。
    U(t1)U(t_1)
  2. 采样点2的堆用量记录第二次GC完成后堆的已用空间，与基线形成对比。
    U(t2)U(t_2)
  3. 时间跨度计算两次采样点之间的实际间隔时长。
    Δt=t2−t1\Delta t = t_2 - t_1
  4. 求增长斜率用堆用量差除以时间差，得到单位时间内“收不掉”的内存增长速度。
    U(t2)−U(t1)t2−t1\dfrac{U(t_2) - U(t_1)}{t_2 - t_1}

Full GC调优

病因清楚之后，老王重新规划了后厨：冷库扩到合适大小、把“日日鲜”货架和“长期储备”冰柜的比例调整好，再立一条规矩——寄存物品三个月不取就清理。Full GC调优也是同样的三张处方：堆参数、大对象治理、代码层释放。核心原则是“让多数对象在年轻时就死掉，别让它们挤进老年代的大扫除清单”。

第一张处方是堆参数。-Xms与-Xmx设为相同值，避免运行时频繁扩容抖动；-XX:NewRatio控制新生代与老年代比例，相当于调整日日鲜货架与长期冰柜的占地比；-XX:SurvivorRatio调整幸存区大小。第二张处方是大对象治理：用-XX:PretenureSizeThreshold让超大对象直接进入老年代，避免在新生代反复拷贝；业务上尽量避免一次性的超大数组或超长字符串，必要时用对象池复用。第三张处方是代码层：try-with-resources关流、缓存设置容量上限、批量处理降低中间对象数量。做这些调整前，要明白Full GC的触发逻辑。

三管齐下之后，老王后厨的大扫除从每周一次变成每月一次，单次时长也从两小时缩到二十分钟。但他没有急着开庆功宴——调优效果必须用数据验证。

Uold≥Rtrigger×ColdU_{\text{old}} \geq R_{\text{trigger}} \times C_{\text{old}}
  1. 老年代已用量当前老年代中存活对象的总体积，相当于长期冰柜已被占用的空间。
    UoldU_{\text{old}}
  2. 触发比例阈值JVM设定的老年代占用比例（例如默认0.92），达到该比例就触发Full GC。
    RtriggerR_{\text{trigger}}
  3. 老年代容量老年代能够容纳的最大空间，相当于长期冰柜的总容量。
    ColdC_{\text{old}}
  4. 触发判定当已用量达到“容量×阈值”时，Full GC被触发，即大扫除自动开始。
    Uold≥Rtrigger×ColdU_{\text{old}} \geq R_{\text{trigger}} \times C_{\text{old}}

调优效果验证

老王没有拍胸脯说“治好了”，而是继续盯了一个月的营业流水。调优完成的标志不是“参数改完了”，而是“数据达标了”。验证的核心方法是在相同业务周期、相同压测规模下做前后对比。

对比基准要提前定好：调优前至少收集一周的GC统计作为“生病时的基线”，调优后再收集同样周期作为“康复后的数据”。验证维度包括Full GC次数、平均与最大暂停时间、GC开销率、接口TP99、系统吞吐量。工具上，用JMeter做压测模拟高峰流量，用Grafana监控堆水位与GC曲线，用jstat复查实时数据。收益大小可以用改进率公式量化。

验证时还要警惕回归风险：堆调小是否引发OOM？缓存淘汰是否影响命中率？这些都要通过压测和灰度验证来排查。新账本出来后，老王的大扫除占用营业时间比例从15%降到了2%——这服药才算真正见效。

改进率=Vbefore−VafterVbefore×100%\text{改进率} = \dfrac{V_{\text{before}} - V_{\text{after}}}{V_{\text{before}}} \times 100\%
  1. 调优前指标值记录调优前同一时间段内的GC暂停总时长，作为对比基线。
    VbeforeV_{\text{before}}
  2. 调优后指标值记录调优后相同统计口径下的GC暂停总时长。
    VafterV_{\text{after}}
  3. 差值相对基线用调优前后的差除以调优前基线，得到相对下降比例。
    Vbefore−VafterVbefore\dfrac{V_{\text{before}} - V_{\text{after}}}{V_{\text{before}}}
  4. 换算百分比乘以100%得到直观的改进率，例如50%代表暂停时间减半。
    Vbefore−VafterVbefore×100%\dfrac{V_{\text{before}} - V_{\text{after}}}{V_{\text{before}}} \times 100\%

工具与经验

老王把这套体检流程写成了一册《后厨手册》，新厨师来了照单操作，半天就能摸清问题。GC调优不是玄学，而是一套可复制的五步法SOP。

工具矩阵是手册的第一章。jps看JVM进程，相当于登记“后厨里有几位师傅”；jstat看GC与堆统计，相当于实时读取“冰箱温度和清扫次数”；jmap导出堆Dump，相当于生成《库存清单》；jstack看线程栈，相当于查看“每位师傅正在忙什么”；MAT和VisualVM负责分析Dump，相当于请专家审阅清单；Arthas可以在线诊断，不必重启应用就能探查运行状态，相当于“师傅边炒菜边接受检查”。

五步法流程是手册的第二章：查症状（监控报警）→看日志（GC日志统计）→取Dump（堆快照）→修代码（调参数或改代码）→验效果（对比数据）。第三章则是三条实战铁律：一次只改一个参数，否则出了问题分不清是谁的锅；让数据说话，不要凭感觉判断“好像变快了”；先压测环境验证，再灰度上生产，绝不拿线上直接试药。

手册越用越厚，团队再遇到“后厨变慢”，第一反应不再是挠头猜谜，而是拿出手册按步骤体检。这正是GC调优实战沉淀出的最大价值。

AI 应用场景

线上推荐服务的Full GC治理

阶段：模型部署与在线推理（MLOps）

解决的问题：推荐网关Java服务每10分钟触发一次Full GC，推理请求的P99延迟从80ms飙到2秒。传统排查像“凭感觉大扫除”，往往直接调大堆内存，反而让单次停顿更久。基于本文方法论，先看监控确认GC开销率，再翻GC日志、取Dump，定位到根因后再精准优化。

具体案例：通过GC日志确认老年代频繁打满，导出Dump后发现某特征缓存对象占堆空间70%，进一步追踪是static Map无上限缓存。改造为Caffeine带容量上限与过期淘汰策略，并调整堆参数后，Full GC降为0，P99恢复至85ms。

特征工程服务的慢泄漏排查

阶段：特征计算与在线存储

解决的问题：特征服务每天内存增长3%，一周后OOM重启导致业务中断。传统做法是“重启大法”，治标不治本。用本文的泄漏率公式量化增长速度，再用多时间点Dump对比定位泄漏源。

具体案例：每天定时导出Dump并对比对象直方图，发现某特征字典实例数以固定斜率增长；沿引用链追踪到ThreadLocal未清理。修复后连续观察两周，内存曲线平稳，Full GC归零。

Python 演示

python49 行
import reimport sys SAMPLE_LOG = """\2025-06-01T10:00:00.123+0800: 1234.567: [GC (Allocation Failure) [PSYoungGen: 524288K->51200K(611840K)] 524288K->120320K(2014720K), 0.0234567 secs] [Times: user=0.03 sys=0.01, real=0.02 secs]2025-06-01T10:00:05.123+0800: 1239.567: [GC (Allocation Failure) [PSYoungGen: 611840K->51200K(611840K)] 624640K->220160K(2014720K), 0.0301234 secs] [Times: user=0.04 sys=0.01, real=0.03 secs]2025-06-01T10:00:30.123+0800: 1264.567: [Full GC (Metadata GC Threshold) [PSYoungGen: 51200K->0K(611840K)] [ParOldGen: 1490944K->1392640K(1402880K)] 1542144K->1392640K(2014720K), [Metaspace: 52190K->52190K(1187840K)], 0.5123456 secs] [Times: user=0.70 sys=0.05, real=0.51 secs]2025-06-01T10:01:00.123+0800: 1294.567: [Full GC (Ergonomics) [PSYoungGen: 307200K->0K(611840K)] [ParOldGen: 1392640K->1392640K(1402880K)] 1699840K->1392640K(2014720K), [Metaspace: 52190K->52190K(1187840K)], 0.6234567 secs] [Times: user=0.86 sys=0.06, real=0.62 secs]""" def parse_gc_times(lines):    """解析GC日志, 统计Minor GC与Full GC的次数和暂停时长"""    pattern = re.compile(        r"\[(GC|Full GC).*?\],?\s*(\d+\.\d+)\s*secs\.?\s*\]"    )    stats = {"minor": {"count": 0, "total": 0.0}, "full": {"count": 0, "total": 0.0}}    for line in lines:        if "GC" not in line:            continue        m = pattern.search(line)        if not m:            continue        kind = "minor" if m.group(1) == "GC" else "full"        pause = float(m.group(2))        stats[kind]["count"] += 1        stats[kind]["total"] += pause    return stats def main():    if len(sys.argv) > 1:        with open(sys.argv[1], "r", encoding="utf-8") as f:            lines = f.readlines()    else:        lines = SAMPLE_LOG.splitlines()    stats = parse_gc_times(lines)    minor = stats["minor"]    full = stats["full"]    print("==== GC日志分析结果 ====")    print("Minor GC: {}次, 总暂停 {:.2f}s, 平均 {:.3f}s".format(        minor["count"], minor["total"],        minor["total"] / minor["count"] if minor["count"] else 0))    print("Full GC: {}次, 总暂停 {:.2f}s, 平均 {:.3f}s".format(        full["count"], full["total"],        full["total"] / full["count"] if full["count"] else 0))    if full["count"] > 0:        print("警告: Full GC次数过多, 老年代空间可能不足") if __name__ == "__main__":    main()
目的：解析GC日志中的Minor GC与Full GC，统计次数、总暂停和平均暂停，快速评估GC开销。
  1. pattern = re.compile(...)用正则表达式从日志行中提取GC类型和暂停时长。
  2. kind = "minor" if m.group(1) == "GC" else "full"区分Minor GC与Full GC。
  3. stats[kind]["count"] += 1累加对应类型的GC次数。
  4. pause = float(m.group(2))把秒数字符串转成浮点数，方便累计求和。
  5. with open(sys.argv[1], "r", encoding="utf-8") as f:打开用户输入的GC日志文件。
  6. stats = parse_gc_times(lines)调用解析函数得到统计结果。
  7. full["total"] / full["count"] if full["count"] else 0计算平均暂停时长，防止除零错误。

常见误区

误区看到Full GC频繁就认为是堆不够用，直接把`-Xmx`从4G调到32G，觉得“堆越大，越不用回收”。

正解堆越大，单次Full GC需要遍历和整理的内存越多，暂停时间反而越长，服务可能从“频繁小卡”变成“偶尔大卡死”。调优要结合机器内存和对象生命周期，合理设置堆大小与新生代比例，重点减少“该收却收不掉”的对象，而不是无脑扩容。就像冷库再大，如果里面堆满了过期货品，大扫除反而更累。

为何常见：内存水位上涨时，人最容易联想到“容器太小”，忽略了“该清的东西没被清掉”才是根因。

误区只盯着GC次数这个数字，看到调优后次数下降就觉得大功告成。

正解GC次数和暂停时间必须一起看。有些参数调整会把多次Minor GC推迟成一次Full GC，次数少了但单次停顿暴涨，整体吞吐量反而更差。正确的衡量标准是GC开销率，即总暂停时间占总运行时间的比例，相当于算“大扫除总共偷走了多少营业时间”。

为何常见：频率是最直观、最容易采集的指标，人不自觉就会拿它当唯一KPI，忽略了更影响用户体验的“单次停顿时长”。

误区接口RT一上涨就怀疑GC，立刻翻GC日志、调GC参数，调了半天没效果。

正解先建立证据链：CPU高是GC线程还是业务线程？响应慢是锁竞争、IO阻塞还是GC停顿？用jstack看线程状态、用APM看调用链，确认GC确实是关键影响因素再动手。就像后厨出菜慢，可能是洗菜池堵了，而不是大扫除太少。

为何常见：GC日志最容易获取，人倾向于处理“看得见摸得着的线索”，而忽略了先做系统性分诊。

误区拿到heap.hprof就打开Histogram，找占用最大的类，认定它就是内存泄漏元凶。

正解占用大的对象不一定是泄漏，有可能是正常的缓存或必要的大结构。泄漏需要对比多个时间点的Dump，看哪个类的实例数在稳定增长，且每次GC后基线依然抬升。单次快照只是“一张截面照片”，看不出“趋势”，用最大者直接断案往往冤枉好人。

为何常见：单点快照提供了“看起来最可疑”的大对象，让人忽略了泄漏必须通过增量对比才能确证这一事实。

面试题

Q1. GC调优的第一步通常是什么？

单选题 · easy

  • A.直接调大堆内存大小
  • B.收集监控观察症状← 正确答案
  • C.立即重写业务代码
  • D.升级到最新JDK版本

答案：B。调优像看病，第一步是“问诊”——用监控收集症状，确认问题是否与GC相关。直接调堆、重写代码、换JDK都是跳过诊断就开药，容易误诊。B才是建立证据链的正确起点。

Q2. 哪个工具可以实时查看JVM的GC统计？

单选题 · easy

  • A.使用jstat查看GC统计← 正确答案
  • B.使用jmap导出内存快照
  • C.使用jstack查看线程栈
  • D.使用javac编译源码文件

答案：A。jstat专门用于查看JVM的GC次数、停顿与堆使用情况，相当于读“后厨值班本”。jmap负责导出Dump，jstack看线程栈，javac是Java编译器，各有分工，不要记混。

Q3. 堆Dump最适合诊断哪一类问题？

单选题 · mid

  • A.CPU死循环导致卡顿
  • B.线程死锁互相等待
  • C.内存泄漏或大对象堆积← 正确答案
  • D.网络超时请求堆积

答案：C。堆Dump是堆内存的《库存清单》，专门用来查“什么对象占了多少空间”，对应内存泄漏和大对象问题。CPU死循环要看线程栈jstack，死锁看锁信息，网络超时要查APM和网络监控，它们都不归Dump管。

Q4. 内存泄漏的典型特征是什么？

单选题 · mid

  • A.GC后堆使用率始终回落
  • B.GC后堆基线持续抬升← 正确答案
  • C.GC次数保持恒定不变
  • D.CPU使用率始终为零

答案：B。内存泄漏像有人借了仓库的椅子不还，每次大扫除后剩余物品反而比上次更多，表现为GC后堆基线上移。A是健康表现，C和D与泄漏没有必然关系。判断泄漏必须看“GC后的基线趋势”而不是单次回收效果。

Q5. GC开销率应该如何计算？

单选题 · mid

  • A.用GC次数除以运行时长
  • B.用GC总暂停除以总时长← 正确答案
  • C.用堆大小除以GC次数
  • D.用老年代除以新生代

答案：B。GC开销率 = GC暂停总时长 ÷ 应用运行总时长，衡量“大扫除占用了多少营业时间”。A算出的是频率而非时间占比，C和D分别是容量和比例概念，都不是开销率。

Q6. 老年代频繁Full GC时，以下哪项优先级最低？

单选题 · hard

  • A.分析老年代对象来源
  • B.无脑调大堆到内存上限← 正确答案
  • C.检查大对象是否过多
  • D.排查是否存在内存泄漏

答案：B。Full GC频繁应先分析病因：老年代对象从哪来、是不是大对象过多、有没有泄漏。无脑调大堆就像把小冷库换成超大冷库，大扫除反而更慢，且可能挤占机器其他资源。B是典型的“头痛医头”式错误操作。

Q7. 以下哪个参数用于开启GC日志？

单选题 · easy

  • A.使用 -Xlog:gc* 开关← 正确答案
  • B.使用 -Xmx 调整堆上限
  • C.使用 -Xms 设置初始堆
  • D.使用 -Xmn 配置新生代

答案：A。开启GC日志相当于给后厨安装值班本，JDK 11+用-Xlog:gc*。-Xmx、-Xms、-Xmn都用于配置堆大小，它们决定“冷库多大”，而不负责“记录清扫过程”。

Q8. 以下哪些属于内存泄漏的常见场景？

多选题 · mid

  • A.static集合只增不减← 正确答案
  • B.ThreadLocal忘记remove← 正确答案
  • C.局部变量正常出作用域
  • D.文件流未及时关闭← 正确答案

答案：ABD。static集合只增不减=入库单从不销账；ThreadLocal不remove=寄存登记未注销；文件流不关闭=借走的锅不还，三者都导致对象无法被GC回收。局部变量出作用域后会被自动回收，是正常行为，不属于泄漏。

Q9. Full GC调优的合理手段包括哪些？

多选题 · mid

  • A.调整堆大小与新生代比例← 正确答案
  • B.减少大对象的不必要分配← 正确答案
  • C.及时释放无用的强引用← 正确答案
  • D.设置JVM禁用垃圾回收

答案：ABC。调优像重新规划后厨：调整堆与新生代比例是改仓库布局，减少大对象是别让占地食材一次进太多，及时释放引用是清理借条。禁用垃圾回收等于不搞大扫除，内存迟早爆仓，属于自毁行为。

Q10. 验证GC调优效果时应关注哪些指标？

多选题 · hard

  • A.关注GC频率与暂停时间← 正确答案
  • B.接口TP99与吞吐量变化← 正确答案
  • C.堆内存增长趋势是否平缓← 正确答案
  • D.日志文件大小的变化

答案：ABC。验证效果要像复查营业流水：GC频率与暂停时间直接反映回收成本，TP99与吞吐量体现用户体验，堆增长趋势平缓说明内存健康。日志文件大小与GC调优是否成功无关，它只反映日志量，不能作为效果指标。