arthas是线上java内存异常动态排查的核心工具，支持不重启、不中断、快定位：通过dashboard监控老年代趋势，vmtool查高频对象与静态字段，heapdump --live导出轻量快照，结合jstat观测gc行为识别泄漏特征。
线上动态排查内存异常点，核心是“不重启、不中断、快定位”。重点不是等 OOM 后再行动，而是在内存缓慢上涨阶段就捕获可疑对象和引用链。以下方法均支持生产环境直接执行，无需改代码、不依赖预埋参数。
用 Arthas 实时抓取内存热点
Arthas 是线上内存问题的首选工具，轻量、无侵入、可热插拔：
-
看实时对象分布：执行
dashboard查看堆内存使用趋势、GC 频次、线程数；重点关注老年代（Old Gen）是否持续不回落 -
查高频对象实例：运行
vmtool --action getInstances --className java.util.HashMap --limit 10或替换为你的业务类名，快速列出当前存活的 Top 10 实例 -
定位大对象持有者：用
vmtool --action getStaticField --className com.example.CacheManager --fieldName instance检查静态单例是否持有了不该持有的集合或缓存 -
导出轻量快照：执行
heapdump --live /tmp/heap-lite.hprof（加--live只导出活跃对象，比全量 dump 快且小）
结合 jstat 持续观测 GC 行为
内存泄漏的本质是对象“该死不死”，GC 日志会暴露这个信号：
- 执行
jstat -gc -h10 <pid> 2000</pid>（每 2 秒输出一次，共 10 行），观察OU（老年代使用量）是否逐轮上升、OGC（Full GC 次数）是否陡增 - 若
OU每次 Full GC 后只下降一点点（比如从 1800M → 1790M），说明有大量对象跨代晋升且无法回收，极可能泄漏 - 配合
jstat -gccause <pid> 5000</pid>看每次 GC 的触发原因，如果频繁出现Allocation Failure但回收效果差，就是典型泄漏特征
用 jmap + MAT 快速分析现场快照
当发现可疑趋势，立刻保留证据：
- 在低峰期执行
jmap -histo:live <pid> > /tmp/histo-live.txt</pid>，获取当前存活对象的类统计（注意加:live，避免干扰） - 对比两次 histo 输出（间隔 5–10 分钟），关注数量增长最快的类，例如
com.example.Order实例从 500 增至 3200，就要立即查它被谁引用 - 将
/tmp/histo-live.txt拷贝到本地，用 Excel 或脚本排序，找出增量最大的前 5 类；再用jmap -dump:format=b,file=/tmp/leak-suspect.hprof <pid></pid>导出对应时刻快照，导入 MAT 查 “Path to GC Roots”
针对常见泄漏源做定向检查
不用大海捞针，优先验证高发场景：
-
ThreadLocal 泄漏：执行
thread -n 5查看活跃线程，再对每个疑似业务线程（如pool-OrderExecutor）运行ognl '@java.lang.Thread@currentThread().getThreadLocals()'，看是否持有未清理的大 Map -
静态缓存膨胀：用
ognl '#class = Class.forName("com.example.GlobalCache"), #class.getDeclaredField("cache").get(null)'直接读取静态字段值，检查 size 和 key 分布 -
Netty 堆外泄漏：若用 Netty，加 JVM 参数
-Dio.netty.leakDetection.level=advanced（无需重启，Arthas 可动态设置系统属性），然后查日志中LEAK:关键字
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
