Java GC优化实战：从内存生命周期到ZGC/G1选型-平芜编程栈

1. GC优化：不是调几个参数就完事，而是理解内存生命周期的实战工程

“GC优化”这四个字在Java、Go、Python甚至前端JavaScript圈子里，几乎天天被提起，但真正能说清楚“我在优化什么”“为什么这个参数有效”“线上卡顿到底是不是GC惹的祸”的人，远比你想象中少。我做JVM调优和高并发系统稳定性保障十年，从电商大促压测到金融级实时风控系统，踩过最多的坑，不是线程死锁，也不是SQL慢查，而是——把GC当成黑盒，盲目调-XX:MaxGCPauseMillis、-XX:G1HeapRegionSize，结果服务更抖了，监控曲线更难看了。GC优化的本质，不是让垃圾回收器“少干活”，而是让它的每一次工作都精准、可控、可预期。它背后是对象生命周期建模、堆内存空间结构认知、应用业务特征匹配三者的深度咬合。如果你正在处理一个QPS 5000+的订单服务，或者一个每秒生成20万临时对象的实时计算任务，又或者一个内存敏感的嵌入式Java应用，那么GC不是“可选项”，而是系统稳定性的第一道防线。本文不讲概念复读，不列参数大全，只聚焦真实场景：怎么判断当前GC是否真成了瓶颈？G1和ZGC在什么业务形态下才值得切换？MAT里一张直方图背后藏着哪三个关键泄漏信号？为什么同样的-XX:MaxGCPauseMillis，在支付链路和报表导出链路上效果截然相反？所有结论，全部来自生产环境日志、GC日志解析脚本、MAT实操截图和三次凌晨紧急回滚的真实记录。

2. GC优化的整体设计思路与方案选型逻辑

2.1 不是“选回收器”，而是“匹配业务内存画像”

很多人一上来就问：“G1好还是ZGC好？”这个问题本身就有陷阱。G1和ZGC不是版本迭代关系，而是面向不同内存画像的两种解法。我见过太多团队，因为听说ZGC“停顿<10ms”就强行上，结果发现服务RT没降，CPU却飙到95%，原因很简单：ZGC的并发标记和转移阶段会持续占用CPU资源，而他们的业务是典型的CPU密集型计算（比如风控规则引擎），内存压力反而不大。真正的选型起点，必须是业务的内存画像三要素：

对象存活周期分布：是大量短命对象（如HTTP请求中的DTO、JSON解析中间体）？还是长生命周期缓存（如用户Session、配置元数据）？抑或混合型（电商商品详情页：短命的渲染VO + 长命的商品SKU缓存）？
堆大小与可用物理内存比：堆设4GB，机器有32GB RAM，ZGC的额外内存开销（约15%~20%）完全可承受；但如果堆设16GB，机器总内存才32GB，ZGC的元数据区（Metaspace）和并发标记位图就会挤占其他进程空间，得不偿失。
延迟敏感度与吞吐量优先级：支付扣款链路要求P99 < 50ms，宁可牺牲5%吞吐也要保低延迟；而离线报表导出任务，只要最终结果正确，允许单次GC暂停200ms，那G1的混合收集（Mixed GC）反而更稳。

提示：别信“默认参数最优论”。HotSpot JVM的-XX:+UseG1GC默认开启，但G1的初始堆大小（-Xms）默认是物理内存的1/64，最大堆（-Xmx）默认是1/4——这对一台64GB内存的服务器意味着-Xms=1GB，-Xmx=16GB。而实际业务往往需要-Xms=-Xmx避免动态扩容抖动，且初始堆至少设为预期稳定占用的1.5倍。这个“默认”，在生产环境99%是错的。

2.2 GC优化不是孤立动作，必须嵌入全链路可观测体系

GC问题从来不会单独出现。它往往是下游依赖（如DB连接池耗尽导致请求堆积）、上游流量突增（如秒杀瞬时QPS翻10倍）、或代码层缺陷（如静态Map无清理）的外在表现。因此，GC优化的第一步，永远是建立三层关联监控：

GC层：不仅看GC次数和耗时，更要抓取-XX:+PrintGCDetails -XX:+PrintGCDateStamps日志，解析每次GC的触发原因（Allocation Failure？Metadata GC Threshold？System.gc()？）和回收效果（Young GC后Eden区剩余多少？Old区增长速率？）。
应用层：监控对象创建速率（通过JFR或Arthasmonitor -c 5 java.lang.Object <init>）、活跃线程数、堆外内存（DirectByteBuffer）使用量。一个高频Full GC，如果伴随java.nio.DirectByteBuffer实例数持续上涨，大概率是Netty未释放堆外内存。
系统层：观察free -h的available内存、iostat -x 1的IO等待、vmstat 1的page in/out。曾有个案例：GC频繁，但GC日志显示全是Young GC，耗时正常；最后发现是磁盘IO满载，导致JVM写GC日志阻塞，误判为GC卡顿。

没有这三层数据交叉验证，任何GC参数调整都是蒙眼打靶。我坚持用一个原则：一次GC优化，必须同时拿到GC日志、JFR火焰图、Prometheus JVM指标三份证据，缺一不可。

2.3 方案选型的硬性门槛与避坑红线

不是所有场景都适合激进优化。以下是我划出的四条红线，触碰任一条，先解决根本问题，再谈GC：

红线1：堆内存持续缓慢上涨，且Full GC后无法回落→ 这是内存泄漏（Memory Leak），不是GC策略问题。必须用MAT分析java.lang.ref.Finalizer引用链或org.springframework.util.ConcurrentReferenceHashMap的value强引用。
红线2：Young GC频率>1次/秒，且每次回收后Eden区仍接近100%→ 说明对象晋升过快或Survivor区太小，根源常是大对象直接分配到老年代（-XX:PretenureSizeThreshold设置不当）或年轻代过小。
红线3：GC线程CPU占用长期>30%→ JVM在GC上消耗过多算力，说明要么堆太大（如32GB堆用G1，Region数量超2048，标记开销剧增），要么回收器与硬件不匹配（如4核机器跑ZGC，其并发线程数默认为CPU核心数，会抢走业务线程资源）。
红线4：GC日志中出现Concurrent Mode Failure或Evacuation Failure→ G1已进入失败模式，此时任何参数微调都无效，必须立即扩容堆或切换回收器。

注意：网上流传的“一键优化脚本”（如自动设置-XX:MaxGCPauseMillis=200）极其危险。G1的MaxGCPauseMillis是目标值，不是承诺值。当堆碎片严重或老年代占用率超阈值（-XX:InitiatingOccupancyFraction），G1会强制触发Mixed GC，暂停时间必然超标。盲目设低，只会让G1更激进地提前收集，引发更多GC。

3. 核心细节解析与实操要点

3.1 GC日志的深度解读：从“看不懂”到“一眼定位根因”

GC日志是唯一客观证据，但默认输出信息量巨大且格式混乱。我用一套标准化解析流程，10分钟内定位90%问题：

第一步：统一日志格式（JDK8u271+）
强制启用结构化日志，避免文本解析歧义：

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/logs/gc.log \ -Xlog:gc*,gc+heap=debug,gc+age=trace,safepoint:file=/data/logs/gc.log:utctime,level,tags:filecount=5,filesize=100M

关键点：-Xlog替代旧参数，gc+age=trace能打印对象年龄分布，safepoint日志可确认是否因安全点停顿导致GC假象。

第二步：抓取三类黄金字段
用awk或Logstash提取核心指标（以G1日志为例）：

触发原因：搜索Trigger:字段，常见值：
- Allocation Failure：Eden区满，最健康；
- G1 Evacuation Pause：G1主动发起，正常；
- Metadata GC Threshold：Metaspace满，需调-XX:MaxMetaspaceSize；
- System.gc()：代码中显式调用，必须删除！
回收效果：关注[Eden: 1200M(1200M)->0B(1200M), Survivors: 100M->100M, Heap: 2500M(4000M)->1300M(4000M)]
解读：Eden从1200M清空到0B（成功），Survivor从100M→100M（没变，说明没对象晋升），Heap总占用从2500M→1300M（降了1200M，即Eden回收量）。若Heap只降200M，说明1000M对象晋升到老年代，需检查SurvivorRatio。
停顿构成：[Times: user=0.12 sys=0.01, real=0.13 secs]
real是真实停顿时间，user+sys是GC线程CPU耗时。若real远大于user+sys，说明OS调度或IO阻塞（如GC日志写磁盘慢）。

第三步：构建GC健康度看板
用Prometheus+Grafana监控三个衍生指标：

jvm_gc_pause_seconds_count{gc="G1 Young Generation"}：Young GC频次，健康值<1次/30秒；
jvm_gc_pause_seconds_max{gc="G1 Old Generation"}：Old GC最大停顿，支付类服务应<100ms；
jvm_memory_used_bytes{area="heap"}/jvm_memory_max_bytes{area="heap"}：堆使用率，持续>75%需预警。

实操心得：我自研了一个Python脚本gc_analyzer.py，输入GC日志路径，自动输出报告：
✅ 最近1小时GC次数/耗时趋势
✅ 对象晋升速率（MB/min）
✅ Survivor区使用率峰值
✅ 触发原因TOP3统计
这个脚本在我们团队已沉淀为SOP，新同学入职第一天就能跑起来。核心逻辑是正则匹配[Eden:.*->.*\], \[Survivors:.*->.*\], \[Heap:.*->.*\]，再用datetime模块计算时间差。代码不复杂，但省去90%人工排查时间。

3.2 G1回收器的关键参数精调：拒绝“抄参数”

G1是目前Java生产环境最主流选择，但它的参数不是越多越好，而是要抓住三个杠杆点：

杠杆点1：控制Mixed GC时机（-XX:InitiatingOccupancyFraction）
默认值45%，即老年代占用达45%就触发Mixed GC。但这个值对不同业务差异极大：

电商详情页：缓存命中率95%，老年代增长慢，设为65%更合理，减少不必要的Mixed GC；
实时风控：每笔交易生成大量中间对象，老年代增长快，设为30%可提前清理，避免Concurrent Mode Failure。

计算公式：IOF = (老年代平均占用 / 老年代总大小) × 100%
实测方法：用jstat -gc <pid> 1000 5连续5次，取OU（Old Used）平均值，除以OC（Old Capacity）。

杠杆点2：平衡吞吐与延迟（-XX:MaxGCPauseMillis）
这不是“保证值”，而是G1的优化目标。设得太低（如50ms），G1会：

缩小每次回收的Region数量，导致GC频次飙升；
提前触发Mixed GC，增加老年代扫描压力。

我的经验法则：设为业务P99 RT的1/3。例如支付链路P99=150ms，则设-XX:MaxGCPauseMillis=50；报表导出P99=5s，则设500。同时必须配-XX:G1HeapRegionSize=2M（避免大对象跨Region）。

杠杆点3：Survivor区管理（-XX:SurvivorRatio & -XX:MaxTenuringThreshold）
默认SurvivorRatio=8，即Eden:Survivor=8:1:1。但若对象平均年龄为2（gc+age=trace日志显示），却设MaxTenuringThreshold=15，会导致Survivor区浪费。
实操步骤：

开启-XX:+PrintTenuringDistribution，观察Desired survivor size和Age分布；
若Age 1对象占比>70%，说明大部分对象活不过第一次Young GC，SurvivorRatio可调大（如16），腾出空间给Eden；
若Age 3对象开始大量晋升，MaxTenuringThreshold应设为3，避免无效复制。

注意：-XX:G1NewSizePercent和-XX:G1MaxNewSizePercent慎用！G1会根据GC历史自动调整年轻代大小，手动固定反而破坏自适应。我只在极端场景（如固定16GB堆，要求年轻代恒为4GB）才用，且必须配合-XX:G1HeapRegionSize确保Region数整除。

3.3 ZGC的落地前提与性能陷阱

ZGC号称“毫秒级停顿”，但它的适用场景非常明确。我们团队在2022年将风控引擎从G1迁ZGC，过程踩了三个深坑：

陷阱1：操作系统内核版本不兼容
ZGC依赖Linux 4.14+的userfaultfd系统调用。Ubuntu 18.04默认内核4.15，没问题；但CentOS 7.6内核3.10，必须升级到7.9+或打补丁。曾因内核不匹配，ZGC退化为Serial GC，服务雪崩。

陷阱2：堆外内存（Off-Heap）管理失控
ZGC的并发标记需额外内存存储标记位图（Marking Bitmap），大小≈堆大小×0.5%。若应用本身大量使用DirectByteBuffer（如Netty、Kafka Client），总内存（堆+堆外）可能超限。解决方案：

严格限制-Dio.netty.maxDirectMemory=2g；
用jcmd <pid> VM.native_memory summary监控堆外内存；
关键服务部署时，预留30%内存给ZGC位图。

陷阱3：JDK版本与ZGC特性错配
JDK11 ZGC不支持类卸载（Class Unloading），Metaspace会持续增长；JDK15+才支持。我们初期用JDK11，Full GC后Metaspace不释放，两周后OOM。升级JDK17后，配合-XX:+ClassUnloadingWithConcurrentMark解决。

ZGC上线 checklist：

[ ]uname -r≥ 4.14
[ ]ulimit -l≥ 堆大小×1.5（锁定内存）
[ ]-Xmx≤ 物理内存×70%（预留位图+堆外）
[ ] JDK ≥ 15，且启用-XX:+UnlockExperimentalVMOptions -XX:+UseZGC

实测对比（风控引擎，16GB堆，QPS 3000）：
指标 G1 ZGC
P99 RT 85ms 42ms
GC CPU占用 12% 28%
Full GC次数/天 0 0
内存碎片率 15% <1%
结论：ZGC显著降低延迟，但CPU成本翻倍。我们最终采用“分链路策略”：支付主链路用ZGC保P99，异步通知链路用G1保吞吐。

指标	G1	ZGC
P99 RT	85ms	42ms
GC CPU占用	12%	28%
Full GC次数/天	0	0
内存碎片率	15%	<1%
结论：ZGC显著降低延迟，但CPU成本翻倍。我们最终采用“分链路策略”：支付主链路用ZGC保P99，异步通知链路用G1保吞吐。

4. 实操过程与核心环节实现

4.1 从零搭建GC可观测性体系：日志、指标、火焰图三位一体

没有观测，优化就是赌博。我搭建的体系分三步，全部开源可复现：

Step 1：GC日志集中采集与结构化解析

工具：Filebeat + Logstash

Filebeat配置（filebeat.yml）：

filebeat.inputs: - type: log enabled: true paths: - "/data/logs/gc.log" tags: ["gc-log"] output.logstash: hosts: ["logstash:5044"]

Logstash过滤（gc-filter.conf）：

filter { if "gc-log" in [tags] { grok { match => { "message" => "%{TIMESTAMP_ISO8601:timestamp}.*?%{NUMBER:pause_time:float}s.*?\[Eden: %{NUMBER:eden_before:int}M\(%{NUMBER:eden_total:int}M\)->%{NUMBER:eden_after:int}B\(%{NUMBER:eden_total2:int}M\), Survivors: %{NUMBER:survivor_before:int}M->%{NUMBER:survivor_after:int}M, Heap: %{NUMBER:heap_before:int}M\(%{NUMBER:heap_total:int}M\)->%{NUMBER:heap_after:int}M\(%{NUMBER:heap_total2:int}M\)\]" } } mutate { add_field => { "heap_usage_percent" => "%{heap_after} / %{heap_total} * 100" } } } }

输出到Elasticsearch，Kibana建可视化看板。

Step 2：JFR（Java Flight Recorder）自动录制
JFR是JVM内置的高性能诊断工具，比JProfiler轻量百倍：

# 启动时开启，环形缓冲区，避免磁盘IO -XX:+FlightRecorder -XX:StartFlightRecording=duration=60s,filename=/data/logs/jfr.jfr,settings=profile # 或运行时触发（Arthas） dashboard -n 1000 # 查看JFR状态 jfr start --duration 30s --filename /data/logs/jfr_$(date +%s).jfr

关键分析点：

Memory > Garbage Collection：查看每次GC的详细阶段耗时（Initial Mark、Root Scan等）；
Code > Hot Methods：定位GC Roots中占用最高的方法（如HashMap.get被频繁调用，可能引发大量临时对象）；
Lock Instances：检查是否因锁竞争导致线程阻塞，误判为GC停顿。

Step 3：Prometheus JVM Exporter集成
用jmx_exporter暴露JVM指标：

# jmx_exporter_config.yaml rules: - pattern: 'java.lang<type=Memory><>(.*)' name: jvm_memory_$1 - pattern: 'java.lang<type=GarbageCollector, name=.*><>(.*)' name: jvm_gc_$2

启动命令：

java -javaagent:/opt/jmx_exporter/jmx_prometheus_javaagent.jar=9404:/opt/jmx_exporter/config.yaml \ -jar your-app.jar

Grafana看板必备面板：

GC Pause Time by Collector（区分Young/Old）
Heap Usage %（分新生代/老年代）
Object Allocation Rate（MB/sec）
Metaspace Usage %

实操心得：很多团队只做Step 1，结果GC日志堆成山却找不到规律。我强制要求：每次上线新版本，必须同步开启JFR 30秒录制，并保存到S3归档。三个月后，我们用这些JFR文件训练了一个简单模型，能预测某次代码变更后GC停顿增长概率（准确率82%）。观测不是目的，积累数据资产才是长期价值。

4.2 MAT内存泄漏分析实战：三步定位Static Map泄漏

MAT（Memory Analyzer Tool）是内存分析神器，但新手常卡在“打开dump就崩溃”。我的流程极简：

Step 1：获取有效Heap Dump

线上禁止jmap -dump:format=b,file=dump.hprof <pid>（会STW数秒）；
改用jcmd <pid> VM.native_memory summary确认内存分布后，用jmap -dump:format=b,live,file=dump.hprof <pid>（加live只dump存活对象）；
更优方案：JDK8u271+用jcmd <pid> VM.native_memory baseline建立基线，后续对比。

Step 2：MAT快速筛选泄漏嫌疑对象
打开dump后，执行：

Histogram→java.util.HashMap→ 右键List objects→with incoming references
查看哪些HashMap的size异常大（如>10万）；
Dominator Tree→ 按Retained Heap排序 → 找到Retained Heap最大的对象（通常是静态容器）；
Leak Suspects Report→ 自动生成报告，但需人工验证（报告说org.springframework.context.support.AbstractApplicationContext泄漏，实际是它持有的ConcurrentHashMap）。

Step 3：追溯引用链，定位代码
以Static Map泄漏为例：

在Dominator Tree中找到可疑java.util.concurrent.ConcurrentHashMap；
右键Path to GC Roots→ 勾选exclude weak/soft references；
展开路径，最终看到：com.xxx.service.CacheManager.cacheMap→static final字段；
定位到CacheManager.java第45行：private static final Map<String, Object> cacheMap = new ConcurrentHashMap<>();
问题：未设置过期策略，也未提供清理接口。

修复方案：

替换为Caffeine.newBuilder().maximumSize(10000).expireAfterWrite(10, TimeUnit.MINUTES).build()；
或添加定时清理线程（不推荐，增加复杂度）。

注意：MAT的OQL（Object Query Language）是高级武器。例如查所有未关闭的Connection：
SELECT * FROM java.sql.Connection c WHERE c.closed = false
这比肉眼找快10倍。我常用OQL查java.nio.DirectByteBuffer的cleaner是否为null，判断是否泄漏。

4.3 生产环境GC优化实施SOP：灰度、监控、回滚三板斧

GC参数调整是高危操作，必须像发布代码一样严谨。我们的SOP如下：

SOP 1：灰度验证（最小可行单元）

选择1台非核心节点（如订单查询服务的备用机）；
参数变更仅限-XX:MaxGCPauseMillis、-XX:InitiatingOccupancyFraction等非结构性参数；
观察24小时，对比灰度机与基线机的：
- GC次数/小时（波动<±10%）
- P99 RT（下降>10%或无恶化）
- CPU使用率（上升<5%）

SOP 2：全量发布与熔断机制

全量发布前，配置-XX:+ExitOnOutOfMemoryError，避免OOM后进程僵死；
设置JVM启动参数-XX:OnOutOfMemoryError="sh /opt/scripts/oom_kill.sh %p"，OOM时自动kill进程并告警；
监控平台配置熔断规则：若连续3次GC停顿>500ms，自动触发curl -X POST http://api/rollback回滚参数。

SOP 3：回滚预案（必须书面化）
每个GC优化方案，必须附带回滚步骤文档，例如：

【G1 IOF从45%调至30%】
回滚命令：sed -i 's/-XX:InitiatingOccupancyFraction=30/-XX:InitiatingOccupancyFraction=45/g' /opt/app/jvm.conf
验证方式：jstat -gc <pid> 1000 3，确认OGCMN（Old Gen Min）值恢复；
回滚时限：5分钟内完成，超时自动触发应急预案（扩容节点）。

实操心得：2023年双11前，我们优化风控引擎GC，灰度时发现ZGC在特定流量模式下触发ZUncommit失败，导致内存持续增长。按SOP，5分钟内切回G1，同时启动根因分析。事后发现是JDK17.0.1的一个已知Bug，升级到17.0.2修复。没有SOP，那次大促可能就翻车了。

5. 常见问题与排查技巧实录

5.1 GC相关典型问题速查表

问题现象	根本原因	快速定位命令	解决方案
Young GC频次极高（>1次/秒）	Eden区过小，或对象晋升过快	`jstat -gc <pid> 1000 5`，看`EC`（Eden Capacity）和`EU`（Eden Used）	增大`-Xmn`；检查`-XX:SurvivorRatio`；确认无大对象直接分配（`-XX:PretenureSizeThreshold`）
Full GC频繁且耗时长	内存泄漏，或老年代碎片化严重	`jmap -histo:live <pid> \| head -20`，看`char[]`、`byte[]`是否异常多；`jstat -gc <pid>`看`OC`和`OU`是否接近	MAT分析dump；G1调`-XX:G1HeapRegionSize`；ZGC需检查堆外内存
GC日志显示`Concurrent Mode Failure`	G1并发标记跟不上对象分配速度	`jstat -gc <pid>`，看`GCT`（GC总耗时）是否持续上升	降低`-XX:InitiatingOccupancyFraction`；增大堆；切换ZGC
应用RT抖动，但GC日志无异常	安全点停顿（Safepoint）导致，非GC本身	`jstat -compiler <pid>`，看`Failed`列是否增长；`jinfo -flag +PrintSafepointStatistics <pid>`	减少`-XX:+UseCountedLoopSafepoints`；升级JDK；检查长循环代码
ZGC启动报`userfaultfd not available`	Linux内核版本过低	`uname -r`	升级内核≥4.14，或改用G1

5.2 独家避坑技巧：那些文档里不会写的真相

技巧1：G1的-XX:G1HeapRegionSize不是越大越好
网上教程常说“大对象多就设大Region”，但Region过大（如4MB）会导致：

小对象（<1MB）无法填满Region，造成内部碎片；
G1的Region数量减少，标记阶段并行度下降，反而延长停顿。

我的经验：Region Size = 1MB ~ 2MB。计算公式：Region Size = 堆大小 / 2048（G1默认Region数上限），如16GB堆，16*1024/2048=8MB，但实际设2MB更均衡。

技巧2：-XX:+UseStringDeduplication慎用
该参数对重复String去重，但：

JDK8u20+才支持，且仅对G1有效；
每次Young GC都会触发去重，增加CPU开销；
若应用String极少重复（如UUID、加密token），开启后CPU反升15%。

验证方法：开启后，jstat -gc <pid>看GCT是否明显上升；jcmd <pid> VM.native_memory summary看Internal内存是否增长。

技巧3：不要迷信-XX:+AlwaysPreTouch
该参数启动时预分配并触碰所有堆内存页，避免运行时缺页中断。但：

对大堆（>8GB）启动时间增加数分钟；
在容器环境（如K8s）中，可能导致OOMKilled（因cgroup内存限制被瞬间突破）。

替代方案：用-XX:+UseContainerSupport（JDK10+）自动适配容器内存限制，更安全。

技巧4：MAT分析时，Retained Heap比Shallow Heap重要10倍
Shallow Heap是对象自身占用内存，Retained Heap是该对象被GC后能释放的总内存。一个ArrayList的Shallow Heap可能只有24B，但Retained Heap可能是100MB（因它持有10万个对象引用）。MAT默认按Shallow排序，务必手动切换到Retained Heap。

最后分享一个小技巧：GC优化的终极心法，不是记住多少参数，而是养成“对象生命周期思维”。写每一行代码时，问自己：这个对象何时创建？谁持有它的引用？它会在哪个GC周期被回收？活过几次Young GC？会不会晋升？想清楚这三个问题，80%的GC问题，其实在编码阶段就规避了。我团队的新同学入职培训，第一课不是学JVM参数，而是画一张“订单对象生命周期图”，从Controller接收DTO，到Service组装Entity，再到Mapper写入DB，每一步的引用关系、作用域、销毁时机都标出来。这张图，比任何GC调优文档都管用。