Arthas实战：用watch和tt命令‘时光倒流’，精准复现和调试那个偶现的线上Bug
线上环境偶现的Bug就像幽灵一样难以捉摸——测试环境无法复现，日志信息又残缺不全。作为一名开发者，你是否经历过这样的绝望时刻？当用户反馈某个接口偶尔返回错误数据，而你翻遍日志却找不到任何线索时，传统的调试手段显得如此无力。本文将带你掌握Arthas中watch和tt命令的组合用法，让你拥有"时间旅行"般的能力，精准复现并解决那些最棘手的线上问题。
1. 为什么需要"时光倒流"式的调试？
在本地开发时，我们可以轻松地设置断点、单步执行、检查变量状态。但一旦代码部署到线上环境，这些调试手段就几乎全部失效。线上环境的特殊性带来了三大调试困境：
- 无法打断点：生产环境通常不允许直接连接调试器
- 日志信息有限：过度日志会影响性能，关键信息可能未被记录
- 难以复现：某些Bug只在特定条件下偶发出现，测试环境无法模拟
传统解决方案是加日志→发布→等待问题复现，这种"试错法"效率极低，可能需要多次发布才能捕获到问题。而Arthas的tt(TimeTunnel)命令提供了一种革命性的思路：记录方法调用的完整现场，然后在合适的时间"回放"。
2. 搭建你的"时间隧道"：tt命令基础
tt命令的核心思想是为方法调用建立一条"时间隧道"，记录下每次调用的完整上下文。下面是基本使用流程：
2.1 记录方法调用
假设我们有一个用户查询接口偶尔返回错误数据，首先需要记录该接口的调用情况：
# 记录UserController的getUser方法的所有调用 tt -t com.example.controller.UserController getUser执行后，Arthas会开始记录每次getUser方法的调用，输出类似：
INDEX TIMESTAMP COST(ms) IS-RET IS-EXP OBJECT CLASS METHOD --------------------------------------------------------------------------------------------------------------------- 1000 2023-05-01 14:30:01 45.27 true false 0x12345678 com.example.UserController getUser 1001 2023-05-01 14:32:22 1023.45 false true 0x12345678 com.example.UserController getUser表格中各列含义：
| 列名 | 说明 |
|---|---|
| INDEX | 调用记录的唯一ID |
| TIMESTAMP | 调用发生的时间 |
| COST | 方法执行耗时(毫秒) |
| IS-RET | 是否正常返回 |
| IS-EXP | 是否抛出异常 |
| OBJECT | 调用对象的hashCode |
| CLASS | 类名 |
| METHOD | 方法名 |
2.2 检索调用记录
当问题复现后，我们可以列出所有记录：
# 列出所有记录 tt -l通过观察IS-EXP列可以快速定位到异常的调用记录。对于上例，INDEX=1001的记录明显异常（执行时间长且抛出了异常）。
3. 深入分析问题现场：watch与tt的完美配合
找到异常记录后，我们需要深入分析当时的调用现场。这时watch命令就派上用场了。
3.1 查看调用参数
首先检查异常调用的入参：
# 查看INDEX=1001记录的参数 tt -i 1001 -w "target.params"-w参数指定要观察的表达式，target.params表示方法的参数数组。输出可能类似：
@ArrayList[ @Object[123], // userId @String["premium"] // userType ]3.2 检查成员变量状态
有时问题可能与对象的状态有关：
# 查看调用时的成员变量 tt -i 1001 -w "target.userService.cacheSize"3.3 结合watch命令动态观察
tt -i -w适合查看静态的快照，而watch命令可以动态观察表达式的值：
# 观察方法执行过程中的userService状态 watch com.example.UserController getUser 'target.userService' -x 2常用观察表达式：
params：方法参数target：当前对象returnObj：返回值throwExp：异常对象#cost：方法耗时
4. 精确复现：时间隧道的"回放"功能
tt最强大的功能是能够在开发环境复现生产环境的调用场景。具体步骤：
4.1 导出调用记录
在生产环境导出异常调用记录：
# 导出INDEX=1001的记录到文件 tt -i 1001 -p > /tmp/bug_record.json4.2 在测试环境回放
将记录文件复制到测试环境，然后：
# 从文件恢复记录 tt -r /tmp/bug_record.json # 重新执行该次调用 tt -i 1001 -p这时，测试环境的代码会以完全相同的参数执行该方法，复现生产环境的问题。
4.3 调试技巧
回放时可以结合调试器使用：
- 在测试环境启动应用时加上调试参数
- 在IDE中设置断点
- 执行
tt -i -p回放调用 - 当执行到断点时，可以像调试普通代码一样检查各种状态
5. 高级应用场景与技巧
5.1 条件记录
生产环境调用量可能很大，我们通常只关心特定条件的调用：
# 只记录耗时超过500ms的调用 tt -t com.example.UserController getUser '#cost>500'5.2 观察复杂对象
对于复杂对象，可以指定展开层级：
# 展开2层观察用户对象 tt -i 1001 -w "target.userService.getUser(params[0])" -x 25.3 批量操作
对多个记录执行相同操作：
# 对所有异常调用进行分析 tt -l | grep "IS-EXP:true" | awk '{print $1}' | xargs -I {} tt -i {} -w "target.params"5.4 与jvm命令结合
当发现内存问题时，可以立即转储内存快照：
# 发现内存泄漏迹象后立即dump heap tt -i 1001 -w "target" | grep "memoryLeakObj" && jmap -dump:live,format=b,file=heap.hprof <pid>6. 与传统调试方式的对比
为了更直观理解这种方法的优势，我们对比几种常见调试方式：
| 调试方法 | 是否需要发布 | 是否影响性能 | 能否精确复现 | 信息完整度 |
|---|---|---|---|---|
| 加日志再发布 | 是 | 是 | 否 | 中 |
| 远程调试 | 否 | 高 | 是 | 高 |
| Arthas watch/tt | 否 | 低 | 是 | 高 |
实际项目中，我遇到过一个典型案例：某金融接口在每月1号凌晨会偶发返回错误利率。通过tt记录下问题发生时的完整调用链，我们发现是因为利率缓存没有及时更新，而日志中完全没有记录这个关键信息。最终在不影响生产环境的情况下，仅用2小时就定位并修复了这个困扰团队半年的"幽灵问题"。
