JavaBean爲何要實現序列化?

我不知道在別人看來，我是什麼樣的人；但在我本身看來，我不過就象是一個在海濱玩耍的小孩，爲不時發現比尋常更爲光滑的一塊卵石或比尋常更爲美麗的一片貝殼而沾沾自喜，而對於展示在我面前的浩瀚的真理的海洋，卻全然沒有發現。

——牛頓

先說一個場景：

例如：客戶端訪問了某個能開啓會話功能的資源， web服務器就會建立一個與該客戶端對應的HttpSession對象，每一個HttpSession對象都要站用必定的內存空間。若是在某一時間段內訪問站點的用戶不少，web服務器內存中就會積累大量的HttpSession對象，消耗大量的服務器內存，即便用戶已經離開或者關閉了瀏覽器，web服務器仍會按必定的規則保留與之對應的HttpSession對象，在他們超時以前，一直佔用web服務器內存資源。

 

這時Session的持久化技術就出現了：

Session的持久化就是web服務器一般將那些暫時不活動但未超時的HttpSession對象轉移到文件系統或數據庫中保存，服務器要使用他們時再將他們從文件系統或數據庫中裝載入內存。

這時又冒出一個問題：對象的儲存、網絡中傳輸 要怎麼搞？

答案也是顯而易見的，最簡單的方式就是，咱們的主題Serializable序列化來解決

 

接着說下三個方面說下Serializable

1、概念：

序列化：把對象轉換爲字節序列的過程稱爲對象的序列化。

反序列化：把字節序列恢復爲對象的過程稱爲對象的反序列化。

2、功能：

就是任何類型只要實現了Serializable接口，就能夠被保存到文件及數據庫中，或者做爲數據流經過網絡發送到別的地方，固然也能夠用管道來傳輸到系統的其餘程序中。

也就是說：一、當你想把的內存中的對象狀態保存到一個文件中或者數據庫中時候；

二、當你想用套接字在網絡上傳送對象的時候；

三、當你想經過RMI傳輸對象的時候；

均可以用序列化來實現，貼近主題

3、JavaBean序列化機制：

JavaBean序列化機制就是把內存中的JavaBean轉換成字節流 (一組byte[ ]) ，這樣JavaBean序列化後能夠很方便的存儲或者在網絡中傳輸。

在反序列化時，JVM會把傳來的字節流中的serialVersionUID與本地相應實體（類）的serialVersionUID進行比較，若是相同就認爲是一致的，能夠進行反序列化，不然就會出現序列化版本不一致的異常。

 

加點料：

api 文檔裏面關於 serialVersionUID 的描述：

序列化運行時使用一個稱爲 serialVersionUID 的版本號與每一個可序列化類相關聯，該序列號在反序列化過程當中用於驗證序列化對象的發送者和接收者是否爲該對象加載了與序列化兼容的類。若是接收者加載的該對象的類的 serialVersionUID 與對應的發送者的類的版本號不一樣，則反序列化將會致使 InvalidClassException。可序列化類能夠經過聲明名爲 "serialVersionUID" 的字段（該字段必須是靜態 (static)、最終 (final) 的 long 型字段）顯式聲明其本身的 serialVersionUID：

若是可序列化類未顯式聲明 serialVersionUID，則序列化運行時將基於該類的各個方面計算該類的默認 serialVersionUID 值，如「Java(TM) 對象序列化規範」中所述。不過，強烈建議 全部可序列化類都顯式聲明 serialVersionUID 值，緣由是計算默認的 serialVersionUID 對類的詳細信息具備較高的敏感性，根據編譯器實現的不一樣可能千差萬別，這樣在反序列化過程當中可能會致使意外的 InvalidClassException。所以，爲保證 serialVersionUID 值跨不一樣 java 編譯器實現的一致性，序列化類必須聲明一個明確的 serialVersionUID 值。還強烈建議使用 private 修飾符顯示聲明 serialVersionUID（若是可能），緣由是這種聲明僅應用於直接聲明類 -- serialVersionUID 字段做爲繼承成員沒有用處。數組類不能聲明一個明確的 serialVersionUID，所以它們老是具備默認的計算值，可是數組類沒有匹配 serialVersionUID 值的要求。