排查内存泄漏需控制开销：jmap -histo最安全，jmap -dump会触发Full GC，Arthas等在线工具更可控但需预部署，生产推荐OOM自动dump与jstat零开销监控。

排查内存泄漏本身会带来一定性能开销，但关键在于控制在可接受范围内——生产环境不是不能动，而是要“轻触、快取、少扰”。开销大小取决于你用什么工具、在什么时机、以什么方式采集数据。

不同工具的开销差异明显

命令行工具（如 jmap、jstack）开销最低，通常毫秒级完成，对业务影响微乎其微。但要注意：
– jmap -dump 会触发一次 Full GC（除非加 -live 参数），可能造成短暂 STW；
– jmap -histo 不触发 GC，只统计堆内对象数量和大小，最安全；
– jstack 采集线程栈时若线程数极多（比如上万），可能卡住几秒，建议配合 timeout 使用。

堆转储文件（Heap Dump）生成与传输是主要瓶颈

真正拖慢服务的往往不是采集动作本身，而是后续环节：
– 堆越大，dump 文件体积越大（比如 4GB 堆可能生成 3GB+ 的 .hprof 文件）；
– dump 过程中 JVM 会暂停应用（STW），时间与存活对象数量正相关；
– 上传 dump 文件到分析机或挂载盘，可能占满磁盘 IO 或网络带宽；
– 若直接在容器里 dump 到 /tmp，而 /tmp 是 tmpfs（内存文件系统），等于把堆又复制进内存，极易触发 OOM。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

在线诊断工具更可控，但需提前部署

Arthas 和 VisualVM JMX 连接 属于“无侵入式”采集：
– 不需要 dump 整个堆，可按需查看类加载、线程、GC 实时状态；
– 可动态开启 GC 日志、监控对象创建速率（watch 命令）；
– 缺点是必须提前接入，且部分命令（如 heapdump）仍等价于 jmap，开销一致；
– 推荐组合：先用 dashboard 看整体趋势，再用 vmtool --action getInstances 抽样查可疑对象，避免全量扫描。

规避高开销的实操建议

– 避免在流量高峰期间执行 jmap -dump，优先选低峰或灰度节点；
– 生产环境默认开启 -XX:+HeapDumpOnOutOfMemoryError，让 OOM 时自动 dump，不依赖人工干预；
– 对于大堆（>8GB），改用 jcmd VM.native_memory summary 快速看堆外内存是否异常，跳过堆内分析盲区；
– 如果只是怀疑泄漏而非已 OOM，用 jstat -gc 1000 持续观察老年代使用率是否单边上涨，零开销定位趋势。