作為一名Java開發(fā)，我為什么建議你在開發(fā)中避免使用Java序列化?

如今大部分的后端服務(wù)都是基于微服務(wù)架構(gòu)實(shí)現(xiàn)的，服務(wù)按照業(yè)務(wù)劃分被拆分，實(shí)現(xiàn)了服務(wù)的解耦，同時(shí)也帶來了一些新的問題，比如不同業(yè)務(wù)之間的通信需要通過接口實(shí)現(xiàn)調(diào)用。兩個(gè)服務(wù)之間要共享一個(gè)數(shù)據(jù)對(duì)象，就需要從對(duì)象轉(zhuǎn)換成二進(jìn)制流，通過網(wǎng)絡(luò)傳輸，傳送到對(duì)方服務(wù)，再轉(zhuǎn)換成對(duì)象，供服務(wù)方法調(diào)用。這個(gè)編碼和解碼的過程我們稱之為序列化和反序列化。

在高并發(fā)系統(tǒng)中，序列化的速度快慢，會(huì)影響請(qǐng)求的響應(yīng)時(shí)間，序列化后的傳輸數(shù)據(jù)體積大，會(huì)導(dǎo)致網(wǎng)絡(luò)吞吐量下降，所以，一個(gè)優(yōu)秀的序列化框架可以提高系統(tǒng)的整體性能。

我們都知道Java提供了RMI框架可以實(shí)現(xiàn)服務(wù)與服務(wù)之間的接口暴露和調(diào)用，RMI中對(duì)數(shù)據(jù)對(duì)象的序列化采用的是Java序列化。而目前主流的框架卻很少使用到Java序列化，如SpringCloud使用的Json序列化，Dubbo雖然兼容了Java序列化，但是默認(rèn)還是使用的Hessian序列化。

Java序列化

首先，來看看什么是Java序列化和實(shí)現(xiàn)原理。Java提供了一種序列化機(jī)制，這種機(jī)制能將一個(gè)對(duì)象序列化成二進(jìn)制形式，用于寫入磁盤或輸出到網(wǎng)絡(luò)，同時(shí)將從網(wǎng)絡(luò)或者磁盤中讀取的字節(jié)數(shù)組，反序列化成對(duì)象，在程序中使用。

JDK 提供的兩個(gè)輸入、輸出流對(duì)象 ObjectInputStream 和 ObjectOutputStream，它們只能對(duì)實(shí)現(xiàn)了 Serializable 接口的類的對(duì)象進(jìn)行反序列化和序列化。

ObjectOutputStream 的默認(rèn)序列化方式，僅對(duì)對(duì)象的非 transient 的實(shí)例變量進(jìn)行序列化，而不會(huì)序列化對(duì)象的 transient 的實(shí)例變量，也不會(huì)序列化靜態(tài)變量。

在實(shí)現(xiàn)了 Serializable 接口的類的對(duì)象中，會(huì)生成一個(gè) serialVersionUID 的版本號(hào)，這個(gè)版本號(hào)有什么用呢?它會(huì)在反序列化過程中來驗(yàn)證序列化對(duì)象是否加載了反序列化的類，如果是具有相同類名的不同版本號(hào)的類，在反序列化中是無法獲取對(duì)象的。

具體實(shí)現(xiàn)序列化的是writeObject和readObject，通常這兩個(gè)方法是默認(rèn)的，我們也可以在實(shí)現(xiàn)Serializable接口的類中對(duì)其重寫，定制屬于自己的序列化和反序列化機(jī)制。

Java序列化類中還定義了兩個(gè)重寫方法：writeReplace()和readResolve()，前者是用來在序列化之前替換序列化對(duì)象的，后者是用來在序列化之后對(duì)返回對(duì)象進(jìn)行處理的。

Java序列化缺陷

我們?cè)谟眠^的RPC通信框架中，很少會(huì)發(fā)現(xiàn)使用JDK提供的序列化，主要是因?yàn)镴DK默認(rèn)的序列化存在著如下一些缺陷：無法跨語言、易被攻擊、序列化后的流太大、序列化性能太差等。

1. 無法跨語言

現(xiàn)在很多系統(tǒng)的復(fù)雜度很高，采用多種語言來編碼，而Java序列化目前只支持Java語言實(shí)現(xiàn)的框架，其它語言大部分都沒有使用Java的序列化框架，也沒有實(shí)現(xiàn)Java序列化這套協(xié)議，因此，如果兩個(gè)基于不同語言編寫的應(yīng)用程序之間通信，使用Java序列化，則無法實(shí)現(xiàn)兩個(gè)應(yīng)用服務(wù)之間傳輸對(duì)象的序列化和反序列化。

2. 易被攻擊

Java官網(wǎng)安全編碼指導(dǎo)方針里有說明，“對(duì)于不信任數(shù)據(jù)的反序列化，從本質(zhì)上來說是危險(xiǎn)的，應(yīng)該避免“。可見Java序列化并不是安全的。

我們知道對(duì)象是通過在 ObjectInputStream 上調(diào)用 readObject() 方法進(jìn)行反序列化的，這個(gè)方法其實(shí)是一個(gè)神奇的構(gòu)造器，它可以將類路徑上幾乎所有實(shí)現(xiàn)了 Serializable 接口的對(duì)象都實(shí)例化。這也就意味著，在反序列化字節(jié)流的過程中，該方法可以執(zhí)行任意類型的代碼，這是非常危險(xiǎn)的。

對(duì)于需要長(zhǎng)時(shí)間進(jìn)行反序列化的對(duì)象，不需要執(zhí)行任何代碼，也可以發(fā)起一次攻擊。攻擊者可以創(chuàng)建循環(huán)對(duì)象鏈，然后將序列化后的對(duì)象傳輸?shù)匠绦蛑蟹葱蛄谢?，這種情況會(huì)導(dǎo)致 hashCode 方法被調(diào)用次數(shù)呈次方爆發(fā)式增長(zhǎng), 從而引發(fā)棧溢出異常。例如下面這個(gè)案例就可以很好地說明。

Set root = new HashSet();   
Set s1 = root;   
Set s2 = new HashSet();   
for (int i = 0; i < 100; i++) {   
   Set t1 = new HashSet();   
   Set t2 = new HashSet();   
   t1.add("test"); //使t2不等于t1   
   s1.add(t1);   
   s1.add(t2);   
   s2.add(t1);   
   s2.add(t2);   
   s1 = t1;   
   s2 = t2;    
} 

之前FoxGlove Security安全團(tuán)隊(duì)的一篇論文中提到的：通過Apache Commons Collections，Java反序列化漏洞可以實(shí)現(xiàn)攻擊，一度橫掃了 WebLogic、WebSphere、JBoss、Jenkins、OpenNMS 的最新版，各大 Java Web Server 紛紛躺槍。

其實(shí)，Apache Commons Collections就是一個(gè)第三方基礎(chǔ)庫，它擴(kuò)展了Java標(biāo)準(zhǔn)庫里的Collection結(jié)構(gòu)，提供了很多強(qiáng)大的數(shù)據(jù)結(jié)構(gòu)類型，并且實(shí)現(xiàn)了各種集合工具類。

實(shí)現(xiàn)攻擊的原理：Apache Commons Collections允許鏈?zhǔn)降娜我獾念惡瘮?shù)反射調(diào)用，攻擊者通過實(shí)現(xiàn)了Java序列化協(xié)議的端口，把攻擊代碼上傳到服務(wù)器上，再由Apache Commons Collections里的TransformedMap來執(zhí)行。

如何解決這個(gè)漏洞?

很多序列化協(xié)議都制定了一套數(shù)據(jù)結(jié)構(gòu)來保存和獲取對(duì)象。例如，JSON 序列化、ProtocolBuf 等，它們只支持一些基本類型和數(shù)組數(shù)據(jù)類型，這樣可以避免反序列化創(chuàng)建一些不確定的實(shí)例。雖然它們的設(shè)計(jì)簡(jiǎn)單，但足以滿足當(dāng)前大部分系統(tǒng)的數(shù)據(jù)傳輸需求。我們也可以通過反序列化對(duì)象白名單來控制反序列化對(duì)象，可以重寫 resolveClass 方法，并在該方法中校驗(yàn)對(duì)象名字。代碼如下所示：

@Override 
protected Class resolveClass(ObjectStreamClass desc) throws IOException,ClassNotFoundException { 
  if (!desc.getName().equals(Bicycle.class.getName())) { 
    throw new InvalidClassException( 
    "Unauthorized deserialization attempt", desc.getName()); 
  } 
  return super.resolveClass(desc); 
} 

3. 序列化后的流太大

序列化后的二進(jìn)制流大小能體現(xiàn)序列化的性能。序列化后的二進(jìn)制數(shù)組越大，占用的存儲(chǔ)空間就越多，存儲(chǔ)硬件的成本就越高。如果我們是進(jìn)行網(wǎng)絡(luò)傳輸，則占用的帶寬就更多，這時(shí)就會(huì)影響到系統(tǒng)的吞吐量。

Java 序列化中使用了 ObjectOutputStream 來實(shí)現(xiàn)對(duì)象轉(zhuǎn)二進(jìn)制編碼，那么這種序列化機(jī)制實(shí)現(xiàn)的二進(jìn)制編碼完成的二進(jìn)制數(shù)組大小，相比于 NIO 中的 ByteBuffer 實(shí)現(xiàn)的二進(jìn)制編碼完成的數(shù)組大小，有沒有區(qū)別呢?

我們可以通過一個(gè)簡(jiǎn)單的例子來驗(yàn)證下：

User user = new User(); 
user.setUserName("test"); 
user.setPassword("test"); 
       
ByteArrayOutputStream os =new ByteArrayOutputStream(); 
ObjectOutputStream out = new ObjectOutputStream(os); 
out.writeObject(user); 
byte[] testByte = os.toByteArray(); 
System.out.print("ObjectOutputStream 字節(jié)編碼長(zhǎng)度：" + testByte.length + "\n"); 

ByteBuffer byteBuffer = ByteBuffer.allocate( 2048); 
 
byte[] userName = user.getUserName().getBytes(); 
byte[] password = user.getPassword().getBytes(); 
byteBuffer.putInt(userName.length); 
byteBuffer.put(userName); 
byteBuffer.putInt(password.length); 
byteBuffer.put(password);         
byteBuffer.flip(); 
byte[] bytes = new byte[byteBuffer.remaining()]; 
System.out.print("ByteBuffer 字節(jié)編碼長(zhǎng)度：" + bytes.length+ "\n"); 

運(yùn)行結(jié)構(gòu)：

ObjectOutputStream 字節(jié)編碼長(zhǎng)度：99 
ByteBuffer 字節(jié)編碼長(zhǎng)度：16 

這里我們可以清楚地看到：Java 序列化實(shí)現(xiàn)的二進(jìn)制編碼完成的二進(jìn)制數(shù)組大小，比 ByteBuffer 實(shí)現(xiàn)的二進(jìn)制編碼完成的二進(jìn)制數(shù)組大小要大上幾倍。因此，Java 序列后的流會(huì)變大，最終會(huì)影響到系統(tǒng)的吞吐量。

4. 序列化性能太差

序列化的速度也是體現(xiàn)序列化性能的重要指標(biāo)，如果序列化的速度慢，就會(huì)影響網(wǎng)絡(luò)通信的效率，從而增加系統(tǒng)的響應(yīng)時(shí)間。我們?cè)賮硗ㄟ^上面這個(gè)例子，來對(duì)比下 Java 序列化與 NIO 中的 ByteBuffer 編碼的性能：

User user = new User(); 
    user.setUserName("test"); 
    user.setPassword("test"); 
       
    long startTime = System.currentTimeMillis(); 
       
     for(int i=0; i<1000; i++) { 
        ByteArrayOutputStream os =new ByteArrayOutputStream(); 
          ObjectOutputStream out = new ObjectOutputStream(os); 
          out.writeObject(user); 
          out.flush(); 
          out.close(); 
          byte[] testByte = os.toByteArray(); 
          os.close(); 
     } 
     
       
long endTime = System.currentTimeMillis(); 
System.out.print("ObjectOutputStream 序列化時(shí)間：" + (endTime - startTime) + "\n"); 

long startTime1 = System.currentTimeMillis(); 
for(int i=0; i<1000; i++) { 
   ByteBuffer byteBuffer = ByteBuffer.allocate( 2048); 
 
        byte[] userName = user.getUserName().getBytes(); 
        byte[] password = user.getPassword().getBytes(); 
        byteBuffer.putInt(userName.length); 
        byteBuffer.put(userName); 
        byteBuffer.putInt(password.length); 
        byteBuffer.put(password); 
             
        byteBuffer.flip(); 
        byte[] bytes = new byte[byteBuffer.remaining()]; 
} 
long endTime1 = System.currentTimeMillis(); 
System.out.print("ByteBuffer 序列化時(shí)間：" + (endTime1 - startTime1)+ "\n"); 

運(yùn)行結(jié)果：

ObjectOutputStream 序列化時(shí)間：29 
ByteBuffer 序列化時(shí)間：6 

通過這個(gè)案例，我們可以清楚地看到：Java 序列化中的編碼耗時(shí)要比 ByteBuffer 長(zhǎng)很多。

上邊說了4個(gè)Java序列化的缺點(diǎn)，其實(shí)業(yè)界有很多可以代替Java序列化的序列化框架，大部分都避免了Java默認(rèn)序列化的一些缺陷，例如比較流行的FastJson、Kryo、Protobuf、Hessian等，這里就來簡(jiǎn)單的介紹一下Protobuf序列化框架。

Protobuf 是由 Google 推出且支持多語言的序列化框架，目前在主流網(wǎng)站上的序列化框架性能對(duì)比測(cè)試報(bào)告中，Protobuf 無論是編解碼耗時(shí)，還是二進(jìn)制流壓縮大小，都名列前茅。

Protobuf 以一個(gè) .proto 后綴的文件為基礎(chǔ)，這個(gè)文件描述了字段以及字段類型，通過工具可以生成不同語言的數(shù)據(jù)結(jié)構(gòu)文件。在序列化該數(shù)據(jù)對(duì)象的時(shí)候，Protobuf 通過.proto 文件描述來生成 Protocol Buffers 格式的編碼。

那么什么是Protocol Buffers存儲(chǔ)格式?

Protocol Buffers 是一種輕便高效的結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)格式。它使用 T-L-V(標(biāo)識(shí) - 長(zhǎng)度 - 字段值)的數(shù)據(jù)格式來存儲(chǔ)數(shù)據(jù)，T 代表字段的正數(shù)序列 (tag)，Protocol Buffers 將對(duì)象中的每個(gè)字段和正數(shù)序列對(duì)應(yīng)起來，對(duì)應(yīng)關(guān)系的信息是由生成的代碼來保證的。在序列化的時(shí)候用整數(shù)值來代替字段名稱，于是傳輸流量就可以大幅縮減;L 代表 Value 的字節(jié)長(zhǎng)度，一般也只占一個(gè)字節(jié);V 則代表字段值經(jīng)過編碼后的值。這種數(shù)據(jù)格式不需要分隔符，也不需要空格，同時(shí)減少了冗余字段名。

Protobuf 定義了一套自己的編碼方式，幾乎可以映射 Java/Python 等語言的所有基礎(chǔ)數(shù)據(jù)類型。不同的編碼方式對(duì)應(yīng)不同的數(shù)據(jù)類型，還能采用不同的存儲(chǔ)格式。如下圖所示：

對(duì)于存儲(chǔ) Varint 編碼數(shù)據(jù)，由于數(shù)據(jù)占用的存儲(chǔ)空間是固定的，就不需要存儲(chǔ)字節(jié)長(zhǎng)度 Length，所以實(shí)際上 Protocol Buffers 的存儲(chǔ)方式是 T - V，這樣就又減少了一個(gè)字節(jié)的存儲(chǔ)空間。

Protobuf 定義的 Varint 編碼方式是一種變長(zhǎng)的編碼方式，每個(gè)字節(jié)的最后一位 (即最高位) 是一個(gè)標(biāo)志位 (msb)，用 0 和 1 來表示，0 表示當(dāng)前字節(jié)已經(jīng)是最后一個(gè)字節(jié)，1 表示這個(gè)數(shù)字后面還有一個(gè)字節(jié)。

對(duì)于 int32 類型數(shù)字，一般需要 4 個(gè)字節(jié)表示，若采用 Varint 編碼方式，對(duì)于很小的 int32 類型數(shù)字，就可以用 1 個(gè)字節(jié)來表示。對(duì)于大部分整數(shù)類型數(shù)據(jù)來說，一般都是小于 256，所以這種操作可以起到很好地壓縮數(shù)據(jù)的效果。

我們知道 int32 代表正負(fù)數(shù)，所以一般最后一位是用來表示正負(fù)值，現(xiàn)在 Varint 編碼方式將最后一位用作了標(biāo)志位，那還如何去表示正負(fù)整數(shù)呢?如果使用 int32/int64 表示負(fù)數(shù)就需要多個(gè)字節(jié)來表示，在 Varint 編碼類型中，通過 Zigzag 編碼進(jìn)行轉(zhuǎn)換，將負(fù)數(shù)轉(zhuǎn)換成無符號(hào)數(shù)，再采用 sint32/sint64 來表示負(fù)數(shù)，這樣就可以大大地減少編碼后的字節(jié)數(shù)。

rotobuf 的這種數(shù)據(jù)存儲(chǔ)格式，不僅壓縮存儲(chǔ)數(shù)據(jù)的效果好， 在編碼和解碼的性能方面也很高效。Protobuf 的編碼和解碼過程結(jié)合.proto 文件格式，加上 Protocol Buffer 獨(dú)特的編碼格式，只需要簡(jiǎn)單的數(shù)據(jù)運(yùn)算以及位移等操作就可以完成編碼與解碼?？梢哉f Protobuf 的整體性能非常優(yōu)秀。

總結(jié)

Java 默認(rèn)的序列化是通過 Serializable 接口實(shí)現(xiàn)的，只要類實(shí)現(xiàn)了該接口，同時(shí)生成一個(gè)默認(rèn)的版本號(hào)，我們無需手動(dòng)設(shè)置，該類就會(huì)自動(dòng)實(shí)現(xiàn)序列化與反序列化。

Java 默認(rèn)的序列化雖然實(shí)現(xiàn)方便，但卻存在安全漏洞、不跨語言以及性能差等缺陷，所以我強(qiáng)烈建議你避免使用 Java 序列化。

縱觀主流序列化框架，F(xiàn)astJson、Protobuf、Kryo 是比較有特點(diǎn)的，而且性能以及安全方面都得到了業(yè)界的認(rèn)可，我們可以結(jié)合自身業(yè)務(wù)來選擇一種適合的序列化框架，來優(yōu)化系統(tǒng)的序列化性能。