Arthas通过分层观察定位Java性能瓶颈：先用dashboard识别高负载线程，再用trace追踪热点方法耗时，接着用thread命令检查锁竞争，最后结合GC与内存分析关联影响。
Arthas 不需要改代码、不重启服务，就能在线定位 Java 应用的性能瓶颈。关键不是“猜”，而是分层观察、交叉验证：先看全局负载，再聚焦线程和方法，最后下钻到类与对象。
一、快速识别高负载线程
执行 dashboard 命令，每 5 秒刷新一次，重点关注 “Thread” 区域中 CPU 使用率最高的前几个线程：
- 记下线程 ID（如 27）和名称（如 http-nio-8080-exec-3）
- 观察其状态是否长期为 RUNNABLE，且 CPU 占比持续高于 30%
- 若多个线程集中在同一类方法（如 com.example.UserService.process），说明该路径是热点
二、追踪热点方法耗时
对可疑类或方法使用 trace 命令，自动展开调用链并标出最慢环节：
- trace com.example.UserService process —— 查看整个方法执行耗时及子调用分布
- 加条件过滤：trace com.example.UserService process '#cost>100' —— 只显示耗时超 100ms 的调用
- 配合 -n 5 限制采样次数，避免干扰业务；-x 2 跳过初始化调用，更贴近真实场景
三、检查是否被锁或阻塞
高 CPU 线程不一定在计算，也可能是自旋等待或同步竞争：
立即学习“Java免费学习笔记（深入）”；
- 用 thread <id>（如 thread 27）查看线程栈，确认是否卡在 synchronized、LockSupport.park 或 Unsafe.park
- 执行 thread -b 快速列出所有正在阻塞其他线程的线程（即持有锁但迟迟不释放者）
- 结合 sc -d *Lock* 检查是否有异常加载的锁实现类，排除类加载冲突导致的锁行为异常
四、关联内存与 GC 影响
CPU 高有时是 GC 频繁反推的结果，不能孤立看线程：
- 运行 dashboard -i 5000，同时观察 “GC” 栏中的 Young GC 和 Full GC 频次与耗时
- 若 CPU 高峰与 GC 停顿时间重叠，执行 vmtool --action getInstances --className java.lang.Object --limit 1 粗略判断对象创建速率
- 用 memory 查看 metaspace 是否持续上涨，防止因动态代理、Groovy 脚本等引发元空间泄漏拖慢 JIT 编译
