序列化的这三个坑千万要小心

这个堆栈可能有老司机已经反应过来了，下面我们就看下这种异常到底是如何发生的

Java序列化与反序列化

•  序列化：将对象写入到IO流中
•  反序列化：从IO流中恢复对象

序列化机制允许将实现序列化的Java对象转换为字节序列，这些字节序列可以保存在磁盘上，或通过网络传输，以达到以后恢复成原来的对象。序列化机制使得对象可以脱离程序的运行而独立存在。

要想有序列化的能力，得实现Serializable接口，就像下面的这个例子一里面一个关键的点是serialVersionUID，JVM会在运行时判断类的serialVersionUID来验证版本一致性，如果传来的字节流中的serialVersionUID与本地相应类的serialVersionUID相同则认为是一致的，可以进行反序列化，否则就会出现序列化版本不一致的异常。

在上面的例子中，我们通过IDEA的插件已经自动为SerializableTest生成了一个serialVersionUID，如果我们不指定serialVersionUID，编译器在编译的时候也会根据类名、接口名、成员方法及属性等来生成一个64位的哈希字段 。o的调用链可以发现是有一个序列化节点的，其支持的序列化协议一共有四种：

  1.  dubbo序列化：阿里尚未开发成熟的高效java序列化实现，阿里不建议在生产环境使用它

  2.  hessian2序列化：hessian是一种跨语言的高效二进制序列化方式。但这里实际不是原生的hessian2序列化，而是阿里修改过的hessian lite，它是dubbo RPC默认启用的序列化方式

  3.  json序列化：目前有两种实现，一种是采用的阿里的fastjson库，另一种是采用dubbo中自己实现的简单json库，但其实现都不是特别成熟，而且json这种文本序列化性能一般不如上面两种二进制序列化。

  4.  java序列化：主要是采用JDK自带的Java序列化实现，性能很不理想。

从那个帖子看当时HSF服务提供集群设置的序列化方式是java序列化，而不是像现在一样默认hessian2，如果在RPC中使用了Java序列化，那下面的这三个坑一定注意不要踩

类实现了Serializable接口，但是却没有指定serialVersionUID

我们之前在文中提过，如果实现了Serializable的类没有指定serialVersionUID，编译器编译的时候会根据类名、接口名、成员方法及属性等来生成一个64位的哈希字段，这就决定了这个类在序列化上一定不是向前兼容的，前文中的那个故障就是踩了这个坑

（编辑：我爱制作网_潮州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!