要想使一個類的實例可被序列化，非常簡單，只要在它的聲明中加入"implements Serializable"字樣即可。雖然使一個類可被序列化的直接開銷低到甚至可以忽略不計，但是為了序列化而付出的長期開銷往往是實實在在的。

為實現(xiàn)Serializable而付出的最大代價是，一旦一個類被發(fā)布，就大大降低了"改變這個類的實現(xiàn)"的靈活性。 如果一個類實現(xiàn)了Serializable，它的字節(jié)流編碼（或者說序列化形式，serialized form）就變成了它的導出的API的一部分。一旦這個類被廣泛使用，往往必須永遠支持這種序列化形式，就好像你必須要支持導出的API的所有其他部分一樣。如果你不努力設計一個自定義的序列化形式（custom serialized form），而僅僅接受了默認的序列化形式，這種序列化形式將被永遠地束縛在該類最初的內(nèi)部表示法上。換句話說，如果你接受了默認的序列化形式，這個類中私有的和包級私有的實例域?qū)⒍甲兂蓪С龅腁PI的一部分，這不符合"最低限度地訪問域"的實踐準則（見第13條），從而它就失去了作為信息隱藏工具的有效性。

如果你接受了默認的序列化形式，并且以后又要改變這個類的內(nèi)部表示法，結(jié)果可能導致序列化形式的不兼容。客戶端程序企圖用這個類的舊版本來序列化一個類，然后用新版本進行反序列化，結(jié)果將導致程序失敗。在改變內(nèi)部表示法的同時仍然維持原來的序列化形式（使用ObjectOutputStream.putFields和ObjectInputStream.readFields），這也是可能的，但是做起來比較困難，并且會在源代碼中留下一些可以明顯的隱患。因此，你應該仔細地設計一種高質(zhì)量的序列化形式，并且在很長時間內(nèi)都愿意使用這種形式（見第75，78條）。這樣做將會增加開發(fā)的初始成本，但這是值得的。設計良好的序列化形式也許會給類的演變帶來限制；但是設計不好的序列化形式則可能會使類根本無法演變。

序列化會使類的演變受到限制，這種限制的一個例子與流的唯一標識符（stream unique identifier）有關，通常它也被稱為序列版本UID（serial version UID）。每個可序列化的類都有一個唯一標識號與它相關聯(lián)。如果你沒有在一個名為serialVersionUID的私有靜態(tài)final的long域中顯式地指定該標識號，系統(tǒng)就會自動地將一個復雜的過程作用在這個類上，從而在運行時產(chǎn)生該標識號。這個自動產(chǎn)生的值會受到類名稱、它所實現(xiàn)的接口的名稱、以及所有公有的和受保護的成員的名稱所影響。如果你通過任何方式改變了這些信息，比如，增加了一個不是很重要的工具方法，自動產(chǎn)生的序列版本UID也會發(fā)生變化。因此，如果你沒有聲明一個顯式的序列版本UID，兼容性將會遭到破壞，在運行時導致InvalidClassException異常。

實現(xiàn)Serializable的第二個代價是，它增加了出現(xiàn)Bug和安全漏洞的可能性。 通常情況下，對象是利用構(gòu)造器來創(chuàng)建的；序列化機制是一種語言之外的對象創(chuàng)建機制（extralinguistic mechanism）。無論你是接受了默認的行為，還是覆蓋了默認的行為，反序列化機制（deserialization）都是一個"隱藏的構(gòu)造器"，具備與其他構(gòu)造器相同的特點。因為反序列化機制中沒有顯式的構(gòu)造器，所以你很容易忘記要確保：反序列化過程必須也要保證所有"由構(gòu)造器建立起來的約束關系"，并且不允許攻擊者訪問正在構(gòu)造過程中的對象的內(nèi)部信息。依靠默認的反序列化機制，可以很容易地使對象的約束關系遭到破壞，以及遭受到非法訪問（見第76條）。

實現(xiàn)Serializable的第三個代價是，隨著類發(fā)行新的版本，相關的測試負擔也增加了。 當一個可序列化的類被修訂的時候，很重要的一點是，要檢查是否可以"在新版本中序列化一個實例，然后在舊版本中反序列化"，反之亦然。因此，測試所需要的工作量與"可序列化的類的數(shù)量和發(fā)行版本號"的乘積成正比，這個乘積可能會非常大。這些測試不可能自動構(gòu)建，因為除了二進制兼容性（binary compatibility）以外，你還必須測試語義兼容性（semantic compatibility）。換句話說，你必須既要確保"序列化－反序列化"過程成功，也要確保結(jié)果產(chǎn)生的對象真正是原始對象的復制品?？尚蛄谢惖淖兓酱?#xff0c;它就越需要測試。如果在最初編寫一個類的時候，就精心設計了自定義的序列化形式，測試的要求就可以有所降低，但是也不能完全沒有測試。

實現(xiàn)Serializable接口并不是一個很輕松就可以做出的決定。它提供了一些實在的益處：如果一個類將要加入到某個框架中，并且該框架依賴于序列化來實現(xiàn)對象傳輸或者持久化，對于這個類來說，實現(xiàn)Serializable接口就非常有必要。更進一步來看，如果這個類要成為另一個類的一個組件，并且后者必須實現(xiàn)Serializable接口，若前者也實現(xiàn)了Serializable接口，它就會更易于被后者使用。 然而，有許多實際的開銷都與實現(xiàn)Serializable接口有關。每當你實現(xiàn)一個類的時候，都需要權(quán)衡一下所付出的代價和帶來的好處。根據(jù)經(jīng)驗，比如Date和BigInteger這樣的值類應該實現(xiàn)Serializable，大多數(shù)的集合類也應該如此。代表活動實體的類，比如線程池（thread pool），一般不應該實現(xiàn)Serializable。

為了繼承而設計的類（見第17條）應該很少實現(xiàn)Serializable，接口也應該很少會擴展它。如果違反了這條規(guī)則，擴展這個類或者實現(xiàn)這個接口的程序員就會背上沉重的負擔。然而在有些情況下違反這條規(guī)則卻是合適的。例如，如果一個類或者接口存在的目的主要是為了參與到某個框架中，該框架要求所有的參與者都必須實現(xiàn)Serializable，
那么，對于這個類或者接口來說，實現(xiàn)或者擴展Serializable就是非常有意義的。

為了繼承而設計的類中真正實現(xiàn)了Serializable的有Throwable、Component和HttpServlet。因為Throwable實現(xiàn)了Serializable，所以RMI的異?？梢詮姆掌鞫藗鞯娇蛻舳恕omponent實現(xiàn)了Serializable，因此GUI可以被發(fā)送、保存和恢復。HttpServlet實現(xiàn)了Serializable，因此會話狀態(tài)可以被緩存。

如果你實現(xiàn)了一個帶有實例域的類，它是可序列化和可擴展的，你就應該擔心這樣一條告誡。

如果一個專門為了繼承而設計的類不是可序列化的，就不可能編寫出可序列化的子類。特別是，如果超類沒有提供可訪問的無參構(gòu)造器，子類也不可能做到可序列化。因此，對于為繼承而設計的不可序列化的類，你應該考慮提供一個無參構(gòu)造器。

內(nèi)部類不應該實現(xiàn)Serializable。它們使用編譯器產(chǎn)生的合成域（synthetic field）來保存指向外圍實例（enclosing instance）的引用，以及保存來自外圍作用域的局部變量的值。"這些域如何對應到類定義中"并沒有明確的規(guī)定，就好像沒有指定匿名類和局部類的名稱一樣。因此，內(nèi)部類的默認序列化形式是定義不清楚的。然而，靜態(tài)成員類（static member class）卻可以實現(xiàn)Serializable。

簡而言之，千萬不要認為實現(xiàn)Serializable會很容易。除非一個類在用了一段時間之后就會被拋棄，否則，實現(xiàn)Serializable就是個很嚴肅的承諾，必須認真對待。如果一個類是為了繼承而設計的，則更加需要加倍小心。對于這樣的類而言，在"允許子類實現(xiàn)Serializable"或"禁止子類實現(xiàn)Serializable"兩者之間的一個折衷設計方案是，提供一個可訪問的無參構(gòu)造器。這種設計方案允許（但不要求）子類實現(xiàn)Serializable。

所有文章無條件開放，順手點個贊不為過吧！

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??