java序列化與反序列化是一項比較重要的技術點，目前也有很多成熟的組件可以使用比如protobuf、thrift、jute、jdk自帶序列化等諸多可選項。
那麼我們下面就介紹一下序列化相關的內容。
(1)什麼是序列化與反序列化？
序列化：簡潔的說序列化就是將jvm內存中對象的狀態按照約定的某種方式轉換成二進制字節流的過程。
反序列化：按照序列化時的約定方式從二進制字節流中重建對象的過程。
(2)什麼情況下需要序列化和反序列化？
當我們想把jvm內存中的對象持久化到硬盤上的時候，爲了便於重建對象，我們採用序列化這種機制。
當我們通過RPC框架進行遠程 過程調用時，客戶端將請求參數通過序列化的形式傳遞給服務端，服務端反序列化出對象獲取參數。
當我們希望將我們的對象能以字符串形式存儲到Redis等中間件中時，我們可以通過將對象序列化成文本存儲。當需要的時候讀取數據再進行反序列化。
當然還有很多其他可以使用序列化技術的場景，這裏無法一一列舉。
(3)如何選擇序列化和反序列化組件？
面對這麼多的序列化組件，我們該如何選擇呢？當然實際的使用中我們可以通過如下四點來作爲選擇的依據。
- 序列化之後的數據的字節大小
- 序列化和反序列化的效率
- 序列化對象狀態改變之後，是否兼容舊版本客戶端
- 使用上是否需要藉助第三方的IDL工具
不同的序列化組件由於使用了不同的序列化協議，導致序列化後的數據大小不同，理想情況下序列化之後的數據只有對象狀態的數據。然而既要考慮能正常反序列化重建出對象，又要考慮向後兼容舊版本，這就不得不在序列化中增加額外的元數據，記錄對象類名和域的完整信息。
像protobuf、thrift、Ice序列化組件，都是使用IDL來同時爲客戶端和服務端提供序列化對象的細節處理說明。因爲客戶端和服務端都是使用同一套IDL生成的代碼，這樣序列化之後的數據就會相對較小，對於對象的域只序列化域的類型和順序id。而像Json、java自帶序列化api這樣的序列化機制，必須把序列化的詳細數據分佈信息序列化到二進制流中，這樣勢必會造成數據量的增加。
接下來我們會通過代碼的形式來詳細看看java自帶序列化api和thrift序列化的內部機制。