以下文章来源于猿天地 &＃xff0c;作者尹吉欢

前因

那是一个月黑风高的夜晚&＃xff0c;不管有没有圆圆的月亮&＃xff0c;都无法解救要加班的我。这就是苦涩的人生啊&＃xff01;

那天正好是春节回家的日子&＃xff0c;定了晚上的票&＃xff0c;然后还是上线的日子。

测试在做回归测试的时候&＃xff0c;发现一个老功能报错了&＃xff0c;什么鬼&＃xff0c;都没改过那块代码怎么会出问题&＃xff1f;案件疑点重重呀。。。

为了能够早点上线&＃xff0c;早点回家&＃xff0c;所以这个 Bug 就显得十万火急了&＃xff0c;因为就这一个问题&＃xff0c;其他都没问题&＃xff0c;解决好了就可以上线了&＃xff0c;于是开启了破案之路。

第一步&＃xff1a;找到错误信息

机智的我在第一时间打开了 Cat 查看具体的错误&＃xff0c;由于当时并没有想到去写一篇文章出来&＃xff0c;错误信息也就没有截图&＃xff0c;后面通过模拟的操作&＃xff0c;得到了类似的一样的错误信息如下&＃xff1a;

Cat错误信息

居然是类转换错误&＃xff0c;点进去查看详细的错误信息&＃xff0c;如下图&＃xff1a;

Cat错误详情

真正有价值的错误信息如下&＃xff1a;

dubbo version: 2.7.3, current host: 192.168.8.224 java.lang.ClassCastException:

第二步&＃xff1a;排查报错的代码

公司代码不方便透露&＃xff0c;下面都是模拟的代码&＃xff1a;

public ResponseData login(UserLoginRequest loginRequest) { loginRequest.getAddress().stream().map(a -> a.getStatus()).collect(Collectors.toList());return Response.ok("xxxxxxxxx");}

问题就出在了 map 这里&＃xff0c;从 loginRequest 参数中获取 address 是一个 List

&＃xff0c;Address 中有 status 字段&＃xff0c;如果是正常的对象没有问题&＃xff0c;错误告诉我们是 HashMap 不能转换成 Address 类&＃xff0c;也就是说参数中的 Address 变成了 HashMap 导致的错误。

参数代码&＃xff1a;

&＃64;Datapublic class UserLoginRequest implements Serializable { private String username; private String pass; private List address;}&＃64;Data&＃64;AllArgsConstructorpublic class Address implements Serializable { private int status;}

第三步&＃xff1a;本地复现错误

找到错误后&＃xff0c;马上本地启动相关的两个服务&＃xff0c;我们分别叫 A 和 B 吧&＃xff0c;现象是 A 调用 B 的某个 RPC 接口报错。

本地启动后马上复现了错误&＃xff0c;在报错的地方打断点看参数是否变成了 HashMap&＃xff0c;果不其然&＃xff0c;如下图&＃xff1a;

参数信息

到这里感觉有点懵&＃xff0c;参数中明明是具体的对象类型&＃xff0c;怎么突然就变成了 HashMap&＃xff0c;匪夷所思。

然后想着是不是在上层什么地方出问题了&＃xff0c;继续查看报错的上层代码&＃xff0c;没有发现异常。然后决定在 PRC 的入口处打个断点看看是不是参数一过来就出问题了&＃xff0c;最后经过验证确实如此&＃xff0c;也就排除了 B 服务中对参数做了转换。

接着再看下 Dubbo 内部的参数解码&＃xff0c;

org.apache.dubbo.rpc.protocol.dubbo.DecodeableRpcInvocation#decode(org.apache.dubbo.remoting.Channel, java.io.InputStream)。也就是请求到达 B 之后解码出来的已经是 HashMap 了&＃xff0c;那么问题肯定是调用方传输的参数有问题。

Dubbo内部参数查看

第四步&＃xff1a;排查调用方代码

在调用方这边发起请求前&＃xff0c;查看了参数对象&＃xff0c;发现这个时候参数已经出问题了&＃xff0c;字段类型发生了变化&＃xff0c;所以问题就出在这里&＃xff0c;都是老代码&＃xff0c;应该都没改过&＃xff0c;而是事实却被改了&＃xff0c;通过 Idea 的 Annotate 快速的查看了当前方法中有被修改的记录&＃xff0c;找到了修改的代码&＃xff0c;下面通过模拟的方式贴出有问题的代码&＃xff0c;如下&＃xff1a;

&＃64;Reference(version &＃61; DubboConstant.VERSION_V100, group &＃61; DubboConstant.DEFAULT_GROUP)private UserRemoteService userRemoteService;public void test() { UserLoginRequest request &＃61; new UserLoginRequest(); request.setUsername("yjh"); request.setPass("123456"); List address &＃61; new ArrayList<>(); address.add(new Address(1)); request.setAddress(address); UserLoginRequest2 request2 &＃61; new UserLoginRequest2(); request2.setUsername("yjh2"); request2.setPass("1234562"); List address2 &＃61; new ArrayList<>(); address2.add(new Address2(StatusEnum.INVALID)); request2.setAddress(address2); BeanUtils.copyProperties(request2, request); userRemoteService.login(request);}

出问题的就是 BeanUtils.copyProperties(request2, request); 这行代码&＃xff0c;将一个对象复制到另一个对象&＃xff0c;两个对象的属性都一样&＃xff0c;唯一不一样的是 Address 中的 status 是 int 类型&＃xff0c;Address2 中的 status 是 Enum&＃xff0c;复制过去就出问题了。

属性复制

这种情况也只在 Dubbo 的 RPC 请求出问题&＃xff0c;如果是 Http 请求&＃xff0c;基本类型变成了枚举&＃xff0c;直接就报错了&＃xff0c;无法转换。

Http请求错误

第五步&＃xff1a;BeanUtils 问题排查

归根到底还是 copy 的问题&＃xff0c;我做了个小实验&＃xff0c;如果是 Address2 copy 到 Address 是不会出问题的&＃xff0c;只有嵌套的对象才会出问题。

特意看了下 copy 的代码&＃xff0c;如果是 Address2 copy 到 Address&＃xff0c;那么就是 status 到 status&＃xff0c;在 copy 之前会进行判断 Address 的 setStatus 的第一个参数类型和 Address2 的 getStatus 的返回值是否相同&＃xff0c;如果相同才会进行赋值操作&＃xff0c;不同就不会&＃xff0c;如果是单个对象在这里就会直接过滤掉了&＃xff0c;一个是 int 一个是 Enum。

BeanUtils源码

嵌套对象之所以可以那是因为 address 的参数和返回类型都是 List&＃xff0c;没有去判断嵌套类里面的&＃xff0c;是整个集合直接复制赋值的&＃xff0c;下图是目标方法&＃xff1a;

BeanUtils源码

value 是新的集合对象&＃xff0c;invoke 后整个 address 就变了。

嵌套对象复制后

第六步&＃xff1a;Dubbo 解码问题排查

前面分析中&＃xff0c;调用之前通过 BeanUtils 复制&＃xff0c;只是将枚举赋值给了基本类型&＃xff0c;如果 Dubbo 在接收到参数进行解码时能够识别出类型不一致&＃xff0c;这样就直接会报错了&＃xff0c;然而并没有&＃xff0c;特意调试了下 Dubbo 解码的代码&＃xff0c;默认是 Hessian 的解码&＃xff0c;怀疑跟 Hessian 有关&＃xff0c;于是我把序列化改成了 FastJson&＃xff0c;在解码参数的时候就直接报错了&＃xff0c;不能转换成 int 类型。而 Hessian 在映射不了的时候就直接变成 HashMap 了&＃xff0c;这才有了我们前面的错误。

FastJson解码失败

结局

找到原因后解决就是分分钟的事了&＃xff0c;通过这个问题还是说明了加任何的代码都有风险。剩下的就是开发的锅了&＃xff0c;加了代码没有自测&＃xff0c;好在有测试把关&＃xff0c;否则就凉凉了。