Arthas 的 dashboard 和 thread 命令不直接监控变量值，而是通过 CPU 占用、老年代内存增长、线程数异常等全局指标定位问题线程与内存泄漏线索，再结合 vmtool、ognl、getstatic 等命令深入检查具体变量。
Arthas 的 dashboard 和 thread 命令本身不直接监控“变量”的内存运行状态——它们聚焦于线程行为与 JVM 全局资源（CPU、内存、线程数、GC）的实时观测。真正用于查看变量值或对象实例的，是 vmtool、ognl 或 getstatic 等命令。但 dashboard 与 thread 是诊断起点：它们帮你快速识别“哪个线程在狂占 CPU”“哪类对象在持续膨胀”，从而精准圈定需进一步查变量的目标。
dashboard：先看全局异常信号
执行 dashboard 后，重点关注三块区域：
-
线程面板顶部 CPU% 列：数值持续 >80% 的线程（如 ID=45 的
redis-scheduler占 85%），说明它可能在执行高频循环、死循环或阻塞式重试；这不是变量本身的问题，而是变量使用方式引发的线程行为异常 - JVM 内存区的 PS Old / G1 Old Gen 使用量：若老年代占用率随时间单向爬升（如从 3G → 5.4G → 7.2G），且 Full GC 后几乎不下降，说明有对象长期存活未被回收——这时要怀疑静态缓存、监听器未注销、线程局部变量未清理等场景中的变量引用
- 线程数持续增长：比如每分钟新增 10+ THREAD_NEW 状态线程，可能意味着某处 new Thread() 未复用或未 shutdown，背后常是 Runnable 中持有业务对象（如未释放的数据库连接、缓存 map 引用）
thread：定位高消耗线程并追溯调用链
找到可疑线程 ID（如 dashboard 中 CPU% 最高的 35 号）后，用 thread 35 查看完整堆栈。关键看：
- 堆栈末尾是否落在你自己的业务包路径下（如
com.example.cache.CacheService.add），这说明问题代码就在那里 - 是否出现重复调用同一方法（如
getRandomStr在循环中反复执行），结合代码可判断是否因逻辑缺陷导致变量反复创建（如每次生成新 byte[] 数组却未复用） - 是否有
WAITING on java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject类似字样，暗示线程被锁住，而锁对象可能正被某个静态变量（如 static Map）持有
从线程/内存线索转向变量检查
当 dashboard 和 thread 锁定可疑类或方法后，再用其他命令查具体变量：
- 查静态变量内容：
getstatic com.example.LeakController cache—— 直接打印该 static Map 的 size 和部分 key，确认是否无限增长 - 查运行中对象实例：
vmtool --action getInstances --className byte[] --limit 5—— 列出最大的 5 个 byte[] 实例，看其分配位置（stackTrace）是否指向某段缓存逻辑 - 动态执行表达式验证假设：
ognl '#context=@org.springframework.web.context.ContextLoader@getCurrentWebApplicationContext(),#context.getBean("cacheService").getSize()'—— 调用 Spring Bean 方法获取当前缓存大小，无需改代码
避免常见误解
不要指望 dashboard 显示某个 String 变量的值，也不要用 thread 去翻找局部变量——它们不在这个层级。它们的作用是：
- 告诉你“系统正在发烫”，而不是“哪根电线短路了”
- 指出“发热最厉害的芯片编号”，然后你才拿万用表（vmtool/ognl）去测那颗芯片的引脚电压（变量值）
- 如果只盯着变量看，容易陷入细节迷宫；先用 dashboard/thread 看清热力分布，排查效率能提升 5 倍以上
