arthas 的 profiler 命令不直接用于内存泄漏排查,仅辅助定位高频对象创建或长生命周期线程;内存泄漏需依赖 vmtool、heapdump、dashboard 等命令结合 gc roots 分析。

Arthas 的 profiler 命令本身不直接用于内存泄漏排查,它主要用于 CPU 热点分析(如方法耗时、调用栈分布)。内存泄漏需结合其他命令协同诊断,profiler 仅在特定场景下辅助定位——比如发现某个对象创建异常频繁、或某段代码长期持有对象未释放,进而引向可疑的内存增长源头。
为什么 profiler 不是内存泄漏的主力工具
profiler 基于 async-profiler,采样的是运行时的调用栈和方法执行时间,它能看到“谁在频繁 new 对象”或“谁在反复调用某段初始化逻辑”,但无法直接展示堆内存中对象的引用链、存活数量或 GC 后是否被回收。这些才是内存泄漏的核心证据。
真正用于内存泄漏排查的 Arthas 命令主要是:
-
vmtool --action getInstances:按类名查当前堆中实例数量 -
vmtool --action getStaticField:检查静态集合类(如 static Map/List)是否持续累积 -
dashboard或jvm:观察老年代使用率、GC 频次与回收效果 -
heapdump+ 外部工具(如 Eclipse MAT):导出堆快照做深度分析
profiler 在内存泄漏排查中的辅助用法
当已观察到内存持续上涨(如 dashboard 显示老年代占用每小时涨 5%),且怀疑是某段业务逻辑导致对象堆积时,可用 profiler 快速聚焦热点:
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
定位高频对象创建点:启动采样后,用
profiler stop --format html导出火焰图,重点关注new xxxObject或构造方法(如com.example.User.<init></init>)出现频次异常高的调用路径 -
识别长生命周期线程/定时任务:通过
profiler start -e itimer(基于时间采样)查看哪些线程长时间处于 RUNNABLE 状态,并持续调用某段缓存逻辑,可能隐含未清理的本地缓存 -
验证修复效果:修改代码(如加 remove 逻辑)后,再次用
profiler对比相同路径下对象创建次数是否显著下降
典型组合排查流程(含 profiler 参与环节)
假设线上服务 OOM 前老年代缓慢上涨:
- 先用
dashboard确认内存趋势和 GC 行为(如 CMS GC 失败、G1 Mixed GC 越来越频繁) - 用
vmtool --action getInstances --className com.example.CacheEntry --limit 10查看该类实例数是否随时间线性增长 - 若确认增长,再用
profiler start -e itimer -d 60采样 60 秒,停后生成 HTML:profiler stop --format html --file /tmp/prof.html - 打开 HTML,搜索
CacheEntry.<init></init>,看其上层调用是否集中在某个 Service 方法或 ScheduledTask 中——这往往就是泄漏源头的入口 - 最后用
vmtool --action getStaticField --className com.example.GlobalCache --fieldName instances检查该静态 Map 是否真在不断 put 而未 remove
注意事项
使用 profiler 时需注意:
- async-profiler 默认不采集对象分配事件(allocation profiling),要开启需加参数
-e alloc(Arthas 3.7.0+ 支持),例如:profiler start -e alloc -d 30,才能看到对象分配热点 - allocation 模式开销较大,生产环境慎用,建议先在预发复现问题后再启用
- 单靠 profiler 无法替代 MAT 分析:它不能告诉你某个
CacheEntry为何没被回收,必须结合heapdump查它的 GC Roots 引用链
不复杂但容易忽略:profiler 是“找火源”的放大镜,而内存泄漏的本质是“水没排出去”。先确认水位(内存监控)、再查排水口(GC Roots)、最后盯住进水阀(对象创建点)——profiler 主要在第三步提供线索。
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










