作為一名Java開發(fā)，我為什么建議你在開發(fā)中避免使用Java序列化?
如今大部分的后端服務(wù)都是基于微服務(wù)架構(gòu)實現(xiàn)的，服務(wù)按照業(yè)務(wù)劃分被拆分，實現(xiàn)了服務(wù)的解耦，同時也帶來了一些新的問題，比如不同業(yè)務(wù)之間的通信需要通過接口實現(xiàn)調(diào)用。兩個服務(wù)之間要共享一個數(shù)據(jù)對象，就需要從對象轉(zhuǎn)換成二進制流，通過網(wǎng)絡(luò)傳輸，傳送到對方服務(wù)，再轉(zhuǎn)換成對象，供服務(wù)方法調(diào)用。這個編碼和解碼的過程我們稱之為序列化和反序列化。
在高并發(fā)系統(tǒng)中，序列化的速度快慢，會影響請求的響應(yīng)時間，序列化后的傳輸數(shù)據(jù)體積大，會導致網(wǎng)絡(luò)吞吐量下降，所以，一個優(yōu)秀的序列化框架可以提高系統(tǒng)的整體性能。
我們都知道Java提供了RMI框架可以實現(xiàn)服務(wù)與服務(wù)之間的接口暴露和調(diào)用，RMI中對數(shù)據(jù)對象的序列化采用的是Java序列化。而目前主流的框架卻很少使用到Java序列化，如SpringCloud使用的Json序列化，Dubbo雖然兼容了Java序列化，但是默認還是使用的Hessian序列化。
Java序列化
首先，來看看什么是Java序列化和實現(xiàn)原理。Java提供了一種序列化機制，這種機制能將一個對象序列化成二進制形式，用于寫入磁盤或輸出到網(wǎng)絡(luò)，同時將從網(wǎng)絡(luò)或者磁盤中讀取的字節(jié)數(shù)組，反序列化成對象，在程序中使用。
JDK 提供的兩個輸入、輸出流對象 ObjectInputStream 和 ObjectOutputStream，它們只能對實現(xiàn)了 Serializable 接口的類的對象進行反序列化和序列化。
ObjectOutputStream 的默認序列化方式，僅對對象的非 transient 的實例變量進行序列化，而不會序列化對象的 transient 的實例變量，也不會序列化靜態(tài)變量。
在實現(xiàn)了 Serializable 接口的類的對象中，會生成一個 serialVersionUID 的版本號，這個版本號有什么用呢?它會在反序列化過程中來驗證序列化對象是否加載了反序列化的類，如果是具有相同類名的不同版本號的類，在反序列化中是無法獲取對象的。
具體實現(xiàn)序列化的是writeObject和readObject，通常這兩個方法是默認的，我們也可以在實現(xiàn)Serializable接口的類中對其重寫，定制屬于自己的序列化和反序列化機制。
Java序列化類中還定義了兩個重寫方法：writeReplace()和readResolve()，前者是用來在序列化之前替換序列化對象的，后者是用來在序列化之后對返回對象進行處理的。
Java序列化缺陷
我們在用過的RPC通信框架中，很少會發(fā)現(xiàn)使用JDK提供的序列化，主要是因為JDK默認的序列化存在著如下一些缺陷：無法跨語言、易被攻擊、序列化后的流太大、序列化性能太差等。
1. 無法跨語言
現(xiàn)在很多系統(tǒng)的復雜度很高，采用多種語言來編碼，而Java序列化目前只支持Java語言實現(xiàn)的框架，其它語言大部分都沒有使用Java的序列化框架，也沒有實現(xiàn)Java序列化這套協(xié)議，因此，如果兩個基于不同語言編寫的應(yīng)用程序之間通信，使用Java序列化，則無法實現(xiàn)兩個應(yīng)用服務(wù)之間傳輸對象的序列化和反序列化。
2. 易被攻擊
Java官網(wǎng)安全編碼指導方針里有說明，“對于不信任數(shù)據(jù)的反序列化，從本質(zhì)上來說是危險的，應(yīng)該避免“。可見Java序列化并不是安全的。
我們知道對象是通過在 ObjectInputStream 上調(diào)用 readObject() 方法進行反序列化的，這個方法其實是一個神奇的構(gòu)造器，它可以將類路徑上幾乎所有實現(xiàn)了 Serializable 接口的對象都實例化。這也就意味著，在反序列化字節(jié)流的過程中，該方法可以執(zhí)行任意類型的代碼，這是非常危險的。
對于需要長時間進行反序列化的對象，不需要執(zhí)行任何代碼，也可以發(fā)起一次攻擊。攻擊者可以創(chuàng)建循環(huán)對象鏈，然后將序列化后的對象傳輸?shù)匠绦蛑蟹葱蛄谢@種情況會導致 hashCode 方法被調(diào)用次數(shù)呈次方爆發(fā)式增長, 從而引發(fā)棧溢出異常。例如下面這個案例就可以很好地說明。
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反序列化漏洞可以實現(xiàn)攻擊，一度橫掃了 WebLogic、WebSphere、JBoss、Jenkins、OpenNMS 的最新版，各大 Java Web Server 紛紛躺槍。
其實，Apache Commons Collections就是一個第三方基礎(chǔ)庫，它擴展了Java標準庫里的Collection結(jié)構(gòu)，提供了很多強大的數(shù)據(jù)結(jié)構(gòu)類型，并且實現(xiàn)了各種集合工具類。
實現(xiàn)攻擊的原理：Apache Commons Collections允許鏈式的任意的類函數(shù)反射調(diào)用，攻擊者通過實現(xiàn)了Java序列化協(xié)議的端口，把攻擊代碼上傳到服務(wù)器上，再由Apache Commons Collections里的TransformedMap來執(zhí)行。
如何解決這個漏洞?
很多序列化協(xié)議都制定了一套數(shù)據(jù)結(jié)構(gòu)來保存和獲取對象。例如，JSON 序列化、ProtocolBuf 等，它們只支持一些基本類型和數(shù)組數(shù)據(jù)類型，這樣可以避免反序列化創(chuàng)建一些不確定的實例。雖然它們的設(shè)計簡單，但足以滿足當前大部分系統(tǒng)的數(shù)據(jù)傳輸需求。我們也可以通過反序列化對象白名單來控制反序列化對象，可以重寫 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. 序列化后的流太大
序列化后的二進制流大小能體現(xiàn)序列化的性能。序列化后的二進制數(shù)組越大，占用的存儲空間就越多，存儲硬件的成本就越高。如果我們是進行網(wǎng)絡(luò)傳輸，則占用的帶寬就更多，這時就會影響到系統(tǒng)的吞吐量。
Java 序列化中使用了 ObjectOutputStream 來實現(xiàn)對象轉(zhuǎn)二進制編碼，那么這種序列化機制實現(xiàn)的二進制編碼完成的二進制數(shù)組大小，相比于 NIO 中的 ByteBuffer 實現(xiàn)的二進制編碼完成的數(shù)組大小，有沒有區(qū)別呢?
我們可以通過一個簡單的例子來驗證下：
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é)編碼長度：" + 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é)編碼長度：" + bytes.length+ "\n");
運行結(jié)構(gòu)：
ObjectOutputStream 字節(jié)編碼長度：99
ByteBuffer 字節(jié)編碼長度：16
這里我們可以清楚地看到：Java 序列化實現(xiàn)的二進制編碼完成的二進制數(shù)組大小，比 ByteBuffer 實現(xiàn)的二進制編碼完成的二進制數(shù)組大小要大上幾倍。因此，Java 序列后的流會變大，最終會影響到系統(tǒng)的吞吐量。
4. 序列化性能太差
序列化的速度也是體現(xiàn)序列化性能的重要指標，如果序列化的速度慢，就會影響網(wǎng)絡(luò)通信的效率，從而增加系統(tǒng)的響應(yīng)時間。我們再來通過上面這個例子，來對比下 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");
運行結(jié)果：
ObjectOutputStream 序列化時間：29
ByteBuffer 序列化時間：6
通過這個案例，我們可以清楚地看到：Java 序列化中的編碼耗時要比 ByteBuffer 長很多。
上邊說了4個Java序列化的缺點，其實業(yè)界有很多可以代替Java序列化的序列化框架，大部分都避免了Java默認序列化的一些缺陷，例如比較流行的FastJson、Kryo、Protobuf、Hessian等，這里就來簡單的介紹一下Protobuf序列化框架。
Protobuf 是由 Google 推出且支持多語言的序列化框架，目前在主流網(wǎng)站上的序列化框架性能對比測試報告中，Protobuf 無論是編解碼耗時，還是二進制流壓縮大小，都名列前茅。
Protobuf 以一個 .proto 后綴的文件為基礎(chǔ)，這個文件描述了字段以及字段類型，通過工具可以生成不同語言的數(shù)據(jù)結(jié)構(gòu)文件。在序列化該數(shù)據(jù)對象的時候，Protobuf 通過.proto 文件描述來生成 Protocol Buffers 格式的編碼。
那么什么是Protocol Buffers存儲格式?
Protocol Buffers 是一種輕便高效的結(jié)構(gòu)化數(shù)據(jù)存儲格式。它使用 T-L-V(標識 - 長度 - 字段值)的數(shù)據(jù)格式來存儲數(shù)據(jù)，T 代表字段的正數(shù)序列 (tag)，Protocol Buffers 將對象中的每個字段和正數(shù)序列對應(yīng)起來，對應(yīng)關(guān)系的信息是由生成的代碼來保證的。在序列化的時候用整數(shù)值來代替字段名稱，于是傳輸流量就可以大幅縮減;L 代表 Value 的字節(jié)長度，一般也只占一個字節(jié);V 則代表字段值經(jīng)過編碼后的值。這種數(shù)據(jù)格式不需要分隔符，也不需要空格，同時減少了冗余字段名。
Protobuf 定義了一套自己的編碼方式，幾乎可以映射 Java/Python 等語言的所有基礎(chǔ)數(shù)據(jù)類型。不同的編碼方式對應(yīng)不同的數(shù)據(jù)類型，還能采用不同的存儲格式。如下圖所示：
對于存儲 Varint 編碼數(shù)據(jù)，由于數(shù)據(jù)占用的存儲空間是固定的，就不需要存儲字節(jié)長度 Length，所以實際上 Protocol Buffers 的存儲方式是 T - V，這樣就又減少了一個字節(jié)的存儲空間。
Protobuf 定義的 Varint 編碼方式是一種變長的編碼方式，每個字節(jié)的最后一位 (即最高位) 是一個標志位 (msb)，用 0 和 1 來表示，0 表示當前字節(jié)已經(jīng)是最后一個字節(jié)，1 表示這個數(shù)字后面還有一個字節(jié)。
對于 int32 類型數(shù)字，一般需要 4 個字節(jié)表示，若采用 Varint 編碼方式，對于很小的 int32 類型數(shù)字，就可以用 1 個字節(jié)來表示。對于大部分整數(shù)類型數(shù)據(jù)來說，一般都是小于 256，所以這種操作可以起到很好地壓縮數(shù)據(jù)的效果。
我們知道 int32 代表正負數(shù)，所以一般最后一位是用來表示正負值，現(xiàn)在 Varint 編碼方式將最后一位用作了標志位，那還如何去表示正負整數(shù)呢?如果使用 int32/int64 表示負數(shù)就需要多個字節(jié)來表示，在 Varint 編碼類型中，通過 Zigzag 編碼進行轉(zhuǎn)換，將負數(shù)轉(zhuǎn)換成無符號數(shù)，再采用 sint32/sint64 來表示負數(shù)，這樣就可以大大地減少編碼后的字節(jié)數(shù)。
rotobuf 的這種數(shù)據(jù)存儲格式，不僅壓縮存儲數(shù)據(jù)的效果好， 在編碼和解碼的性能方面也很高效。Protobuf 的編碼和解碼過程結(jié)合.proto 文件格式，加上 Protocol Buffer 獨特的編碼格式，只需要簡單的數(shù)據(jù)運算以及位移等操作就可以完成編碼與解碼。可以說 Protobuf 的整體性能非常優(yōu)秀。
總結(jié)
Java 默認的序列化是通過 Serializable 接口實現(xiàn)的，只要類實現(xiàn)了該接口，同時生成一個默認的版本號，我們無需手動設(shè)置，該類就會自動實現(xiàn)序列化與反序列化。
Java 默認的序列化雖然實現(xiàn)方便，但卻存在安全漏洞、不跨語言以及性能差等缺陷，所以我強烈建議你避免使用 Java 序列化。
縱觀主流序列化框架，F(xiàn)astJson、Protobuf、Kryo 是比較有特點的，而且性能以及安全方面都得到了業(yè)界的認可，我們可以結(jié)合自身業(yè)務(wù)來選擇一種適合的序列化框架，來優(yōu)化系統(tǒng)的序列化性能。
原文地址：https://mp.weixin.qq.com/s/lumvJUke3TSOwG6-7ZuMzg
