序列化： 一個老傢伙的鹹魚翻身（Java對象、XML、JSON、反序列化）

轉自：碼農翻身（微信號：coderising）

一、寒冬的蟄伏

這裏的工做很繁忙，一年365天， 一天24小時幾乎不停工。

可是我倒是一個閒人， 由於我作的工做最近用的人太少了， 常常被冷落在一邊。

大多數時候，我只能羨慕的看着線程、反射、註解、集合、泛型這些明星員工在那裏忙忙碌碌， 聽着他們充滿激情的的大聲說笑。

他們都叫我序列化，想一想也是， 個人工做就是把一個Java 對象變成二進制的字節流， 或者反過來把字節流變成Java 對象， 這有什麼意思？

當你們須要一個Java 對象的時候， 直接new 出來不就得了， 對象不用了天然有使人膽戰心驚的垃圾回收去處理。

可是存在即合理， 在JDk1.1的時代， 我就已經存在了。 當時人們的思想很超前： 網絡就是計算機。 一個個Java 對象應該能夠在網絡中處處旅行 ： 從一個機器出發時，就變成二進制字節流，順着網絡跨過千山萬水， 到達另一臺機器，在那裏搖身一變，恢復成Java 對象， 在那裏繼續運算。

既然能夠以二進制方式在網絡中漫遊， 那天然也能夠把這些字節流存到硬盤中， 當JVM停機，整個世界坍塌之後， 線程，反射，註解都不復存在了， 而個人字節流還會在硬盤上默默等待， 等待下一次JVM的重生， 把對象恢復。

因此我以爲個人工做也頗有價值， 從某種意義上來說， 我可讓Java 對象跨越時間和空間而永生 ！

這種永生是有代價的， 首先你必須得用Java， 這是廢話， 由於我只是java對象序列化。

雖然那二進制字節流的格式是公開的， 你能夠用任何語言(C,C++,Python…)去解析讀取， 可是解析之後又有什麼用處呢？ 那些字節流中會告知你這是哪一個類的數據，字段的類型和值， 可是若是你沒有相對應的Java 類，仍是沒法構建出Java 對象出來。
其次， 作序列化雙方的類必須得一致， 要否則確定出亂子。

大部分人都不知道在上個世紀末和本世紀初， 我仍是隨着J2EE火了一陣， 當時J2EE中有個叫RMI東西， 其實就是Java RPC。 因爲我卓越的工做， 開發人員用能夠輕鬆的調用遠程服務器上的Java 方法， 就至關於調用本地方法同樣， 很方便。

惋惜的是這個RMI只能用在Java環境中，對於服務器來講這根本不是問題， 可是當時Web應用正在興起， 一個瀏覽器中是很難有Java環境的， 因此RMI很快就沒落了， 我也隨之被打入冷宮， 我也只好蟄伏下來，等待機會。

序列化生成代碼

二、XML和JSON的挑戰

後來咱們這裏來了一個叫XML的小夥子，很受你們的歡迎， 都喜歡把Java 對象序列化的工做交給他去作。

我不能坐以待斃， 我仔細的觀察了幾天之後， 終於發現這個傢伙有個大缺點： 太複雜了！

對於個人Java 序列化，大部分狀況下你只須要讓你的類實現Serializable接口， 我就能夠接管後續的全部工做。不用你操心了。

但是用XML, 你還得寫一堆代碼把一個類中的各個字段和他們的值變成XML標籤/屬性/值 才行。 當用來表示對象的XML字符串漫遊到另一個機器上， 還得有一堆代碼把XML變成對象。

我嘲笑XML說： 「小夥子， 你這也太麻煩了吧， 人類的時間多寶貴， 爲了用XML作序列化，代價好高嗷！」

「老傢伙，沒你想的那麼複雜， 你可能不知道， 咱們有些類庫能自動幫助把對象變成XML」 他絕不示弱。

「 不要忘了 」 小夥子補充道 「 咱們XML但是語言中立的， 在這裏是Java對象， 到了客戶端 什麼語言都行 ， Java/C/Python/Ruby… 都沒問題， 甚至瀏覽器裏的Javascript都能處理， 這一點你不行了吧？」

這傢伙戳到了個人痛處， 在瀏覽器中個人確須要一個Java 環境才行運行 ， 唉，真是成也Java ,敗也Java。

我說： 「我知道你是語言無關的， 可是你注意到沒有， 你的XML標籤冗餘太多， 真正的數據不多。 好比有個Person類， 有兩個字段name和address, 用你的XML作序列化就變成了這個樣子

<person>
    <name>abc</name>
    <address>xyz</address>
</person>

， 這在網絡上傳輸起來絕對是一種浪費！ 個人java 字節流就不同了， 二進制的，很是緊湊，一點都不浪費！「

XML小夥子沉默了， 小樣， 我也抓住了你的痛點。

過了兩天，這個小夥子又帶來了一個叫JSON的小弟， 他得意洋洋的向我炫耀： 用了JSON之後，數據精簡多了， 不信你看：{「name」：「abc」, 「address」:「xyz」} ， 如今咱們不但語言中立，還很精簡， 老傢伙，這下你無話可說了吧。

我認栽， 可是讓XML也沒高興多久， 讓他沒有想到的是， Web時代JSON和Javascript是一對絕配， 聯手統治了瀏覽器。 連XML本身都快沒飯吃了。

三、新協議的崛起

其實我一直以爲個人二進制序列化方式能減小存儲空間， 方便網絡傳輸，只是個人硬傷是沒法跨越語言。

不行， 我不能一直守着Java這一畝三分地了， 必須擴展支持多語言， 這樣才能脫離Java環境。

有人說： 計算機的全部問題均可以經過增長一箇中間層來解決。 我是否是也能夠搞箇中間層出來？

讓這個中間層來定義/描述消息的格式，而後再弄一個小翻譯器（ 不，叫編譯器顯的更加高大上）， 把這個程序員自定義的消息格式轉換成各類語言的實現，例如java, python, c++等等。

在轉換好的語言實現裏邊，自動包含了要被序列化的類的定義， 以及實現序列化和反序列化的代碼， 固然序列化之後的數據是二進制的。

等到二進制的字節流經過網絡傳輸到另一臺機器， 就能夠反序列化爲各類語言（例如Python）的對象了， 固然必須是同一個消息格式產生的Python類。

不只僅是Python, C++, Go, C# , 甚至Javascript 均可以用 ！

是否是很爽 ？ 既語言中立， 又採用二進制傳輸， 體積小，解析快， 完美的綜合了各類優勢！

惟一的額外工做是須要把消息格式的定義編譯成各類語言的實現， 爲了能支持多語言，這也是沒辦法的事情 。

我得意的把新方案給XML和JSON這兩個傢伙看了， 從表情來看，就知道他倆如臨大敵了。

我也把方案提交給了咱們服務器世界的老大 ， 他大爲讚揚， 決定先在部分場景下用起來， 例如對象存入緩存的時候須要序列化， 之前用json, 佔用空間很大， 改用了個人新方案之後， 不但減小了空間使用， 還提高了讀寫的效率， 效果不錯。

我成功地扳回了一局，如今找我用新方案來作序列化的人愈來愈多了， 可是最終鹿死誰手還很難說，最有可能的狀況是，各類方案混合使用， 即便是這樣，我也很知足了。