爲何我不建議你使用Java序列化

做爲一名Java開發，我爲何建議你在開發中避免使用Java序列化？

現在大部分的後端服務都是基於微服務架構實現的，服務按照業務劃分被拆分，實現了服務的解耦，同時也帶來了一些新的問題，好比不一樣業務之間的通訊須要經過接口實現調用。兩個服務之間要共享一個數據對象，就須要從對象轉換成二進制流，經過網絡傳輸，傳送到對方服務，再轉換成對象，供服務方法調用。這個編碼和解碼的過程咱們稱之爲序列化和反序列化。

在高併發系統中，序列化的速度快慢，會影響請求的響應時間，序列化後的傳輸數據體積大，會致使網絡吞吐量降低，因此，一個優秀的序列化框架能夠提升系統的總體性能。

咱們都知道Java提供了RMI框架能夠實現服務與服務之間的接口暴露和調用，RMI中對數據對象的序列化採用的是Java序列化。而目前主流的框架卻不多使用到Java序列化，如SpringCloud使用的Json序列化，Dubbo雖然兼容了Java序列化，可是默認仍是使用的Hessian序列化。

Java序列化

首先，來看看什麼是Java序列化和實現原理。Java提供了一種序列化機制，這種機制能將一個對象序列化成二進制形式，用於寫入磁盤或輸出到網絡，同時將從網絡或者磁盤中讀取的字節數組，反序列化成對象，在程序中使用。

JDK 提供的兩個輸入、輸出流對象 ObjectInputStream 和 ObjectOutputStream，它們只能對實現了 Serializable 接口的類的對象進行反序列化和序列化。

ObjectOutputStream 的默認序列化方式，僅對對象的非 transient 的實例變量進行序列化，而不會序列化對象的 transient 的實例變量，也不會序列化靜態變量。

在實現了 Serializable 接口的類的對象中，會生成一個 serialVersionUID 的版本號，這個版本號有什麼用呢？它會在反序列化過程當中來驗證序列化對象是否加載了反序列化的類，若是是具備相同類名的不一樣版本號的類，在反序列化中是沒法獲取對象的。

具體實現序列化的是writeObject和readObject，一般這兩個方法是默認的，咱們也能夠在實現Serializable接口的類中對其重寫，定製屬於本身的序列化和反序列化機制。

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

Java序列化缺陷

咱們在用過的RPC通訊框架中，不多會發現使用JDK提供的序列化，主要是由於JDK默認的序列化存在着以下一些缺陷：沒法跨語言、易被***、序列化後的流太大、序列化性能太差等。

1. 沒法跨語言

如今不少系統的複雜度很高，採用多種語言來編碼，而Java序列化目前只支持Java語言實現的框架，其它語言大部分都沒有使用Java的序列化框架，也沒有實現Java序列化這套協議，所以，若是兩個基於不一樣語言編寫的應用程序之間通訊，使用Java序列化，則沒法實現兩個應用服務之間傳輸對象的序列化和反序列化。

2. 易被***

Java官網安全編碼指導方針裏有說明，「對於不信任數據的反序列化，從本質上來講是危險的，應該避免「。可見Java序列化並非安全的。

咱們知道對象是經過在 ObjectInputStream 上調用 readObject() 方法進行反序列化的，這個方法實際上是一個神奇的構造器，它能夠將類路徑上幾乎全部實現了 Serializable 接口的對象都實例化。這也就意味着，在反序列化字節流的過程當中，該方法能夠執行任意類型的代碼，這是很是危險的。

對於須要長時間進行反序列化的對象，不須要執行任何代碼，也能夠發起一次***。***者能夠建立循環對象鏈，而後將序列化後的對象傳輸到程序中反序列化，這種狀況會致使 hashCode 方法被調用次數呈次方爆發式增加, 從而引起棧溢出異常。例以下面這個案例就能夠很好地說明。

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安全團隊的一篇論文中提到的：經過Apache Commons Collections，Java反序列化漏洞能夠實現***，一度橫掃了 WebLogic、WebSphere、JBoss、Jenkins、OpenNMS 的最新版，各大 Java Web Server 紛紛躺槍。

其實，Apache Commons Collections就是一個第三方基礎庫，它擴展了Java標準庫裏的Collection結構，提供了不少強大的數據結構類型，而且實現了各類集合工具類。

實現***的原理：Apache Commons Collections容許鏈式的任意的類函數反射調用，***者經過實現了Java序列化協議的端口，把***代碼上傳到服務器上，再由Apache Commons Collections裏的TransformedMap來執行。

如何解決這個漏洞？

不少序列化協議都制定了一套數據結構來保存和獲取對象。例如，JSON 序列化、ProtocolBuf 等，它們只支持一些基本類型和數組數據類型，這樣能夠避免反序列化建立一些不肯定的實例。雖然它們的設計簡單，但足以知足當前大部分系統的數據傳輸需求。咱們也能夠經過反序列化對象白名單來控制反序列化對象，能夠重寫 resolveClass 方法，並在該方法中校驗對象名字。代碼以下所示：

@Overrideprotected 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. 序列化後的流太大

序列化後的二進制流大小能體現序列化的性能。序列化後的二進制數組越大，佔用的存儲空間就越多，存儲硬件的成本就越高。若是咱們是進行網絡傳輸，則佔用的帶寬就更多，這時就會影響到系統的吞吐量。

Java 序列化中使用了 ObjectOutputStream 來實現對象轉二進制編碼，那麼這種序列化機制實現的二進制編碼完成的二進制數組大小，相比於 NIO 中的 ByteBuffer 實現的二進制編碼完成的數組大小，有沒有區別呢？

咱們能夠經過一個簡單的例子來驗證下：

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 字節編碼長度：" + 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 字節編碼長度：" + bytes.length+ "\n");

運行結構：

ObjectOutputStream 字節編碼長度：99ByteBuffer 字節編碼長度：16

這裏咱們能夠清楚地看到：Java 序列化實現的二進制編碼完成的二進制數組大小，比 ByteBuffer 實現的二進制編碼完成的二進制數組大小要大上幾倍。所以，Java 序列後的流會變大，最終會影響到系統的吞吐量。

4. 序列化性能太差

序列化的速度也是體現序列化性能的重要指標，若是序列化的速度慢，就會影響網絡通訊的效率，從而增長系統的響應時間。咱們再來經過上面這個例子，來對比下 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 序列化時間：" + (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 序列化時間：" + (endTime1 - startTime1)+ "\n");

運行結果：

ObjectOutputStream 序列化時間：29ByteBuffer 序列化時間：6

經過這個案例，咱們能夠清楚地看到：Java 序列化中的編碼耗時要比 ByteBuffer 長不少。

上邊說了4個Java序列化的缺點，其實業界有不少能夠代替Java序列化的序列化框架，大部分都避免了Java默認序列化的一些缺陷，例如比較流行的FastJson、Kryo、Protobuf、Hessian等，這裏就來簡單的介紹一下Protobuf序列化框架。

Protobuf 是由 Google 推出且支持多語言的序列化框架，目前在主流網站上的序列化框架性能對比測試報告中，Protobuf 不管是編解碼耗時，仍是二進制流壓縮大小，都名列前茅。

Protobuf 以一個 .proto 後綴的文件爲基礎，這個文件描述了字段以及字段類型，經過工具能夠生成不一樣語言的數據結構文件。在序列化該數據對象的時候，Protobuf 經過.proto 文件描述來生成 Protocol Buffers 格式的編碼。

那麼什麼是Protocol Buffers存儲格式？

Protocol Buffers 是一種輕便高效的結構化數據存儲格式。它使用 T-L-V（標識 - 長度 - 字段值）的數據格式來存儲數據，T 表明字段的正數序列 (tag)，Protocol Buffers 將對象中的每一個字段和正數序列對應起來，對應關係的信息是由生成的代碼來保證的。在序列化的時候用整數值來代替字段名稱，因而傳輸流量就能夠大幅縮減；L 表明 Value 的字節長度，通常也只佔一個字節；V 則表明字段值通過編碼後的值。這種數據格式不須要分隔符，也不須要空格，同時減小了冗餘字段名。

Protobuf 定義了一套本身的編碼方式，幾乎能夠映射 Java/Python 等語言的全部基礎數據類型。不一樣的編碼方式對應不一樣的數據類型，還能採用不一樣的存儲格式。以下圖所示：

對於存儲 Varint 編碼數據，因爲數據佔用的存儲空間是固定的，就不須要存儲字節長度 Length，因此實際上 Protocol Buffers 的存儲方式是 T - V，這樣就又減小了一個字節的存儲空間。

Protobuf 定義的 Varint 編碼方式是一種變長的編碼方式，每一個字節的最後一位 (即最高位) 是一個標誌位 (msb)，用 0 和 1 來表示，0 表示當前字節已是最後一個字節，1 表示這個數字後面還有一個字節。

對於 int32 類型數字，通常須要 4 個字節表示，若採用 Varint 編碼方式，對於很小的 int32 類型數字，就能夠用 1 個字節來表示。對於大部分整數類型數據來講，通常都是小於 256，因此這種操做能夠起到很好地壓縮數據的效果。

咱們知道 int32 表明正負數，因此通常最後一位是用來表示正負值，如今 Varint 編碼方式將最後一位用做了標誌位，那還如何去表示正負整數呢？若是使用 int32/int64 表示負數就須要多個字節來表示，在 Varint 編碼類型中，經過 Zigzag 編碼進行轉換，將負數轉換成無符號數，再採用 sint32/sint64 來表示負數，這樣就能夠大大地減小編碼後的字節數。

rotobuf 的這種數據存儲格式，不只壓縮存儲數據的效果好， 在編碼和解碼的性能方面也很高效。Protobuf 的編碼和解碼過程結合.proto 文件格式，加上 Protocol Buffer 獨特的編碼格式，只須要簡單的數據運算以及位移等操做就能夠完成編碼與解碼。能夠說 Protobuf 的總體性能很是優秀。

總結

1. Java 默認的序列化是經過 Serializable 接口實現的，只要類實現了該接口，同時生成一個默認的版本號，咱們無需手動設置，該類就會自動實現序列化與反序列化。

2. Java 默認的序列化雖然實現方便，但卻存在安全漏洞、不跨語言以及性能差等缺陷，因此我強烈建議你避免使用 Java 序列化。

3. 縱觀主流序列化框架，FastJson、Protobuf、Kryo 是比較有特色的，並且性能以及安全方面都獲得了業界的承認，咱們能夠結合自身業務來選擇一種適合的序列化框架，來優化系統的序列化性能。