Kryo序列化在分布式处理情景下的问题
最近在dubbo的issue列表里看到了这样一个issue，主要描述的是在某种情况下使用kryo作为序列化方式会报错，这个issue下面，另外一位来自阿里的Committer也给了问题出现的原因，这个问题还是非常有意思的，这里顺便看一下kryo的序列化方式，复现一下这个问题。
issue下面其实已经贴出了一个demo可以用来复现上述的问题。但是在我的机器上一直不work，我就没有用他的demo了。这里我准备一个更简单的demo让大家更清楚的了解这个问题，先看看我们的类：
Server：启动的main函数代码可以从dubbo-demo下面找一个provider抄过来即可，主要看配置文件：
Client：代码就不看了，直接看配置：
PhoneService：这里只贴PhoneService的实现、Phone类还有User类，实在是太简单了：
publicclassPhoneServiceImplimplementsPhoneService{
publicPhonegetPhone(){
returnnewPhone();
}
}
publicclassPhoneimplementsSerializable{
privatestaticfinallongserialVersionUID = -8578553481899481234L;
privateString color ="black";
publicStringgetColor(){
returncolor;
}
publicvoidsetColor(String color){
this.color = color;
}
}
publicclassUserimplementsSerializable{
privatestaticfinallongserialVersionUID =2345729265494289413L;
privateString name ="xyh";
publicStringgetName(){
returnname;
}
publicvoidsetName(String name){
this.name = name;
}
}
Optimizer：这里把两个Optimizer都贴出来：
publicclassUserOptimizerimplementsSerializationOptimizer{
publicCollectiongetSerializableClasses(){
returnCollections.singletonList(User.class);
}
}
publicclassPhoneOptimizerimplementsSerializationOptimizer{
publicCollectiongetSerializableClasses(){
returnCollections.singletonList(Phone.class);
}
}
代码特别简单，就是简单的引用和暴露，唯一特别的地方就是我们设置了我们的optimizer，服务端用PhoneOptimizer而客户端使用UserOptimizer，并且我们使用Kryo作为序列化方式。
启动一下程序，启动Server没什么特别的，正常启动。启动Client的时候报错：
PhoneService ps = (PhoneService) context.getBean("phoneService");
Phone p = ps.getPhone();
错误：
Exception in thread"main"java.lang.ClassCastException: dubbo.action.domain.User cannot be cast to dubbo.action.domain.Phone
at com.alibaba.dubbo.common.bytecode.proxy0.getPhone(proxy0.java)
at dubbo.action.ServerAndConsumer.main(ServerAndConsumer.java:20)
我们明明在PhoneService里返回的是Phone类，怎么就cast exception了呢。带着这个问题我们看下源码。
要解决这个问题，我们要先看看Optimizer是怎么起作用的，这个部分的代码是dubbo重启维护之后，从dubbox中合并过来的，代码在DubboProtocol#optimizeSerialization：
// 加载我们配置中的 optimizer="xxx.PhoneOptimezer" 这个类
Class clazz = Thread.currentThread().getContextClassLoader().loadClass(className);
if(!SerializationOptimizer.class.isAssignableFrom(clazz)) {
// throw exception...
}
SerializationOptimizer optimizer = (SerializationOptimizer) clazz.newInstance();
if(optimizer.getSerializableClasses() ==null) {
return;
}
// 把我们PhoneOptimezer中的类注册到SerializableClassRegistry中
for(Class c : optimizer.getSerializableClasses()) {
SerializableClassRegistry.registerClass(c);
}
optimizers.add(className);
SerializableClassRegistry的的内容非常简单，不多说了，看下SerializableClassRegistry的getRegisteredClasses调用方，在AbstractKryoFactory里（注意Fst序列化方式中也用到了类似的地方，我们先不看，只看kryo相关）：
for(Class clazz : SerializableClassRegistry.getRegisteredClasses()) {
kryo.register(clazz);
}
其实就是把我们的Phone和User两个domain类注册到了kryo里。
源码分析——kryo序列化
现在我们知道了这个Optimizer的作用之后，就要看看为什么会报错了。这里我们要从客户端和服务端两个端看起，先看看服务端写出去了什么东西，再看看客户端收到了什么东西。
这里我需要跟大家说明一下kryo的两种写class信息的序列化方式：
写入的是class name，默认情况下就是这种写class的方式，性能不好，因为写入的数据比较大，无论是传输还是写入都慢。
写入的是id，对于我们注册过的类（调用过kryo.register(Class type)），我们写入的class信息是一个id，性能好，写入的数据量小，写入和传输都快。
我们下面看看我们如何出的错。
我会带着大家一起跟踪整个过程，先以debug的方式运行服务端，再以普通方式运行客户端。我们看看我们到底写出去个什么东西，我们既然要看写出去个什么东西，当然要看我们encode相关的部分，这里我们encode的是response，代码入口在DubboCountCodec#encode，我们跳过一些信息，看kryo相关的内容，入口在KryoObjectOutput#writeObject，追进去：
可以看到我们写出去的确实是一个Phone对象，我们看看writeClass方法，这个主要是把类的信息写到流里，最终走到DefaultClassResolver#writeClass里：
这里要注意，我们发现我们走到了registration.getId() != NAME这个分支里，结果我们实际上并没有向流里写什么信息，只是写了一个id（output.writeVarInt），这是为什么，我们要追溯一下Kryo#getRegistration(java.lang.Class)这个方法，这个方法底层是从classResolver的classToRegistration这个map中获取一个Registration，那我们就看看这个classToRegistration中的值是从哪来的，看下使用这个字段的地方，我们找到了线索：
DefaultClassResolver#register方法中使用了put。那我们可以很轻松的联想到我们之前在启动dubbo的时候，注册了我们的Phone.class到kryo中。看下这个register方法：
if(registration.getId() != NAME) {
// 如果id不是-1，就把我们的registration放到一个map里，键就是id
idToRegistration.put(registration.getId(), registration);
}elseif(TRACE) {
// sth...
}
classToRegistration.put(registration.getType(), registration);
if(registration.getType().isPrimitive())
classToRegistration.put(getWrapperClass(registration.getType()), registration);
returnregistration;
我们在使用kryo.register(Class type)这个方法时，其实默认调用的是这样的：return classResolver.register(new Registration(type, serializer, getNextRegistrationId()));，注意这里getNextRegistrationId，实际上就是从idToRegistration这个字段里取最大的id，然后加1后返回。kryo默认会注册五十多个类，都是java原生的类，比如Boolean和Integer。
我们写完了class信息之后，就是实际写入我们的对象的具体信息了，比如我们的color字段。这里不说了，跟我们的问题关系不大。
其实说到这里，基本上很多朋友也能猜到问题了，我们在服务端注册的Phone.class，但是在客户端，我们注册的User.class，而二者对应的id是同一个，这种情况下就会出现问题。为什么id是同一个，这里我说一下，之前我们说过，kryo会默认注册五十多个jdk原生的类，那么客户端和服务端的kryo绝对是两个对象，在这两个kryo都没有注册其他类的情况下，Phone和User这两个类在两个kryo中的位置是一样的。
我们猜完了，就要实际看看效果了。这里我们用普通方式运行服务端，debug方式运行客户端，看看我们客户端收到数据以后，为什么报错。
上面是encode这里就是decode了，decode的就是响应信息，最终和我们kryo相关的地方在KryoObjectInput#readObject()，调用的是kryo的readClassAndObject方法：
我们看看读取出来的是什么：
果然是一个User对象。至此我们就知道为什么会class cast exception了。
后记
这里可能有人会说，你并没有复现issue中提到的场景啊，issue里说报出来的是另外一个错误。这里其实本质是一样的，如果你看得懂这篇文章，应该会明白。说白了，kryo中有个注册表，标记id - class的关系。
但是在分布式系统中，两端的这个id - class表关系一旦错误，就会出现各种问题，这是kryo在分布式系统中的局限性，下面借用一下解决这个issue的这位大神的图，一目了然：
这个部分与我们的问题无关，有兴趣的可以看下，没兴趣的直接跳过即可。
kryo初始化对象很特别，使用的是ConstructorAccess这个类。我们看下ConstructorAccess#get方法，先看头部：
Class enclosingType = type.getEnclosingClass();
booleanisNonStaticMemberClass = enclosingType !=null&& type.isMemberClass() && !Modifier.isStatic(type.getModifiers());
String className = type.getName();
// 拼装类名，我们的场景中就是 xxx.PhoneConstructorAccess
String accessClassName = className +"ConstructorAccess";
if(accessClassName.startsWith("java."))
accessClassName ="reflectasm."+ accessClassName;
Class accessClass;
AccessClassLoader loader = AccessClassLoader.get(type);
try{
// 尝试加载xxx.PhoneConstructorAccess
accessClass = loader.loadClass(accessClassName);
catch(xxx) {
xxx
}
很奇怪，居然尝试去加载一个不存在的类，我们每个类进来，都会尝试加载ClassNameConstructorAccess这个类。我们的例子中，当然不存在这个PhoneConstructorAccess类，继续看如果捕捉异常会怎样：
在捕捉到异常之后，使用ASM重新创建了一个ConstructorAccess子类，并且这个新类的newInstance方法，返回的就是我们的User（或者Phone）对象的实例。
这里我们可以看到，实际上kryo是通过一个额外的、通过ASM生成的类，来进行对象的初始化的。为什么用这种方式，不甚了解，有了解的朋友可以告知我一下。
在此我向大家推荐一个架构学习交流群。交流学习群号：938837867 暗号：555 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备