如果你只知道實現 Serializable 介面的物件，可以序列化為本地檔案。那你最好再閱讀該篇文章，文章對序列化進行了更深一步的討論，用實際的例子程式碼講述了序列化的高階認識，包括父類序列化的問題、靜態變數問題、transient 關鍵字的影響、序列化 ID 問題。在筆者實際開發過程中，就多次遇到序列化的問題，在該文章中也會與讀者分享。

引言

　　將Java物件序列化為二進位制檔案的 Java 序列化技術是 Java 系列技術中一個較為重要的技術點，在大部分情況下，開發人員只需要瞭解被序列化的類需要實現 Serializable 介面，使用 ObjectInputStream 和 ObjectOutputStream 進行物件的讀寫。然而在有些情況下，光知道這些還遠遠不夠，文章列舉了筆者遇到的一些真實情境，它們與 Java 序列化相關，通過分析情境出現的原因，使讀者輕鬆牢記 Java 序列化中的一些高階認識。

序列化 ID 問題

　　情境：兩個客戶端 A 和 B 試圖通過網路傳遞物件資料，A 端將物件 C 序列化為二進位制資料再傳給 B，B 反序列化得到 C。

　　問題：C 物件的全類路徑假設為 com.inout.Test，在 A 和 B 端都有這麼一個類檔案，功能程式碼完全一致。也都實現了 Serializable 介面，但是反序列化時總是提示不成功。

　　解決：虛擬機器是否允許反序列化，不僅取決於類路徑和功能程式碼是否一致，一個非常重要的一點是兩個類的序列化 ID 是否一致（就是 private static final long serialVersionUID = 1L）。清單 1 中，雖然兩個類的功能程式碼完全一致，但是序列化 ID 不同，他們無法相互序列化和反序列化。

　　序列化 ID 在 Eclipse 下提供了兩種生成策略，一個是固定的 1L，一個是隨機生成一個不重複的 long 型別資料（實際上是使用 JDK 工具生成），在這裡有一個建議，如果沒有特殊需求，就是用預設的 1L 就可以，這樣可以確保程式碼一致時反序列化成功。那麼隨機生成的序列化 ID 有什麼作用呢，有些時候，通過改變序列化 ID 可以用來限制某些使用者的使用。

特性使用案例

　　讀者應該聽過 Façade 模式，它是為應用程式提供統一的訪問介面，案例程式中的 Client 客戶端使用了該模式，案例程式結構圖如圖 1 所示。

　　Client 端通過 Façade Object 才可以與業務邏輯物件進行互動。而客戶端的 Façade Object 不能直接由 Client 生成，而是需要 Server 端生成，然後序列化後通過網路將二進位制物件資料傳給 Client，Client 負責反序列化得到 Façade 物件。該模式可以使得 Client 端程式的使用需要伺服器端的許可，同時 Client 端和伺服器端的 Façade Object 類需要保持一致。當伺服器端想要進行版本更新時，只要將伺服器端的 Façade Object 類的序列化 ID 再次生成，當 Client 端反序列化 Façade Object 就會失敗，也就是強制 Client 端從伺服器端獲取最新程式。

靜態變數序列化

情境：檢視清單 2 的程式碼。

清單 2. 靜態變數序列化問題程式碼

　　清單 2 中的 main 方法，將物件序列化後，修改靜態變數的數值，再將序列化物件讀取出來，然後通過讀取出來的物件獲得靜態變數的數值並打印出來。依照清單 2，這個 System.out.println(t.staticVar) 語句輸出的是 10 還是 5 呢？最後的輸出是 10，對於無法理解的讀者認為，列印的 staticVar 是從讀取的物件裡獲得的，應該是儲存時的狀態才對。之所以列印 10 的原因在於序列化時，並不儲存靜態變數，這其實比較容易理解，序列化儲存的是物件的狀態，靜態變數屬於類的狀態，因此 序列化並不儲存靜態變數。

父類的序列化與 Transient 關鍵字

　　情境：一個子類實現了 Serializable 介面，它的父類都沒有實現 Serializable 介面，序列化該子類物件，然後反序列化後輸出父類定義的某變數的數值，該變數數值與序列化時的數值不同。

解決：要想將父類物件也序列化，就需要讓父類也實現Serializable 介面。如果父類不實現的話的，就需要有預設的無參的建構函式。 在父類沒有實現 Serializable 介面時，虛擬機器是不會序列化父物件的，而一個 Java 物件的構造必須先有父物件，才有子物件，反序列化也不例外。所以反序列化時，為了構造父物件，只能呼叫父類的無參建構函式作為預設的父物件。因此當我們取 父物件的變數值時，它的值是呼叫父類無參建構函式後的值。如果你考慮到這種序列化的情況，在父類無參建構函式中對變數進行初始化，否則的話，父類變數值都 是預設宣告的值，如 int 型的預設是 0，string 型的預設是 null。

　　Transient 關鍵字的作用是控制變數的序列化，在變數宣告前加上該關鍵字，可以阻止該變數被序列化到檔案中，在被反序列化後，transient 變數的值被設為初始值，如 int 型的是 0，物件型的是 null。

特性使用案例

　　我們熟悉使用 Transient 關鍵字可以使得欄位不被序列化，那麼還有別的方法嗎？根據父類物件序列化的規則，我們可以將不需要被序列化的欄位抽取出來放到父類中，子類實現 Serializable 介面，父類不實現，根據父類序列化規則，父類的欄位資料將不被序列化，形成類圖如圖 2 所示。

　　上圖中可以看出，attr1、attr2、attr3、attr5 都不會被序列化，放在父類中的好處在於當有另外一個 Child 類時，attr1、attr2、attr3 依然不會被序列化，不用重複抒寫 transient，程式碼簡潔。

對敏感欄位加密

　　情境：伺服器端給客戶端傳送序列化物件資料，物件中有一些資料是敏感的，比如密碼字串等，希望對該密碼欄位在序列化時，進行加密，而客戶端如果擁有解密的金鑰，只有在客戶端進行反序列化時，才可以對密碼進行讀取，這樣可以一定程度保證序列化物件的資料安全。

　　解決： 在序列化過程中，虛擬機器會試圖呼叫物件類裡的 writeObject 和 readObject 方法，進行使用者自定義的序列化和反序列化，如果沒有這樣的方法，則預設呼叫是 ObjectOutputStream 的 defaultWriteObject 方法以及 ObjectInputStream 的 defaultReadObject 方法。使用者自定義的 writeObject 和 readObject 方法可以允許使用者控制序列化的過程，比如可以在序列化的過程中動態改變序列化的數值。基於這個原理，可以在實際應用中得到使用，用於敏感欄位的加密工作， 清單 3 展示了這個過程。

在清單 3 的 writeObject 方法中，對密碼進行了加密，在 readObject 中則對 password 進行解密，只有擁有金鑰的客戶端，才可以正確的解析出密碼，確保了資料的安全。執行清單 3 後控制檯輸出如圖 3 所示。

特性使用案例

　　RMI 技術是完全基於 Java 序列化技術的，伺服器端介面呼叫所需要的引數物件來至於客戶端，它們通過網路相互傳輸。這就涉及 RMI 的安全傳輸的問題。一些敏感的欄位，如使用者名稱密碼（使用者登入時需要對密碼進行傳輸），我們希望對其進行加密，這時，就可以採用本節介紹的方法在客戶端對密 碼進行加密，伺服器端進行解密，確保資料傳輸的安全性。

序列化儲存規則

　　清單 3 中對同一物件兩次寫入檔案，打印出寫入一次物件後的儲存大小和寫入兩次後的儲存大小，然後從檔案中反序列化出兩個物件，比較這兩個物件是否為同一物件。一 般的思維是，兩次寫入物件，檔案大小會變為兩倍的大小，反序列化時，由於從檔案讀取，生成了兩個物件，判斷相等時應該是輸入 false 才對，但是最後結果輸出如圖 4 所示。

　　我們看到，第二次寫入物件時檔案只增加了 5 位元組，並且兩個物件是相等的，這是為什麼呢？

　　解答：Java 序列化機制為了節省磁碟空間，具有特定的儲存規則，當寫入檔案的為同一物件時，並不會再將物件的內容進行儲存，而只是再次儲存一份引用，上面增加的 5 位元組的儲存空間就是新增引用和一些控制資訊的空間。反序列化時，恢復引用關係，使得清單 3 中的 t1 和 t2 指向唯一的物件，二者相等，輸出 true。該儲存規則極大的節省了儲存空間。

特性案例分析

　　清單 4 的目的是希望將 test 物件兩次儲存到 result.obj 檔案中，寫入一次以後修改物件屬性值再次儲存第二次，然後從 result.obj 中再依次讀出兩個物件，輸出這兩個物件的 i 屬性值。案例程式碼的目的原本是希望一次性傳輸物件修改前後的狀態。

　　結果兩個輸出的都是 1， 原因就是第一次寫入物件以後，第二次再試圖寫的時候，虛擬機器根據引用關係知道已經有一個相同物件已經寫入檔案，因此只儲存第二次寫的引用，所以讀取時，都是第一次儲存的物件。讀者在使用一個檔案多次 writeObject 需要特別注意這個問題。

小結

　　本文通過幾個具體的情景，介紹了 Java 序列化的一些高階知識，雖說高階，並不是說讀者們都不瞭解，希望用筆者介紹的情景讓讀者加深印象，能夠更加合理的利用 Java 序列化技術，在未來開發之路上遇到序列化問題時，可以及時的解決。由於本人知識水平有限，文章中倘若有錯誤的地方，歡迎聯絡我批評指正。