為什么我不建議你使用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官網安全編碼指導方針里有說明，“對于不信任數據的反序列化，從本質上來說是危險的，應該避免“?？梢奐ava序列化并不是安全的。
我們知道對象是通過在 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 方法，并在該方法中校驗對象名字。代碼如下所示：
- @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. 序列化后的流太大
序列化后的二進制流大小能體現序列化的性能。序列化后的二進制數組越大，占用的存儲空間就越多，存儲硬件的成本就越高。如果我們是進行網絡傳輸，則占用的帶寬就更多，這時就會影響到系統的吞吐量。
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 字節編碼長度：99
- ByteBuffer 字節編碼長度：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 序列化時間：29
- ByteBuffer 序列化時間：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 的整體性能非常優秀。
總結
Java 默認的序列化是通過 Serializable 接口實現的，只要類實現了該接口，同時生成一個默認的版本號，我們無需手動設置，該類就會自動實現序列化與反序列化。
Java 默認的序列化雖然實現方便，但卻存在安全漏洞、不跨語言以及性能差等缺陷，所以我強烈建議你避免使用 Java 序列化。
縱觀主流序列化框架，FastJson、Protobuf、Kryo 是比較有特點的，而且性能以及安全方面都得到了業界的認可，我們可以結合自身業務來選擇一種適合的序列化框架，來優化系統的序列化性能。
