得亏了它,我才把潜藏那么深的Bug挖出来

312 阅读4分钟

2020年写了很多事故解决的文章,并不是我绞尽脑汁想出来的,而是真的遇到了这些问题。通过文章的方式记录下来,分享出去,才有意义。

事故背景

首先看下面的图吧,这是我从cat上截的图。

图片

可以看到是一个Rpc调用的错误,从错误中我们只能分析出这个Rpc的请求成功了,并且返回了,因为都走到了反序列化这步。

最后是在创建DTO对象的时候报错了,Could not initalize class xxxxx.DTO说明了这一点。

作为一个调用方,虽然看到了明确的错误,但还是要本着严谨的态度去排查问题,还是先确认服务提供者到底有没有问题,跟同事确认了,服务提供方没问题,通过telnet可以正常invoke。

好了,到这为止就把背景交代清楚了,能不能将这个潜藏的Bug找出来就各显身手吧。

arthas大显身手

要想效率高,那必须得有好用的工具呀!arthas挺身而出,都毛遂自荐了,不用白不用。

首先使用sc命令查看JVM已加载的类信息,就看这个不能实列化的类到底有没有被成功加载。

sc -d 类全路径 (打印类的详细信息

图片

类的信息都被打印出来了,足以证明这个类被加载了。

然后打印下类里面的字段,看看有没有丢失什么的

sc -d -f 类全路径 (打印类的Field信息

图片

居然报错了,错误还跟我们之前在cat中看到的一模一样,这边也是要是创建对象,然后反射获取所有字段信息,由于不能创建对象,直接报错了。

就这么结束了吗?怎么可能,还没下班呢,接着走下去。。。。

现在我开始怀疑这个class是不是有问题,然后就开始用arthas的另一个命令jad来反编译。

通过jad 命令将 JVM 中实际运行的 class 的 byte code 反编译成 java 代码,便于我们理解业务逻辑,也能让我们知道代码跟本地的到底是不是一致。

**jad --source-only **类全路径

执行完后,什么也没输出,我一度怀疑这个命令是不是我用错了,然后我试了下jad --source-only java.lang.String 发现命令没问题,就是那个class有问题。

这时我想起还有一个redefine命令可以用于加载外部的.class文件,看看能不能加载进来。于是我将lib目录里面依赖的jar包解压了,然后用redefine去加载那个不能反编译的class。

图片

居然告诉我是一个无效的class,尝试多次都无法让这个class现出庐山真面目。

最后没办法,只能将这个class弄到本地,拖入IDEA中反编译,对比了下代码,跟git仓库里面的一模一样,也就不存在jar包损坏的问题。

即将揭开真相

到目前为止,有效的线索如下:

  • class已加载,但是无法实例化
  • 通过本地反编译,代码是完整的

越在这种没有思路的情况下越要静下心来思考,于是再次看了一遍源码,发现这个类中有引用一个外部的自定义异常类。

然后我用sc -d去查看这个类的信息,告诉我不存在,终于明白了。

图片

看上面这张图,项目A依赖了API,API中依赖了Common,Common中又依赖了很多其他的三方Jar包。

由于项目A和Common中依赖的三方Jar包冲突了,所以项目A中之前就简单粗暴的把Common给排除了,冲突是解决了。

在进行RPC调用的时候,请求的数据响应回来后需要反序列化成对象,这个时候去创建对象失败了,因为类中依赖了某个外部的类,但在当前项目中没有加载进来,所以就报错了。

总结

这次的问题归根到底还是没有想到一个API会依赖其他的模块,本身API作为RPC调用客户端就应该简洁。

其实在做exclusion的时候应该只exclusion有冲突的三方Jar,不应该将整个Common都exclusion掉。

最后就是合理的利用方便快速的工具帮助我们快速的排查问题,arthas就是这个好帮手,通过arthas我们可以进一步排除程序启动后加载的class有没有问题,进一步缩小范围。

感兴趣的可以关注下我的微信公众号 猿天地,更多技术文章第一时间阅读。我的GitHub也有一些开源的代码 github.com/yinjihuan