Java序列化的這三個(gè)坑千萬要小心

作者：佚名 2021-03-30 15:10:50

序列化機(jī)制允許將實(shí)現(xiàn)序列化的Java對象轉(zhuǎn)換為字節(jié)序列，這些字節(jié)序列可以保存在磁盤上，或通過網(wǎng)絡(luò)傳輸，以達(dá)到以后恢復(fù)成原來的對象。序列化機(jī)制使得對象可以脫離程序的運(yùn)行而獨(dú)立存在。

[[390519]]

前幾天看到一個(gè)2016年挺有趣的一個(gè)故障復(fù)盤，有一哥們給底層的HSF服務(wù)返回值加了一個(gè)字段，秉承著“加字段一定是安全的”這種慣性思維就直接上線了，上線后發(fā)現(xiàn)這個(gè)接口成功率直接跌0，下游的服務(wù)拋出類似下面這個(gè)異常堆棧

java.io.InvalidClassException:com.taobao.query.TestSerializable;  
 local class incompatible: stream classdesc serialVersionUID = -7165097063094245447,local class    serialVersionUID = 6678378625230229450

看到這個(gè)堆棧可能有老司機(jī)已經(jīng)反應(yīng)過來了，下面我們就看下這種異常到底是如何發(fā)生的

Java序列化與反序列化

序列化：將對象寫入到IO流中
反序列化：從IO流中恢復(fù)對象

要想有序列化的能力，得實(shí)現(xiàn)Serializable接口，就像下面的這個(gè)例子一樣：

public class SerializableTest implements Serializable {  
    private static final long serialVersionUID = -3751255153289772365L;  
}

這里面一個(gè)關(guān)鍵的點(diǎn)是serialVersionUID，JVM會(huì)在運(yùn)行時(shí)判斷類的serialVersionUID來驗(yàn)證版本一致性，如果傳來的字節(jié)流中的serialVersionUID與本地相應(yīng)類的serialVersionUID相同則認(rèn)為是一致的，可以進(jìn)行反序列化，否則就會(huì)出現(xiàn)序列化版本不一致的異常。

在上面的例子中，我們通過IDEA的插件已經(jīng)自動(dòng)為SerializableTest生成了一個(gè)serialVersionUID，如果我們不指定serialVersionUID，編譯器在編譯的時(shí)候也會(huì)根據(jù)類名、接口名、成員方法及屬性等來生成一個(gè)64位的哈希字段。

Dubbo與序列化

/dev-guide/images/dubbo-extension.jpg

圖片來源：https://dubbo.apache.org/zh/docs/v2.7/dev/design/

從Dubbo的調(diào)用鏈可以發(fā)現(xiàn)是有一個(gè)序列化節(jié)點(diǎn)的，其支持的序列化協(xié)議一共有四種：

1. dubbo序列化：阿里尚未開發(fā)成熟的高效java序列化實(shí)現(xiàn)，阿里不建議在生產(chǎn)環(huán)境使用它

2. hessian2序列化：hessian是一種跨語言的高效二進(jìn)制序列化方式。但這里實(shí)際不是原生的hessian2序列化，而是阿里修改過的hessian lite，它是dubbo RPC默認(rèn)啟用的序列化方式

3. json序列化：目前有兩種實(shí)現(xiàn)，一種是采用的阿里的fastjson庫，另一種是采用dubbo中自己實(shí)現(xiàn)的簡單json庫，但其實(shí)現(xiàn)都不是特別成熟，而且json這種文本序列化性能一般不如上面兩種二進(jìn)制序列化。

4. java序列化：主要是采用JDK自帶的Java序列化實(shí)現(xiàn)，性能很不理想。

從那個(gè)帖子看當(dāng)時(shí)HSF服務(wù)提供集群設(shè)置的序列化方式是java序列化，而不是像現(xiàn)在一樣默認(rèn)hessian2，如果在RPC中使用了Java序列化，那下面的這三個(gè)坑一定注意不要踩

類實(shí)現(xiàn)了Serializable接口，但是卻沒有指定serialVersionUID

我們之前在文中提過，如果實(shí)現(xiàn)了Serializable的類沒有指定serialVersionUID，編譯器編譯的時(shí)候會(huì)根據(jù)類名、接口名、成員方法及屬性等來生成一個(gè)64位的哈希字段，這就決定了這個(gè)類在序列化上一定不是向前兼容的，前文中的那個(gè)故障就是踩了這個(gè)坑。我們在本地模擬一下這個(gè)case:

假如我們先有Student這樣的一個(gè)類

public class Student implements Serializable {  
    private static int startId = 1000;  
    private int id;  
    public Student() {  
        id = startId ++;  
    }  
}

我們將其序列化到磁盤：

private static void serialize() {  
    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類加一個(gè)字段

public class Student implements Serializable {  
    private static int startId = 1000;  
    private int id;  
  // 注意這里我們已經(jīng)加了一個(gè)屬性  
    private String name;  
    public Student() {  
        id = startId ++;  
    }  
}

我們再去解碼，發(fā)現(xiàn)程序會(huì)拋出異常：

java.io.InvalidClassException: com.idealism.base.Student; local class incompatible: stream classdesc serialVersionUID = -1534228028811562580, local class serialVersionUID = 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)

其實(shí)到這里我們就完整的模擬了前文中的那個(gè)故障，其根因是RPC的參數(shù)實(shí)現(xiàn)了Serializable接口，但是沒有指定serialVersionUID，編譯器會(huì)根據(jù)類名、接口名、成員方法及屬性等來生成一個(gè)64位的哈希字段，當(dāng)服務(wù)端類升級之后導(dǎo)致了服務(wù)端發(fā)送給客戶端的字節(jié)流中的serialVersionUID發(fā)生了改變，因此當(dāng)客戶端反序列化去檢查serialVersionUID字段的時(shí)候發(fā)現(xiàn)發(fā)生了變化被判定了異常。

父類實(shí)現(xiàn)了Serializable接口，并且指定了serialVersionUID但是子類沒有指定serialVersionUID

我們對前面的例子中的Student類稍微改一下

public class Student extends Base{  
    private static int startId = 1000;  
    private int id;  
    public Student() {  
        id = startId ++;  
    }  
}

其中父類長這樣：

public class Base implements Serializable {  
    private static final long serialVersionUID = 218886242758597651L;  
    private Date gmtCreate;  
}

如果我們按照之前的討論在本地進(jìn)行一次序列化和反序列化，程序依然拋異常：

java.io.InvalidClassException: com.idealism.base.Student; local class incompatible: stream classdesc serialVersionUID = 1049562984784675762, local class serialVersionUID = 7566357243685852874 
 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)

我們在設(shè)計(jì)類的時(shí)候公共屬性要放到基類，這條經(jīng)驗(yàn)指導(dǎo)放到這個(gè)case中仍然不太正確，而且這個(gè)case比上一個(gè)還要隱蔽，問題出主要是通過IDEA插件生成的serialVersionUID的修飾符是pivate導(dǎo)致這個(gè)字段在子類中不可見，子類中的serialVersionUID仍然是編譯器自動(dòng)生成的。當(dāng)然可以把父類中serialVersionUID的改為非private來解這個(gè)問題，不過我仍然建議每個(gè)有序列化需求的類都顯式指定serialVersionUID的值。

如果序列化遇到類之間的組合或者繼承關(guān)系，則Java按照下面的規(guī)則處理：

當(dāng)一個(gè)對象的實(shí)例變量引用其他對象，序列化該對象時(shí)也把引用對象進(jìn)行序列化，而不管其是否實(shí)現(xiàn)了Serializable接口
如果子類實(shí)現(xiàn)了Serializable，則序列化時(shí)只序列化子類，不會(huì)序列化父類中的屬性
如果父類實(shí)現(xiàn)了Serializable，則序列化時(shí)子類和父類都會(huì)被序列化，異常場景如本例所指

還有一點(diǎn)要注意：如果類的實(shí)例中有靜態(tài)變量，改屬性不會(huì)被序列化和反序列化

類中有枚舉值

《阿里巴巴開發(fā)規(guī)約》中有這么一條：

【強(qiáng)制】二方庫例可以定義枚舉類型，參數(shù)可以使用枚舉類型，但是接口返回值不允許使用枚舉類型或者包含枚舉類型的POJO對象。

說明：由于升級原因，導(dǎo)致雙方的枚舉類不盡相同，在接口解析，類反序列化時(shí)出現(xiàn)異常

這里會(huì)出現(xiàn)這樣一個(gè)限制的原因是Java對枚舉的序列化和反序列化采用完全不同的策略。序列化的結(jié)果中僅包含枚舉的名字，而不包含枚舉的具體定義，反序列化的時(shí)候客戶端從序列化結(jié)果中讀取枚舉的name，然后調(diào)用java.lang.Enum#valueOf根據(jù)本地的枚舉定義獲取具體的枚舉值。

我們?nèi)匀挥弥暗拇a舉例：

public class Student implements Serializable {  
    private static final long serialVersionUID = 2528736437985230667L;      
    private static int startId = 1000;  
    private int id;  
    private String name;  
    // 新增字段，校服尺碼，其類型是一個(gè)枚舉  
    private SchoolUniformSizeEnum schoolUniformSize;  
    public Student() {  
        id = startId ++;  
    }  
}

假如學(xué)生這個(gè)類中新增了一個(gè)校服尺碼的枚舉值

public enum SchoolUniformSizeEnum {  
    SMALL,  
    MEDIUM,  
    LARGE  
}

假如服務(wù)端此時(shí)對這個(gè)枚舉進(jìn)行了升級，但是客戶端的二方包中仍然只有三個(gè)值：

public enum SchoolUniformSizeEnum {  
    SMALL,  
    MEDIUM,  
    LARGE,  
    OVERSIZED  
}

如果服務(wù)端有邏輯給客戶端返回了這個(gè)新增的枚舉值：

private static void serialize() {  
    try {  
        Student student = new Student();  
        // 服務(wù)端升級了枚舉  
        student.setSchoolUniformSize(SchoolUniformSizeEnum.OVERSIZED);  
        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();  
    }  
}

因?yàn)榭蛻舳说亩桨€沒有升級，所以當(dāng)客戶端讀到這個(gè)新的字節(jié)流并序列化的時(shí)候會(huì)因?yàn)檎也坏綄?yīng)的枚舉值而拋異常。

java.io.InvalidObjectException: enum constant OVERSIZED does not exist in class com.idealism.base.SchoolUniformSizeEnum  
 at java.io.ObjectInputStream.readEnum(ObjectInputStream.java:2130)  
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1659)  
 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2403)  
 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2327)  
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2185)  
 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:36)  
 at com.idealism.base.SerializableTest.main(SerializableTest.java:9)

2016年的故障還值得我們?nèi)?fù)盤嗎

看到這里可能有小伙伴覺得，我這輩子都不可能去修改Dubbo的序列化方式，就讓他hessian2到底吧，我不得不承認(rèn)確實(shí)是這樣的。如果把序列化光限制在RPC這一個(gè)場景，未免有些狹隘。以阿里為例，其分布式緩存中間件Tair的寫接口可接受的入?yún)⒕褪且粋€(gè)Serializable，好在我們平常往緩存中塞東西都是以String為key的，但萬一有前人真的用了一個(gè)實(shí)現(xiàn)了Serializable的類，并且恰好沒有指定serialVersionUID，那新來的你不就正好踩坑了么。所以在遇到序列化的地方需要仔細(xì)查看有沒有踩文章中列出來的三個(gè)坑。

責(zé)任編輯：龐桂玉來源： Java知音