得亏了它,我才把潜藏那么深的Bug挖出来
Posted yinjihuan
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了得亏了它,我才把潜藏那么深的Bug挖出来相关的知识,希望对你有一定的参考价值。
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有没有问题,进一步缩小范围。
以上是关于得亏了它,我才把潜藏那么深的Bug挖出来的主要内容,如果未能解决你的问题,请参考以下文章
[转] "self = [super init]"的解释与潜藏bug