首先還是安利時間：寫文時的歌單是
君に最後の口づけを
IxU
時間煮雨
我好想你
花に亡霊
あの夢をなぞって
たふ?ん
群青
1.數據序列化的意義及必要性
??在開發中時長會遇到需要進行跨進程進行數據傳輸，或者將數據持久化存儲到磁盤或別的什么介質中，而數據在傳輸或存儲前需要進行序列化的過程。
??那么，為什么需要這個序列化的過程呢？它的意義是什么呢？
??有些小伙伴可能會不理解，為什么不能直接把數據在內存中拿出來直接拿去進行傳輸或者存儲呢？
??雖然數據都是存在于內存中這一點是沒有問題的，但對于使用了不同編程語言而開發出來的程序來說，它們會在底層為了高效利用內存與CPU而進行不同的優化，通常來說它們都是指針變種或者升級版，所以對于一個對象來說，它對用戶所表現出來的外觀與它在內存中的里相是不一樣的，舉例來說，假如說有一個Object A，
它表現出來的外觀是這樣的：
{
??int a = 10;
??long b = 9527;
??String s = "鈴木愛理是我老婆";
??char[] carr = [新,垣,結,衣,也,是,我,老,婆];
??Object B:{
????int innerA = 10086;
????long innerB = 1020;
??}
}
但實際上它在內存里是這樣的：
{
??int a = 10;(基礎數據類型是被直接包著的)
??long b = 9527;
??String b -> 2134565（指向字符串對象地址的指針，數字是我亂寫的）
??int[] b -> 689461（指向int數組第0個元素所在地址的指針）
??Object B -> 98463165（指向ObjectB這個對象的指針）
}
所以如果你未經任何處理，直接將ObjectA從內存中復制出來，那么對方最終可能只能接收到一堆無法識別的奇葩數字。
??所以大概可以將序列化的過程簡單地理解為【將不同編程語言為了優化而魔改后的內存中的數據，轉換為可通過某種方法完整還原會內存中的，用于跨進程傳輸或持久化存儲的數據格式】，而這種序列化的方法必須是在某種意義上通用的，與編程語言無關的。
2.常用的序列化格式
①目前互聯網比較流行的XML與JSON
??比較老資格的有XML，以前在銀行里的時候也是經常與XML報文打交道。
??JSON是最近幾年開始流行起來的，似乎是因為大家嫌棄XML冗余體積比較多，浪費了太多網絡帶寬，于是乎JSON出來了，體積更小。
??這兩種格式都是具有很不錯的可讀性的，受過訓練的人類（指程序猿）也能輕易肉眼讀取，并且兼容性也不錯，因為大部分JSON和XML的序列化工具都是根據報文中的變量名進行1對1識別，因此除非是因為業務大規模變更而導致必填項發生變化，不然單純對于實體轉換來說具有很好的向前/向后的兼容性。
??但是使用它們也有需要注意的問題：
??數字編碼模糊。由于這兩種序列化格式中僅有變量名作為標識，因此如果發送方與接收方所定義的實體/數據結構中的數字類型不一致——比如說同為變量a，發送方是double，接收方是int，或者字符串，或者說是所指定的精度不一致的double——這種情況中接收方反序列化時會產生問題
②二進制變種而來的序列化方式
??有部分開發者可能是為了獲得更高的傳輸效率，節省帶寬，而會選擇更緊湊或更快的解析格式。但這些方式一般偏小眾，難以在市場上普及，因此僅作為組織內小范圍應用。
目前比較有名的二進制方式有facebook開源的apache thrift和google開源的protocol buffers，以及apache avro。其中apache avro的壓縮率是最高的。這兩種方式應用起來相對更復雜點（因為需要配置實體信息等各種）
3.模式演化與兼容
??由于市場的發展與業務的變化，所以數據模式總是在發生變化，而對于開發者來說可能不是每一次都會兼顧去把所有的老程序進行升級，因此考慮向前/向后兼容是有必要的。
??對于序列化工具指導兼容性實現的方式有reader模式，writer模式，數據流模式（好像對我來說沒什么卵用，隨便記下來算了）。
神驅一夢
2020.11.15
