dashboard和thread不直接显示方法执行时长，而是分层定位热点：dashboard看全局异常（cpu高、老年代飙升、线程数激增），thread锁高负载线程并查堆栈，再用trace测具体方法耗时。
dashboard 和 thread 命令本身不直接显示“方法执行时长”，但它们是定位热点方法的最高效入口：dashboard 提供全局异常信号，thread 快速聚焦高消耗线程，再结合 trace 等命令才能精确测量单次或多次调用耗时。整个过程是分层递进的——先看面，再盯线，最后钻点。
dashboard：一眼识别 JVM 全局异常
执行 dashboard 后，界面动态刷新，重点关注三块：
- CPU% 列持续高于 80% 的线程（如 ID=27 的 pool-1-thread-3 占 92%），说明它正密集执行某段逻辑，极可能是热点方法源头
- PS Old / G1 Old Gen 使用量单向攀升（比如 5 分钟内从 2.1G → 6.8G），且 Full GC 后回落极少，提示存在长期存活对象，背后常是静态缓存未清理、监听器未注销等导致的变量引用泄漏
- THREAD_NEW 或 RUNNABLE 线程数每分钟新增 10+，大概率是线程池配置不当或 new Thread() 泄漏，需检查其 Runnable 中是否持有未释放的业务对象（如 Map、Connection）
thread：锁定高负载线程并初步判断热点位置
从 dashboard 找到可疑线程 ID 后，用 thread 命令深入：
- thread -n 5：直接列出 CPU 占用最高的前 5 个线程，省去人工排序
- thread [id]：查看指定线程完整堆栈，重点观察末尾是否落在你自己的包路径下（如 com.example.order.OrderService.submit）
- thread -b：一键检测死锁，直接输出持锁/等待锁的线程及锁对象，避免手动分析 jstack
- 若堆栈中反复出现同一方法（如 com.example.util.StringUtils.split），结合代码可判断是否因循环调用或低效实现导致 CPU 持续占用
从线程线索转向热点方法耗时测量
thread 定位到具体线程和调用栈后，真正测方法执行时长要用 trace：
- trace com.example.service.UserService login：跟踪该方法内部所有子调用，显示各层级耗时，快速发现慢 SQL、远程调用或正则匹配等瓶颈点
- trace -n 5 com.example.cache.CacheManager get：只采样最近 5 次调用，避免高频方法刷屏，适合压测或突增流量场景
- 若 trace 显示某行正则匹配（java.util.regex.Pattern.matcher）耗时超 200ms，基本可确认是日志切面中过度使用复杂正则所致
补充技巧：让监控更精准、更安全
实际排查中，几个细节常决定成败：
- dashboard 默认每 5 秒刷新一次，按 c 可继续刷新，按 q 退出但保持会话，避免误触 ctrl+c 导致整个 Arthas 断开
- thread 命令中的 ID 是 Java 层线程 ID，与 jstack 中的 nid（十六进制 native ID）不一致，勿混用
- 线上环境慎用 watch 或 trace 高频方法（如 toString、getter），可能引发性能抖动；建议加 -n 限制采样次数，或用 tt 命令录制后再分析
- 多个 Arthas 客户端可同时连接同一 JVM，但执行 stop 会终止所有会话，日常调试优先用 quit 退出当前终端
