Arthas 启动失败主因是用户权限不一致或 JVM 启用 -XX:+DisableAttachMechanism；trace 仅捕获后续调用且受 JIT 内联影响；monitor/watch 开销大需谨慎；所有诊断数据会话级失效，须主动重定向或手动保存。
Arthas 启动失败：java -jar arthas-boot.jar 报错找不到进程或权限拒绝
Arthas 无法 attach 到目标 JVM，最常见原因是目标进程 UID 与当前用户不一致（比如 Java 进程由 root 启动，而你用普通用户运行 arthas-boot.jar），或目标 JVM 启用了 -XX:+DisableAttachMechanism。
- 先用
ps -ef | grep java确认目标进程 PID 和启动用户，切换到同一用户再执行java -jar arthas-boot.jar - 若进程是 root 启动且不能切用户，可临时用
sudo java -jar arthas-boot.jar，但注意 Arthas 会继承 sudo 权限，后续命令操作范围更广，需谨慎 - 检查 JVM 参数是否含
-XX:+DisableAttachMechanism—— 一旦启用，Arthas 完全无法 attach，必须重启应用并移除该参数 - 容器环境（如 Docker）需确保已挂载
/tmp（Arthas 依赖 tmp 目录通信），且开启--cap-add=SYS_PTRACE，否则 attach 时静默失败
trace 命令卡住或返回空：方法没被调用？还是匹配错了？
trace 不是监听器，它只对「后续新发生的调用」生效；如果目标方法在 trace 启动前已调用过、或根本没触发，就看不到任何输出。另外，类名/方法名写错、未加载、或被 JIT 内联都会导致无结果。
- 确认方法签名是否完整：
trace com.example.Service doWork只匹配无参方法；带参得写成trace com.example.Service doWork java.lang.String - 加
-n 5限制采样次数，避免长时间阻塞；加--skipJDKMethod false才能看到 JDK 底层调用链（默认跳过） - 如果方法刚启动就调用，可能 trace 还没就绪——先
watch或ognl验证类是否已加载，再 trace - JIT 编译后的方法可能被内联，此时
trace失效；可加 JVM 参数-XX:-TieredStopAtLevel临时禁用分层编译辅助诊断
monitor 和 watch 性能开销大：线上不敢用？
这两个命令本质是字节码增强（retransform），每秒采集都会触发一次 JVM safepoint，高频调用或大对象打印会显著拖慢吞吐量，甚至引发 STW。
-
monitor -c 60表示每 60 秒统计一次，不是每秒采样 60 次 —— 时间间隔越大，压力越小 -
watch默认打印整个入参/返回值对象，遇到大 JSON 或集合务必加条件过滤，例如watch com.XX method '{params[0].id, returnObj.status}' -x 2 - 生产环境慎用
watch * * *这类通配，极易误伤；优先用精确类名 + 方法名，配合-b（before）或-s（success）缩小增强范围 - 如果发现 CPU 突增，立刻
stop或直接shutdownArthas，不要等超时自动退出
连接断开后诊断数据丢失：怎么保留关键现场？
Arthas 是会话级工具，终端关闭、网络中断或 stop 后所有 trace/watch/monitor 状态全部清空，不会落盘。想留痕，得主动导出。
立即学习“Java免费学习笔记（深入）”；
- 所有命令支持重定向输出：
trace com.XX m1 > /tmp/trace.log，但注意这仅保存命令执行期间的输出，不是实时流式记录 - 真正要持续捕获，得用
dashboard -i 5 > /tmp/dashboard.log &后台跑，配合tail -f查看（注意磁盘空间） - 复杂场景建议组合使用：
jad反编译源码存档，sc -d查类加载详情，vmtool --action getstatic提取静态变量快照，这些结果都可手动保存 - 别依赖 Arthas 自动保存 —— 它没有持久化机制，断连即丢，关键线索务必在看到的第一时间复制走
Arthas 的威力不在功能多，而在「轻量介入」和「即时反馈」；但正因太轻，它不记账、不备份、不兜底。所有操作都要带着「这次断了就没了」的预期去执行。
