序列化: 一個(gè)老家伙的咸魚翻身
1.寒冬的蟄伏
這里的工作很繁忙，一年365天， 一天24小時(shí)幾乎不停工。
但是我卻是一個(gè)閑人， 因?yàn)槲易龅墓ぷ髯罱玫娜颂倭耍?經(jīng)常被冷落在一邊。
大多數(shù)時(shí)候，我只能羨慕的看著線程、反射、注解、集合、泛型這些明星員工在那里忙忙碌碌， 聽著他們充滿激情的的大聲說(shuō)笑。
他們都叫我序列化，想想也是， 我的工作就是把一個(gè)Java 對(duì)象變成二進(jìn)制的字節(jié)流， 或者反過(guò)來(lái)把字節(jié)流變成Java 對(duì)象， 這有什么意思?
當(dāng)大家需要一個(gè)Java 對(duì)象的時(shí)候， 直接new 出來(lái)不就得了， 對(duì)象不用了自然有令人膽戰(zhàn)心驚的垃圾回收去處理。
但是存在即合理， 在JDk1.1的時(shí)代， 我就已經(jīng)存在了。 當(dāng)時(shí)人們的思想很超前： 網(wǎng)絡(luò)就是計(jì)算機(jī)。 一個(gè)個(gè)Java 對(duì)象應(yīng)該可以在網(wǎng)絡(luò)中到處旅行 ： 從一個(gè)機(jī)器出發(fā)時(shí)，就變成二進(jìn)制字節(jié)流，順著網(wǎng)絡(luò)跨過(guò)千山萬(wàn)水， 到達(dá)另外一臺(tái)機(jī)器，在那里搖身一變，恢復(fù)成Java 對(duì)象， 在那里繼續(xù)運(yùn)算。
既然可以以二進(jìn)制方式在網(wǎng)絡(luò)中漫游， 那自然也可以把這些字節(jié)流存到硬盤中， 當(dāng)JVM停機(jī)，整個(gè)世界坍塌以后， 線程，反射，注解都不復(fù)存在了， 而我的字節(jié)流還會(huì)在硬盤上默默等待， 等待下一次JVM的重生， 把對(duì)象恢復(fù)。
所以我覺(jué)得我的工作也很有價(jià)值， 從某種意義上來(lái)講， 我可以讓Java 對(duì)象跨越時(shí)間和空間而永生 !
這種永生是有代價(jià)的， 首先你必須得用Java， 這是廢話， 因?yàn)槲抑皇莏ava對(duì)象序列化。
雖然那二進(jìn)制字節(jié)流的格式是公開的， 你可以用任何語(yǔ)言(C,C++,Python...)去解析讀取， 但是解析以后又有什么用處呢? 那些字節(jié)流中會(huì)告知你這是哪個(gè)類的數(shù)據(jù)，字段的類型和值， 但是如果你沒(méi)有相對(duì)應(yīng)的Java 類，還是無(wú)法構(gòu)建出Java 對(duì)象出來(lái)。
其次， 做序列化雙方的類必須得一致， 要不然肯定出亂子。
大部分人都不知道在上個(gè)世紀(jì)末和本世紀(jì)初， 我還是隨著J2EE火了一陣， 當(dāng)時(shí)J2EE中有個(gè)叫RMI東西， 其實(shí)就是Java RPC。 由于我卓越的工作， 開發(fā)人員用可以輕松的調(diào)用遠(yuǎn)程服務(wù)器上的Java 方法， 就相當(dāng)于調(diào)用本地方法一樣， 很方便。
可惜的是這個(gè)RMI只能用在Java環(huán)境中，對(duì)于服務(wù)器來(lái)說(shuō)這根本不是問(wèn)題， 但是當(dāng)時(shí)Web應(yīng)用正在興起， 一個(gè)瀏覽器中是很難有Java環(huán)境的， 所以RMI很快就沒(méi)落了， 我也隨之被打入冷宮， 我也只好蟄伏下來(lái)，等待機(jī)會(huì)。
2.XML和JSON的挑戰(zhàn)
后來(lái)我們這里來(lái)了一個(gè)叫XML的小伙子，很受大家的歡迎， 都喜歡把Java 對(duì)象序列化的工作交給他去做。
我不能坐以待斃， 我仔細(xì)的觀察了幾天以后， 終于發(fā)現(xiàn)這個(gè)家伙有個(gè)大缺點(diǎn)： 太復(fù)雜了!
對(duì)于我的Java 序列化，大部分情況下你只需要讓你的類實(shí)現(xiàn)Serializable接口， 我就可以接管后續(xù)的所有工作。不用你操心了。
可是用XML, 你還得寫一堆代碼把一個(gè)類中的各個(gè)字段和他們的值變成XML標(biāo)簽/屬性/值 才行。 當(dāng)用來(lái)表示對(duì)象的XML字符串漫游到另外一個(gè)機(jī)器上， 還得有一堆代碼把XML變成對(duì)象。
我嘲笑XML說(shuō)： “小伙子， 你這也太麻煩了吧， 人類的時(shí)間多寶貴， 為了用XML做序列化，代價(jià)好高嗷!”
“老家伙，沒(méi)你想的那么復(fù)雜， 你可能不知道， 我們有些類庫(kù)能自動(dòng)幫助把對(duì)象變成XML” 他毫不示弱。
“ 不要忘了 ” 小伙子補(bǔ)充道 “ 我們XML可是語(yǔ)言中立的， 在這里是Java對(duì)象， 到了客戶端 什么語(yǔ)言都行 ， Java/C/Python/Ruby.... 都沒(méi)問(wèn)題， 甚至瀏覽器里的Javascript都能處理， 這一點(diǎn)你不行了吧?”
這家伙戳到了我的痛處， 在瀏覽器中我的確需要一個(gè)Java 環(huán)境才行運(yùn)行 ， 唉，真是成也Java ,敗也Java。
我說(shuō)： “我知道你是語(yǔ)言無(wú)關(guān)的， 但是你注意到?jīng)]有， 你的XML標(biāo)簽冗余太多， 真正的數(shù)據(jù)很少。 比如有個(gè)Person類， 有兩個(gè)字段name和address, 用你的XML做序列化就變成了這個(gè)樣子<person><name>abc</name><address>xyz</address></person>， 這在網(wǎng)絡(luò)上傳輸起來(lái)絕對(duì)是一種浪費(fèi)! 我的java 字節(jié)流就不一樣了， 二進(jìn)制的，非常緊湊，一點(diǎn)都不浪費(fèi)!“
XML小伙子沉默了， 小樣， 我也抓住了你的痛點(diǎn)。
過(guò)了兩天，這個(gè)小伙子又帶來(lái)了一個(gè)叫JSON的小弟， 他得意洋洋的向我炫耀： 用了JSON以后，數(shù)據(jù)精簡(jiǎn)多了， 不信你看：{"name”：“abc", "address":"xyz"} ， 現(xiàn)在我們不但語(yǔ)言中立，還很精簡(jiǎn)， 老家伙，這下你無(wú)話可說(shuō)了吧。
我認(rèn)栽， 但是讓XML也沒(méi)高興多久， 讓他沒(méi)有想到的是， Web時(shí)代JSON和Javascript是一對(duì)絕配， 聯(lián)手統(tǒng)治了瀏覽器。 連XML自己都快沒(méi)飯吃了。
3.新協(xié)議的崛起
其實(shí)我一直覺(jué)得我的二進(jìn)制序列化方式能減少存儲(chǔ)空間， 方便網(wǎng)絡(luò)傳輸，只是我的硬傷是無(wú)法跨越語(yǔ)言。
不行， 我不能一直守著Java這一畝三分地了， 必須擴(kuò)展支持多語(yǔ)言， 這樣才能脫離Java環(huán)境。
有人說(shuō)： 計(jì)算機(jī)的所有問(wèn)題都可以通過(guò)增加一個(gè)中間層來(lái)解決。 我是不是也可以搞個(gè)中間層出來(lái)?
讓這個(gè)中間層來(lái)定義/描述消息的格式，然后再弄一個(gè)小翻譯器( 不，叫編譯器顯的更加高大上)， 把這個(gè)程序員自定義的消息格式轉(zhuǎn)換成各種語(yǔ)言的實(shí)現(xiàn)，例如java, python, c++等等。
在轉(zhuǎn)換好的語(yǔ)言實(shí)現(xiàn)里邊，自動(dòng)包含了要被序列化的類的定義， 以及實(shí)現(xiàn)序列化和反序列化的代碼， 當(dāng)然序列化以后的數(shù)據(jù)是二進(jìn)制的。
等到二進(jìn)制的字節(jié)流通過(guò)網(wǎng)絡(luò)傳輸?shù)搅硗庖慌_(tái)機(jī)器， 就可以反序列化為各種語(yǔ)言(例如Python)的對(duì)象了， 當(dāng)然必須是同一個(gè)消息格式產(chǎn)生的Python類。
不僅僅是Python, C++, Go, C# , 甚至Javascript 都可以用 !
是不是很爽 ? 既語(yǔ)言中立， 又采用二進(jìn)制傳輸， 體積小，解析快， ***的綜合了各種優(yōu)點(diǎn)!
唯一的額外工作是需要把消息格式的定義編譯成各種語(yǔ)言的實(shí)現(xiàn)， 為了能支持多語(yǔ)言，這也是沒(méi)辦法的事情 。
我得意的把新方案給XML和JSON這兩個(gè)家伙看了， 從表情來(lái)看，就知道他倆如臨大敵了。
我也把方案提交給了我們服務(wù)器世界的老大 ， 他大為贊賞， 決定先在部分場(chǎng)景下用起來(lái)， 例如對(duì)象存入緩存的時(shí)候需要序列化， 以前用json, 占用空間很大， 改用了我的新方案以后， 不但減少了空間使用， 還提升了讀寫的效率， 效果不錯(cuò)。
我成功地扳回了一局，現(xiàn)在找我用新方案來(lái)做序列化的人越來(lái)越多了， 但是最終鹿死誰(shuí)手還很難說(shuō)，最有可能的情況是，各種方案混合使用， 即使是這樣，我也很滿足了。
【本文為51CTO專欄作者“劉欣”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過(guò)作者微信公眾號(hào)coderising獲取授權(quán)】
