Dubbo RPC调用返回结果中对象被转为HashMap的问题

记录一下编程中遇到的一个有意思的问题：使用Dubbo进行RPC远程调用后，返回对象中有个集合属性List<MyObject> 被解析为了 List<HashMap>，导致调用端使用 MyObject.methodA() 后产生了异常，现在举个例子来模拟下这个场景，并分析下原因。

场景

项目框架：springboot+dubbo。  版本：springboot:2.3.1.RELEASE  dubbo:2.7.15

项目结构：

• 服务提供者：dubbo-sample-provider。
• 服务消费者：dubbo-sample-consumer。
• 接口工程：dubbo-sample-api。

dubbo-sample-provider和dubbo-sample-consumer都引用了dubbo-sample-api。

接口定义（dubbo-sample-api）

先声明一下，在本次测试中，从数据库中查出来的对象我将它称为PO，通过RPC调用在provider和consumer间进行传输的对象我将它称为DTO。

接口实现的功能很简单，通过用户id获取用户信息，包括用户拥有的角色。

public interface IUserService {
    UserInfoDTO getUserInfo(Integer uerId);
}

public class UserInfoDTO implements Serializable {
    private Integer id;
    private String name;
    private List<RoleDTO> roles;
}

public class RoleDTO implements Serializable {
    private Integer roleId;
    private String roleName;
}

服务提供（dubbo-sample-provider）

@DubboService
public class UserServiceImpl implements IUserService {
    
    @Override
    public UserInfoDTO getUserInfo(Integer uerId) {
        UserInfoPO userInfoPO = findUserFormDb(uerId);
        // PO转为DTO
        UserInfoDTO userInfoDTO = new UserInfoDTO();
        BeanUtils.copyProperties(userInfoPO,userInfoDTO);

        return userInfoDTO;
    }

    // 虽然我new了几个对象，你且当是从数据库查出来的
    private UserInfoPO findUserFormDb(Integer userId) {
        RolePO rolePO1 = new RolePO(1,"质检员");
        RolePO rolePO2 = new RolePO(2,"初审员");
        return new UserInfoPO(userId,"张三", Arrays.asList(rolePO1,rolePO2));
    }

}


public class UserInfoPO implements Serializable {
    private Integer id;
    private String name;
    private List<RolePO> roles;
}

public class RolePO implements Serializable {
    private Integer roleId;
    private String roleName;
}

这里注意，BeanUtils是spring包里的工具类 org.springframework.beans.BeanUtils

服务消费（dubbo-sample-consumer）

@SpringBootTest
public class UserTest {

    @DubboReference
    IUserService userService;

    @Test
    public void userTest() {
        UserInfoDTO userInfo = userService.getUserInfo(1);
        String roleName = userInfo.getRoles().get(0).getRoleName();
        System.out.println(roleName);
    }

}

开始测试

服务端启动后，消费端调用getUserInfo方法会报异常

2024-01-10 14:23:50.070  WARN 99188 --- [           main] c.a.c.c.hessian.io.SerializerFactory     : Hessian/Burlap: 'com.hml.provider.user.entity.RolePO' is an unknown class in sun.misc.Launcher$AppClassLoader@18b4aac2:
java.lang.ClassNotFoundException: com.hml.provider.user.entity.RolePO

java.lang.ClassCastException: java.util.HashMap cannot be cast to com.hml.api.user.entity.RoleDTO

这个异常里有两个信息：

1. 消费者服务中没有找到RolePO这个类。
2. HashMap不能转为RoleDTO。

看到这里可能会很纳闷，接收对象里明明声明的是RoleDTO，怎么还出现了RolePO呢？HashMap又是怎么怎么回事？

debug一下消费端的返回结果

咦！明明 roles 的属性定义为List<RoleDTO>，现在却解析为了 List<HashMap>。

再来debug一下服务提供者的代码

DTO中出现了PO，显而易见，对象转换时出现了问题，UserInfoDTO中roles的属性定义为List<RoleDTO>，而这里转换完之后却是List<RolePO>。

这个问题是spring提供的工具方法 BeanUtils.copyProperties 造成的，这个方法看起来是对属性的浅拷贝，而且只看属性的名称，没有判断属性的类型。对应spring的包和版本为spring-beans-5.2.7.RELEASE.jar。

我尝试了一下更高版本的spring，没有了这个问题，高版本的spring包中进行了优化，属性名称一样，类型不一致时不再进行值拷贝，反应到本次的测试代码中就是拷贝完后 roles 为 null 。

换一个属性拷贝的工具类试试，这里换为hutool包的BeanUtil.copyProperties

这次对象转换正常了，DTO里都是DTO,调用端返回对象也正常了

到这里其实已经解决问题了，那么刚才有问题时的HashMap是怎么来的呢？这就要跟到dubbo的反序列化流程里了，这里贴出几个关键点

1.处理RPC返回结果并转成接收对象的入口方法

org.apache.dubbo.rpc.protocol.dubbo.DecodeableRpcResult#handleValue

这个 value 值就是反序列化后的结果。

2.获取对象的序列化器

com.alibaba.com.caucho.hessian.io.SerializerFactory#getDeserializer(java.lang.String)

因为provider返回的对象是RolePO，所以这里会有一次获取RolePO的Deserializer的过程。

还是在getDeserializer这个方法中，代码会走到这里

尝试通过类加载器获取这个全限定名（com.hml.provider.user.entity.RolePO）对应的Class对象，因为 dubbo-sample-consumer 项目中没有 RolePO 这个类，所以这里loadSerializedClass会报异常进而进入到 catch 代码块里，最终 getDeserializer 返回了一个null，给到上层方法。

3.获取到序列化器，进行对象的反序列化

com.alibaba.com.caucho.hessian.io.SerializerFactory#readObject

由于 getDeserializer 获取到的结果为null，所以就用 _hashMapDeserializer 当做默认的序列化器，将 RolePO 转为了 HashMap 。

4. 由于 provider 返回的是一个List<RolePO>,所以解析这个集合是采用的集合序列化器com.alibaba.com.caucho.hessian.io.CollectionDeserializer，将集合解析完毕后可以看到解析结果

所以本次RPC调用返回的就是这个结果

org.apache.dubbo.rpc.protocol.dubbo.DecodeableRpcResult#handleValue

好，这就是HashMap产生的过程。而根本原因就是 provider 返回的对象是个错误的对象，这在POJO对象比较细化，且存在频繁属性拷贝的工程中比较容易遇见。POJO对象细化就是比如对应数据库的实体用PO后缀，service间传输的实体用DTO后缀，和前端交互的实体用VO后缀等，这些实体对象之间免不了存在属性拷贝的情况，如果一个对象的属性层级比较深，对象包对象的，加上再使用个浅拷贝工具的话，就会出现Bug。

所以对象属性拷贝的工具还是要选好，推荐使用Orika等支持深拷贝的工具，实在不行就使用 fastjson、gson等工具先转json字符串，再转成指定对象。