Java序列化的這三個坑千萬要小心
前幾天看到一個2016年挺有趣的一個故障復盤，有一哥們給底層的HSF服務返回值加了一個字段，秉承著“加字段一定是安全的”這種慣性思維就直接上線了，上線后發現這個接口成功率直接跌0，下游的服務拋出類似下面這個異常堆棧
- java.io.InvalidClassException:com.taobao.query.TestSerializable;
- local class incompatible: stream classdesc serialVersionUID = -7165097063094245447,local class serialVersionUID = 6678378625230229450
看到這個堆棧可能有老司機已經反應過來了，下面我們就看下這種異常到底是如何發生的
Java序列化與反序列化
- 序列化：將對象寫入到IO流中
- 反序列化：從IO流中恢復對象
序列化機制允許將實現序列化的Java對象轉換為字節序列，這些字節序列可以保存在磁盤上，或通過網絡傳輸，以達到以后恢復成原來的對象。序列化機制使得對象可以脫離程序的運行而獨立存在。
要想有序列化的能力，得實現Serializable接口，就像下面的這個例子一樣：
- public class SerializableTest implements Serializable {
- private static final long serialVersionUID = -3751255153289772365L;
- }
這里面一個關鍵的點是serialVersionUID，JVM會在運行時判斷類的serialVersionUID來驗證版本一致性，如果傳來的字節流中的serialVersionUID與本地相應類的serialVersionUID相同則認為是一致的，可以進行反序列化，否則就會出現序列化版本不一致的異常。
在上面的例子中，我們通過IDEA的插件已經自動為SerializableTest生成了一個serialVersionUID，如果我們不指定serialVersionUID，編譯器在編譯的時候也會根據類名、接口名、成員方法及屬性等來生成一個64位的哈希字段 。
Dubbo與序列化
/dev-guide/images/dubbo-extension.jpg
圖片來源：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 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類加一個字段
- public class Student implements Serializable {
- private static int startId = 1000;
- private int id;
- // 注意這里我們已經加了一個屬性
- private String name;
- public Student() {
- id = startId ++;
- }
- }
我們再去解碼，發現程序會拋出異常：
- 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)
其實到這里我們就完整的模擬了前文中的那個故障，其根因是RPC的參數實現了Serializable接口，但是沒有指定serialVersionUID，編譯器會根據類名、接口名、成員方法及屬性等來生成一個64位的哈希字段，當服務端類升級之后導致了服務端發送給客戶端的字節流中的serialVersionUID發生了改變，因此當客戶端反序列化去檢查serialVersionUID字段的時候發現發生了變化被判定了異常。
父類實現了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;
- }
如果我們按照之前的討論在本地進行一次序列化和反序列化，程序依然拋異常：
- 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)
我們在設計類的時候公共屬性要放到基類，這條經驗指導放到這個case中仍然不太正確，而且這個case比上一個還要隱蔽，問題出主要是通過IDEA插件生成的serialVersionUID的修飾符是pivate導致這個字段在子類中不可見，子類中的serialVersionUID仍然是編譯器自動生成的。當然可以把父類中serialVersionUID的改為非private來解這個問題，不過我仍然建議每個有序列化需求的類都顯式指定serialVersionUID的值。
如果序列化遇到類之間的組合或者繼承關系，則Java按照下面的規則處理：
- 當一個對象的實例變量引用其他對象，序列化該對象時也把引用對象進行序列化，而不管其是否實現了Serializable接口
- 如果子類實現了Serializable，則序列化時只序列化子類，不會序列化父類中的屬性
- 如果父類實現了Serializable，則序列化時子類和父類都會被序列化，異常場景如本例所指
還有一點要注意：如果類的實例中有靜態變量，改屬性不會被序列化和反序列化
類中有枚舉值
《阿里巴巴開發規約》中有這么一條：
【強制】二方庫例可以定義枚舉類型，參數可以使用枚舉類型，但是接口返回值不允許使用枚舉類型或者包含枚舉類型的POJO對象。
說明：由于升級原因，導致雙方的枚舉類不盡相同，在接口解析，類反序列化時出現異常
這里會出現這樣一個限制的原因是Java對枚舉的序列化和反序列化采用完全不同的策略。序列化的結果中僅包含枚舉的名字，而不包含枚舉的具體定義，反序列化的時候客戶端從序列化結果中讀取枚舉的name，然后調用java.lang.Enum#valueOf根據本地的枚舉定義獲取具體的枚舉值。
我們仍然用之前的代碼舉例：
- public class Student implements Serializable {
- private static final long serialVersionUID = 2528736437985230667L;
- private static int startId = 1000;
- private int id;
- private String name;
- // 新增字段，校服尺碼，其類型是一個枚舉
- private SchoolUniformSizeEnum schoolUniformSize;
- public Student() {
- id = startId ++;
- }
- }
假如學生這個類中新增了一個校服尺碼的枚舉值
- public enum SchoolUniformSizeEnum {
- SMALL,
- MEDIUM,
- LARGE
- }
假如服務端此時對這個枚舉進行了升級，但是客戶端的二方包中仍然只有三個值：
- public enum SchoolUniformSizeEnum {
- SMALL,
- MEDIUM,
- LARGE,
- OVERSIZED
- }
如果服務端有邏輯給客戶端返回了這個新增的枚舉值：
- private static void serialize() {
- try {
- Student student = new Student();
- // 服務端升級了枚舉
- 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();
- }
- }
因為客戶端的二方包還沒有升級，所以當客戶端讀到這個新的字節流并序列化的時候會因為找不到對應的枚舉值而拋異常。
- 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年的故障還值得我們去復盤嗎
看到這里可能有小伙伴覺得，我這輩子都不可能去修改Dubbo的序列化方式，就讓他hessian2到底吧，我不得不承認確實是這樣的。如果把序列化光限制在RPC這一個場景，未免有些狹隘。以阿里為例，其分布式緩存中間件Tair的寫接口可接受的入參就是一個Serializable，好在我們平常往緩存中塞東西都是以String為key的，但萬一有前人真的用了一個實現了Serializable的類，并且恰好沒有指定serialVersionUID，那新來的你不就正好踩坑了么。所以在遇到序列化的地方需要仔細查看有沒有踩文章中列出來的三個坑。
