MAT

1.下载使用

https://www.eclipse.org/mat/
MemoryAnalyzer.ini 把最后一行 -Xmx1024m 改成 -Xmx10g

2.打开文件

Leak Suspects Report	自动扫描整份堆，找出"内存泄漏嫌疑点"：哪个对象占了最多内存、它被谁引用、为什么回收不掉。会生成 Overview + Top Consumers + Leak Suspects	第一次分析就选这个，最常用，直接告诉你罪魁祸首
Component Report	不是找泄漏，而是找"浪费"：重复字符串、空集合、finalizer、弱引用等低效结构。需要先框定一组对象	已定位到可疑模块，想精细优化时再选
Re-open previously run reports	直接打开 dump 旁边已生成的 ZIP 报告，不重新解析，秒开	之前已经跑过一次，只是回头看结果

3.分析结果

Shortest Paths To the Accumulation Point	从 GC Root 到"累积点"的最短引用链。回答：谁在拿着它 / 从哪能释放掉	想知道"这段内存挂在哪条调用链上、哪里能断开"时看
Accumulated Objects in Dominator Tree	累积点之下对象的支配树（树形、逐层展开，按 retained size 排序）。回答：这 4.24 GB 具体是哪些对象吃掉的	想知道"内存长什么样"，一层层往里挖
Accumulated Objects by Class in Dominator Tree	同上，但按类聚合成一个节点。回答：哪几种类型占大头（你这里就是 TreeMap$Entry / char[] / Object[]）	最推荐先看这个，一眼看出大头
All Accumulated Objects by Class	不限于支配树，列出累积点下所有可达对象按类统计（含被多个父节点共享的，所以数字通常比上一项更大）	想拿完整清单、不漏掉共享对象时看

4.详细信息

WorkQueue[16] @0x100055fe8730 ← 4.5 GB 全在这一个工作队列里
← queues ForkJoinPool @0x10014cfe3e8d
← ASYNC_POOL java.util.concurrent.CompletableFuture (System Class) ← GC Root
← pool ForkJoinWorkerThread ... commonPool-worker-14~20
← common class ForkJoinPool (System Class)
← executor Caffeine SSLSMW / SSMSA ← 只有 146KB / 297KB，无关
← ASYNC_POOL jdk.internal.net.http.HttpClientImpl

根因：ForkJoinPool.commonPool() 里堆积了约 2,200 个没释放的流式 HTTP 请求（SSE/按行读取），占了 4.5 GB（78%）。