1.序列化的含義和作用

序列化用來將對象編碼成字節流，反序列化就使將字節流編碼重新構建對象。
序列化實現了對象傳輸和對象持久化，所以它能夠為遠程通信提供對象表示法，為JavaBean組件提供持久化數據。

2.序列化的危害

1.降低靈活性：為實現Serializable而付出的最大代價是，一旦一個類被發布，就大大降低了”改變這個類的實現”的靈活性。如果一個類實現了Serializable，它的字節流編碼（或者說序列化形式，serialized form）就變成了它的導出的API的一部分，必須永遠支持這種序列化形式。

而且，特殊地，每個可序列化類都有唯一的標志（serial version id，在類體現為私有靜態final的long域serialVersionUID），如果沒有顯式指示，那么系統就會自動生成一個serialVersionUID，如果下一個版本改變了這個類，那么系統就會重新自動生成一個serialVersionUID。因此如果沒有聲明顯式的uid，會破壞版本之間的兼容性，運行時產生InvalidClassException。

2.降低封裝性：如果你接受了默認的序列化形式，這個類中私有的和包級私有的實例域將都變成導出的API的一部分，這不符合”最低限度地訪問域”的實踐準則。

3.降低安全性：增加了bug和漏洞的可能性，反序列化的過程其實類似于調用對象的構造器，但是這個過程又沒有用到構造器，因此如果字節流被無意修改或被用心不測的人修改，那么服務器很可能會產生錯誤或者遭到攻擊。

16年出現的大名鼎鼎的Java反序列化漏洞本質上就是不恰當的序列化造成的。

4.降低可測試性：隨著類版本的不斷更替，必須滿足版本兼容問題，所以發行的版本越多，測試的難度就越大。

5.降低性能：序列化對象時，不僅會序列化當前對象本身，還會對該對象引用的其他對象也進行序列化。如果一個對象包含的成員變量是容器類等并深層引用時（對象是鏈表形式），此時序列化開銷會很大，這時必須要采用其他一些手段處理。

3.序列化的使用場景

1.需要實現一個類的對象傳輸或者持久化。
2.A是B的組件，當B需要序列化時，A也實現序列化會更容易讓B使用。

4.序列化不適合場景

為了繼承而設計的類應該盡可能少地去實現Serializable接口，用戶接口也應該盡可能不繼承Serializable接口，原因是子類或實現類也要承擔序列化的風險。

5.序列化需要注意的地方

1)如果父類實現了Serializable，子類自動序列化了，不需要實現Serializable；

2)若父類未實現Serializable,而子類序列化了，父類屬性值不會被保存，反序列化后父類屬性值丟失，需要父類有一個無參的構造器，子類要負責序列化(反序列化)父類的域，子類要先序列化自身，再序列化父類的域。

至于為什么需要父類有一個無參的構造器，是因為子類先序列化自身的時候先調用父類的無參的構造器。
實例：

private void writeObject(java.io.ObjectOutputStream out) throws IOException{ out.defaultWriteObject();//先序列化對象 out.writeInt(parentvalue);//再序列化父類的域 } private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException{ in.defaultReadObject();//先反序列化對象 parentvalue=in.readInt();//再反序列化父類的域 }

3)序列化時，只對對象狀態進行了保存，對象方法和類變量等并沒有保存，因此序列化并不保存靜態變量值。

4)當一個對象的實例變量引用其他對象，序列化該對象時也把引用對象序列化了。所以組件也應該序列化。

5)不是所有對象都可以序列化，基于安全和資源方面考慮，如Socket/thread若可序列化，進行傳輸或保存，無法對他們重新分配資源。

總結

以上是生活随笔為你收集整理的Effective Java之谨慎地实现Serializable(七十四)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。