作者：riemann_
遇到這個 Java Serializable 序列化這個接口，我們可能會有如下的問題
什麼叫序列化和反序列化
作用。為啥要實作這個 Serializable 接口，也就是為啥要序列化
serialVersionUID 這個的值到底是在怎麼設定的，有什麼用。有的是1L，有的是一長串數字，迷惑ing。
我剛剛見到這個關鍵字 Serializable 的時候，就有如上的這麼些問題。
在處理這個問題之前，你要先知道一個問題，這個比較重要。這個Serializable接口，以及相關的東西，全部都在 Java io 裡面的。
序列化：把對象轉換為位元組序列的過程稱為對象的序列化。
反序列化：把位元組序列恢複為對象的過程稱為對象的反序列化。
上面是專業的解釋，現在來點通俗的解釋。在代碼運作的時候，我們可以看到很多的對象(debug過的都造吧)，可以是一個，也可以是一類對象的集合，很多的對象資料，這些資料中，有些資訊我們想讓他持久的儲存起來，那麼這個序列化。
就是把記憶體裡面的這些對象給變成一連串的位元組描述的過程。
常見的就是變成檔案
我不序列化也可以儲存檔案啥的呀，有什麼影響呢？我也是這麼問的。
當你想把的記憶體中的對象狀态儲存到一個檔案中或者資料庫中時候；
當你想用套接字在網絡上傳送對象的時候；
當你想通過RMI傳輸對象的時候；
(老實說，上面的幾種，我可能就用過個存資料庫的)
實作Serializable接口即可
上面這些理論都比較簡單，下面實際代碼看看這個序列化到底能幹啥，以及會産生的bug問題。
先上對象代碼，FlyPig.java
注意下，注釋的代碼，是一會兒要各種情況下使用的。
下面就是main方法啦
對上面的2個操作檔案流的類的簡單說明
ObjectOutputStream代表對象輸出流：
它的writeObject(Object obj)方法可對參數指定的obj對象進行序列化，把得到的位元組序列寫到一個目标輸出流中。
ObjectInputStream代表對象輸入流：
它的readObject()方法從一個源輸入流中讀取位元組序列，再把它們反序列化為一個對象，并将其傳回。
具體怎麼看運作情況。
第一種：上來就這些代碼，不動，直接run，看效果。
實際運作結果，他會在 d:/flyPig.txt 生成個檔案。
從運作結果上看：
他實作了對象的序列化和反序列化。
transient 修飾的屬性，是不會被序列化的。我設定的奧迪四個圈的車不見啦，成了null。my god。
你先别着急說，這個靜态變量AGE也被序列化啦。這個得另測。
第二種：為了驗證這個靜态的屬性能不能被序列化和反序列化，可如下操作。
這個完了之後，意思也就是說，你先序列化個對象到檔案了。這個對象是帶靜态變量的static。
現在修改flyPig類裡面的AGE的值，給改成26吧。
然後，看下圖裡面的運作代碼和執行結果。
輸出結果：
可以看到，剛剛序列化的269，沒有讀出來。而是剛剛修改的26，如果可以的話，應該是覆寫這個26，是269才對。
是以，得出結論，這個靜态static的屬性，他不序列化。
第三種：示範這個 serialVersionUID 的作用和用法
最暴力的改法，直接把model的類實作的這個接口去掉。然後執行後面的序列化和反序列化的方法。直接報錯。
抛異常：NotSerializableException
這個太暴力啦，不推薦這麼幹。
然後就是，還和上面的操作差不多，先是單獨執行序列化方法。生成檔案。然後，打開屬性 addTip ，這之後，再次執行反序列化方法，看現象。
抛異常：InvalidClassException 詳情如下。
解釋一下：
因為我再model裡面是沒有明确的給這個 serialVersionUID 指派，但是，Java會自動的給我指派的，這個值跟這個model的屬性相關計算出來的。
我儲存的時候，也就是我序列化的時候，那時候還沒有這個addTip屬性呢，是以，自動生成的serialVersionUID 這個值，在我反序列化的時候Java自動生成的這個serialVersionUID值是不同的，他就抛異常啦。
（你還可以反過來，帶ID去序列化，然後，沒ID去反序列化。也是同樣的問題。）
再來一次，就是先序列化，這個時候，把 private static final long serialVersionUID = 1L; 這行代碼的注釋打開。那個addTip屬性先注釋掉，序列化之後，再把這個屬性打開，再反序列化。看看什麼情況。
這個時候，代碼執行OK，一切正常。good。序列化的時候，是沒的那個屬性的，在發序列化的時候，對應的model多了個屬性，但是，反序列化執行OK，沒出異常。
這個現象對我們有什麼意義：
老鐵，這個意義比較大，首先，你要是不知道這個序列化是幹啥的，萬一他真的如開頭所講的那樣存資料庫啦，socket傳輸啦，rmi傳輸啦。雖然我也不知道這是幹啥的。你就給model bean 實作了個這個接口，你沒寫這個 serialVersionUID 那麼在後來擴充的時候，可能就會出現不認識舊資料的bug，那不就炸啦嗎。回憶一下上面的這個出錯情況。想想都可怕，這個鍋誰來背？
是以，有這麼個理論，就是在實作這個Serializable 接口的時候，一定要給這個 serialVersionUID 指派，就是這麼個問題。
這也就解釋了，我們剛剛開始編碼的時候，實作了這個接口之後，為啥IDEA編輯器要黃色警告，需要添加個這個ID的值。而且還是一長串你都不知道怎麼來的數字。
下面解釋這個 serialVersionUID 的值到底怎麼設定才OK。
首先，你可以不用自己去指派，Java會給你指派，但是，這個就會出現上面的bug，很不安全，是以，還得自己手動的來。
那麼，我該怎麼指派，eclipse可能會自動給你指派個一長串數字。這個是沒必要的。
可以簡單的指派個 1L，這就可以啦。。這樣可以確定代碼一緻時反序列化成功。
不同的serialVersionUID的值，會影響到反序列化，也就是資料的讀取，你寫1L，注意L大些。計算機是不區分大小寫的，但是，作為觀衆的我們，是要區分1和L的l，是以說，這個值，閑的沒事不要亂動，不然一個版本更新，舊資料就不相容了，你還不知道問題在哪。。。
第四種：當屬性是對象的時候，沒實作序列化接口
當屬性是對象的時候，如果這個對象，沒實作序列化接口，那麼上面的方法在序列化的時候就在執行oos.writeObject(flyPig)時候，報錯了“Exception in thread “main” java.io.NotSerializableException: com.lxk.model.Bird”。然後給剛剛的屬性的對象加上實作序列化的接口之後，上面的測試就正常通過了。
下面是摘自 jdk api 文檔裡面關于接口 Serializable 的描述
類通過實作 java.io.Serializable 接口以啟用其序列化功能。未實作此接口的類将無法使其任何狀态序列化或反序列化。可序列化類的所有子類型本身都是可序列化的。因為實作接口也是間接的等同于繼承。序列化接口沒有方法或字段，僅用于辨別可序列化的語義。
序列化運作時使用一個稱為 serialVersionUID 的版本号與每個可序列化類相關聯，該序列号在反序列化過程中用于驗證序列化對象的發送者和接收者是否為該對象加載了與序列化相容的類。
如果接收者加載的該對象的類的 serialVersionUID 與對應的發送者的類的版本号不同，則反序列化将會導緻 InvalidClassException。可序列化類可以通過聲明名為 “serialVersionUID” 的字段（該字段必須是靜态 (static)、最終 (final) 的 long 型字段）顯式聲明其自己的 serialVersionUID：
如果可序列化類未顯式聲明 serialVersionUID，則序列化運作時将基于該類的各個方面計算該類的預設 serialVersionUID 值，如“Java™ 對象序列化規範”中所述。
不過，強烈建議 所有可序列化類都顯式聲明 serialVersionUID 值，原因是計算預設的 serialVersionUID 對類的詳細資訊具有較高的敏感性，根據編譯器實作的不同可能千差萬别，這樣在反序列化過程中可能會導緻意外的 InvalidClassException。
是以，為保證 serialVersionUID 值跨不同 java 編譯器實作的一緻性，序列化類必須聲明一個明确的 serialVersionUID 值。還強烈建議使用 private 修飾符顯示聲明 serialVersionUID（如果可能），原因是這種聲明僅應用于直接聲明類 – serialVersionUID 字段作為繼承成員沒有用處。數組類不能聲明一個明确的 serialVersionUID，是以它們總是具有預設的計算值，但是數組類沒有比對 serialVersionUID 值的要求。
