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

您的位置：
门户
>> 文章精选
>> 软件开发专栏
>> Java
>> 查看资讯

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

发表于：2021-4-14 09:34

字体：大中小 | 上一篇 | 下一篇 | 我要投稿

作者：佚名来源：今日头条

软件开发

Java

　　前几天看到一个2016年挺有趣的一个故障复盘，有一哥们给底层的HSF服务返回值加了一个字段，秉承着“加字段一定是安全的”这种惯性思维就直接上线了，上线后发现这个接口成功率直接跌0，下游的服务抛出类似下面这个异常堆栈。

　　java.io.InvalidClassException:com.taobao.query.TestSerializable;

　　local class incompatible: stream classdesc serialVersionUID = -7165097063094245447,localclassserialVersionUID= 6678378625230229450

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

　　Java序列化与反序列化

　　· 序列化：将对象写入到IO流中

　　· 反序列化：从IO流中恢复对象

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

　　要想有序列化的能力，得实现Serializable接口，就像下面的这个例子一样：

　　public classSerializableTestimplementsSerializable{

　　private static final long serialVersionUID = -3751255153289772365L;

　　}

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

　　在上面的例子中，我们通过IDEA的插件已经自动为SerializableTest生成了一个serialVersionUID，如果我们不指定serialVersionUID，编译器在编译的时候也会根据类名、接口名、成员方法及属性等来生成一个64位的哈希字段。

　　Dubbo与序列化

　　图片来源：

　　https://dubbo.apache.org/zh/docs/v2.7/dev/design/

　　从Dubbo的调用链可以发现是有一个序列化节点的，其支持的序列化协议一共有四种：

　　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位的哈希字段，这就决定了这个类在序列化上一定不是向前兼容的，前文中的那个故障就是踩了这个坑。我们在本地模拟一下这个case:

　　假如我们先有Student这样的一个类：

　　public classStudentimplementsSerializable{

　　private static int startId = 1000;

　　private int id;

　　publicStudent {

　　id = startId ++;}}

　　我们将其序列化到磁盘：

　　privatestaticvoidserialize {

　　try {

　　Student student = new Student;

　　FileOutputStream fileOut =new FileOutputStream("/tmp/student.ser");

　　ObjectOutputStream out = new ObjectOutputStream(fileOut);

　　out.writeObject(student);

　　out.close;

　　fileOut.close;System.out.printf("Serialized data is saved in /tmp/student.ser");

　　} catch (

　　IOException i) {i.printStackTrace;}}

　　然后给Student类加一个字段：

　　public classStudentimplementsSerializable{

　　private static int startId = 1000;

　　private int id;

　　// 注意这里我们已经加了一个属性

　　private String name;

　　publicStudent {

　　id = startId ++;

　　}

　　我们再去解码，发现程序会抛出异常：

　　java.io.InvalidClassException: com.idealism.base.Student; local class incompatible: stream classdesc serialVersionUID = -1534228028811562580, local classserialVersionUID= 630353564791955009

　　at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:699)

　　at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2001)

　　at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1848)

　　at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2158)

　　at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1665)

　　at java.io.ObjectInputStream.readObject(ObjectInputStream.java:501)

　　at java.io.ObjectInputStream.readObject(ObjectInputStream.java:459)

　　at com.idealism.base.SerializableTest.deserialize(SerializableTest.java:34)

　　at com.idealism.base.SerializableTest.main(SerializableTest.java:9)

　　其实到这里我们就完整的模拟了前文中的那个故障，其根因是RPC的参数实现了Serializable接口，但是没有指定serialVersionUID，编译器会根据类名、接口名、成员方法及属性等来生成一个64位的哈希字段，当服务端类升级之后导致了服务端发送给客户端的字节流中的serialVersionUID发生了改变，因此当客户端反序列化去检查serialVersionUID字段的时候发现发生了变化被判定了异常。

　　父类实现了Serializable接口，并且指定了serialVersionUID但是子类没有指定serialVersionUID

　　我们对前面的例子中的Student类稍微改一下:

　　public classStudentextendsBase{

　　private static int startId = 1000;

　　private int id;

　　publicStudent {

　　id = startId ++;}}

　　其中父类长这样：

　　public classBaseimplementsSerializable{

　　private static final long serialVersionUID = 218886242758597651L;

　　private Date gmtCreate;

　　}

　　如果我们按照之前的讨论在本地进行一次序列化和反序列化，程序依然抛异常：

　　java.io.InvalidClassException: com.idealism.base.Student; local class incompatible: stream classdesc serialVersionUID = 1049562984784675762, local classserialVersionUID= 7566357243685852874