一、概述
笔者支持过程中多次发现诡异的Dubbo接口异常问题，抓耳挠腮最后定位到代码上和代码外的原因，事后只感觉脑瓜子嗡嗡的。考虑到这不是第一次，也绝不会是最后一次出现类似问题，下面笔者将尽可能详细的梳理、总结一下该问题的现象和本质。
二、问题是什么？
在DubboRPC+Protostuff序列化场景下，如果DTO中的字段使用了非标集合类型，可能会导致接口出入参为null或error，进一步导致业务受损。
该问题的产生存在如下前提或者门槛：
-
接口使用的是DubboRPC；
-
接口使用的是Protostuff序列化；
-
DTO中声明了类型模糊的字段；
-
类型模糊的字段赋值了非标集合类型数据。
DTO中声明了类型模糊的字段
所谓类型模糊的字段，指的是在DTO中存在没法一眼判断出运行时具体类型的字段（静态分析）。听起来还是很抽象是吧？我们看下面的例子：
例1
例2
例3
相信读者在看到上述案例的时候，肯定没法一口笃定字段obj3在运行时具体的、实际的类型是啥吧？如果机智如你肉眼都无法识别、判定这个字段的类型，那死板的序列化库(lib)代码更没法识别、判定。
你看到都迷糊，更别提代码了。
DTO中赋值了非标集合类型数据
要解释非标集合类或者非标准集合类，首先我们需要对齐标准集合类。
标准集合类指的是常见的、jdk标准库内自带的集合类。一般在java.util包下，实现了顶层的、公共的Interface，有公开的的构造方法。常见的有：
io.protostuff.CollectionSchema.MessageFactories
三、为什么会有这个问题？
如上述，当DTO中存在类型模糊的字段时，常见的序列化框架如Protostuff，没有办法根据类的定义和反射得到准确的数据类型。为了在序列化后(object -> byte[ ])能正常的、按预期完成反序列化(byte[ ] -> object)，一般会在byte[ ]中添加类型提示，以辅助反序列化过程正常进行。
以如下DTO为例：
假设按如下代码构造上述Req：
我们用类json格式来进行序列化、反序列化推演，如果不做任何处理，序列化(object -> byte[ ])后的结果如下：
不管是json这种文本格式，还是Protostuff这种二进制格式，序列化产物(byte[ ])在逻辑结构上是相似的~
可以看到，序列化产物上没有任何类型信息(运行时信息)，同时我们上面也看到，DemoReq类的obj3字段上也没有任何具体的类型提示(编译期信息)。那么对端收到上述数据进行反序列化(byte[ ] -> object)时，就无法恢复出正确的、类型和上游一致的字段对象。
Protostuff希望解决这个问题！Protostuff希望达成如下效果：
换句话说，Protostuff想保证：客户端的一个对象被序列化(object -> byte[ ])、传输到对端反序列化后(byte[ ] -> object)，对端可以安全的对这个对象进行equals判断并以此进行业务逻辑处理。
为了实现这个目的，Protostuff在序列化产物上做了一些黑盒的、对上层业务透明的处理。在序列化产物的字段结构上添加类型提示，具体到java语言平台就是类的全限定名。
如上图，Protostuff在序列化产物(object -> byte[ ])中，将类型信息java.util.ArrayList关联到obj3字段上传输到对端，对端在反序列化(byte[ ] -> object)时，如果无法通过反射在DTO类字段(静态的、编译期信息)上提取数据类型时，会从序列化产物中提取字段类型，利用反射或硬编码创建实例后，再进行后续的数据解析、提取。
这就出现了一个问题：
如果在DTO中模糊字段上赋值了对端(另一个进程)不存在的类型或无法通过反射实例化的类型，那对象序列化、传输到对端后，对端进行反序列化(byte[] -> object)的过程就会异常！
对端（另一个进程）不存在的类型
如上图，Foo类是一个静态私有类，不在Api Jar中，传输到对端(另一个进程)后，对端反序列化时可能找不到该类(ClassNotFoundError)。
无法通过反射实例化的类型
如上图，Bar类是一个内部类，只能寄生于外部类，无法被单独实例化。对端反序列化时可能会找不到构造方法(NoSuchMethodException)或类状态不完整无法正常使用。
技术上来说，所有类都有手段进行实例化，比如使用sun.misc.Unsafe#allocateInstance,只是因为绕过了构造方法，实例化出来的类状态是不完整的，不能正常使用。
四、怎么处理这个问题？
调整序列化方案
调整到hessian2、json等代码质量更好、使用范围更广、社区更活跃的序列化方式~
需要注意，存量的很多业务接口依赖了Protostuff的模糊类型序列化特性，不能贸然切换到json、hessian2，需要进行完整的回归测试才能发布到生产环境。
包容它、迁就它
千言万语汇成一句话：避免在DTO中传输非标集合类型数据，或者传输之前进行标准集合类型转换！
你一定想问：为什么中间件同学不能向前一步cover这个问题，还得我们使用者注意，中间件同学的担当、责任感呢？
您的拷问很有道理！但是没有办法，或许Protostuff是为了追求极致的性能而完全抛弃了代码可读性、可维护性，中间件同学完全改不动、不敢改。
日常支持过程中，我们发现常用的、会产生非标集合类型数据的工具库、工具方式包括但不限于：
欢迎大家随时反馈相关的使用场景~
标准库工具类
java.util.ArrayList#subList
ArrayList<Integer> list = Lists.newArrayList(1, 2, 3);List<Integer> obj3 = list.subList(1, 2);
处置方法
ArrayList<Integer> list = Lists.newArrayList(1, 2, 3);List<Integer> obj3 = list.subList(1, 2);List<Integer> obj4 = new ArrayList<>(obj3);
lang3库工具类
org.apache.commons.collections.FastArrayList.SubList#subList
List<Integer> list = new FastArrayList(1, 2, 3);List<Integer> obj3 = list.subList(1, 2);
处置方法
ArrayList<Integer> list = Lists.newArrayList(1, 2, 3);List<Integer> obj3 = list.subList(1, 2);List<Integer> obj4 = new ArrayList<>(obj3);
guava库工具类
com.google.common.collect.Lists#transform
ArrayList<Integer> list = Lists.newArrayList(1, 2, 3);List<Integer> obj3 = Lists.transform(list, it -> it);
处置方法
ArrayList<Integer> list = Lists.newArrayList(1, 2, 3);List<Integer> obj3 = Lists.transform(list, it -> it);List<Integer> obj4 = new ArrayList<>(obj3);
com.google.common.collect.Lists#partition
ArrayList<Integer> list = Lists.newArrayList(1, 2, 3, 4);List<List<Integer>> obj3 = Lists.partition(list,2);
处置方法
ArrayList<Integer> list = Lists.newArrayList(1, 2, 3, 4);List<List<Integer>> lists = Lists.partition(list, 2).stream().map(Lists::newLinkedList).collect(Collectors.toList());
五、总结
以上，笔者基于日常排障&答疑过程中的沉淀和深入到Protostuff源码的细节思考，总结了DubboRPC+Protostuff场景下常见的接口出参、入参为null或error的现象、本质和解决方案。笔者在这只能做到提纲挈领、抛砖引玉，希望可以帮大家理清关键环节和概念，更好的使用DubboRPC支持业务~
*文/羊羽
本文属得物技术原创，更多精彩文章请看：得物技术官网
未经得物技术许可严禁转载，否则依法追究法律责任！
