若o持续上升且fgc后仅微降、fgc频次增加但单次耗时未暴涨、ygc/fgc比值接近或倒挂，则基本可断定是内存泄漏；需结合gc日志中old usage回落量递减及arthas验证强引用失控来确认。
看 jstat 输出的 OU 和 FGC 趋势是否匹配泄漏特征
频繁 GC 本身不等于内存泄漏，关键看老年代行为。执行 jstat -gcutil <pid> 1000</pid> 每秒刷新，盯住三列：O（老年代使用率）、FGC（Full GC 次数）、FGCT（Full GC 总耗时）。如果出现以下组合，基本可断定是泄漏：
-
O持续上升（比如从 45% → 72% → 91%），且每次 Full GC 后仅回落 2%～5%，不“锯齿”而“爬坡” -
FGC频次明显增加，但FGCT单次耗时没暴涨（排除大对象扫描瓶颈） -
YGC/FGC比值接近 1:1 或倒挂（健康应用通常 >10:1），说明大量对象活过年轻代直接进老年代
注意：别只看 OGC（老年代容量）是否稳定——它不变只能说明堆大小没动态扩容，不能排除泄漏。
GC 日志里找 Allocation Failure 和 Old Usage 回落幅度
启用 -Xlog:gc*:file=/path/to/gc.log:time,uptime,level,tags（JDK11+）后，打开日志重点筛两件事：
- 搜索
Allocation Failure触发的Full GC：这说明老年代真没空间了，不是策略触发 - 定位连续几次
Full GC的日志段，提取Old或PSOldGen区域的 “A->B(C)” 形式数据，例如：PSOldGen: 6800K->7150K(8192K)→7150K->7620K(8192K)→7620K->7980K(8192K)。回落量从 350K → 470K → 360K，越来越小，就是典型泄漏信号
如果看到的是 Promotion Failed，优先查大对象或 Survivor 空间不足，不一定是泄漏。
别用 jmap -histo:live 强制触发 Full GC
想确认对象分布？可以，但方式很重要。执行 jmap -histo:live <pid></pid> 会强制触发一次 Full GC，线上环境可能雪上加霜。更安全的做法是：
- 用
jmap -dump:live,format=b,file=heap.hprof <pid></pid>抓存活对象快照（STW 时间短、文件小） - 或提前配好
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/dumps/，等 OOM 自动落盘 - 避免对高负载服务执行无
live参数的jmap -dump，它导出全部对象（含已标记待回收的），文件巨大、分析低效
抓完快照后，MAT 里别迷信 Leak Suspects Report——它常把静态缓存误报为泄漏。真正要盯的是 Dominator Tree 中 Retained Heap 排前三的业务类，再右键查 Path to GC Roots，看引用链是否合理（比如 static CacheManager → HashMap → byte[]）。
Arthas 验证运行时强引用是否失控
堆快照是快照，有些引用关系只有运行时才暴露。比如 ThreadLocal 没 remove()，或监听器注册后没反注册。这时用 Arthas 更直接：
- 查静态 Map 是否持续膨胀：
ognl '@com.example.Cache@cacheMap.size()' - 看线程池中 ThreadLocal 值残留：
thread -n 10找活跃线程，再ognl '#threadLocal.get()'（需先用sc找到 ThreadLocal 实例） - 搜未关闭资源：
watch java.io.FileInputStream close '{params,throwExp}' -n 5，看是否漏调用
这些操作不依赖 dump，也不停服，能快速验证你从 jstat 和 GC 日志里猜出的泄漏点是否真实存在。
最易被忽略的一点：Metaspace 稳定 ≠ 类加载没问题。自定义 ClassLoader 加载的类实例占的是堆内存，不是 Metaspace。如果怀疑类加载器泄漏，得在 MAT 里查 ClassLoader 实例数是否随请求增长，而不是只看 GC 日志里的 Metaspace 行。
