為什么不使用Java序列化

這篇文章主要介紹“為什么不使用Java序列化”，在日常操作中，相信很多人在為什么不使用Java序列化問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”為什么不使用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 方法，并在該方法中校驗對象名字。代碼如下所示：

@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序列化”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！