對於一個存在於Java虛擬機中的對象來說其內部的狀態只保持在內存中JVM停止之後這些狀態就丟失了在很多情況下對象的內部狀態是需要被持久化下來的提到持久化最直接的做法是保存到文件系統或是數據庫之中這種做法一般涉及到自定義存儲格式以及繁瑣的數據轉換對象關系映射(Objectrelational mapping)是一種典型的用關系數據庫來持久化對象的方式也存在很多直接存儲對象的對象數據庫對象序列化機制(object serialization)是Java語言內建的一種對象持久化方式可以很容易的在JVM中的活動對象和字節數組(流)之間進行轉換除了可以很簡單的實現持久化之外序列化機制的另外一個重要用途是在遠程方法調用中用來對開發人員屏蔽底層實現細節
基本的對象序列化
由於Java提供了良好的默認支持實現基本的對象序列化是件比較簡單的事待序列化的Java類只需要實現Serializable接口即可Serializable僅是一個標記接口並不包含任何需要實現的具體方法實現該接口只是為了聲明該Java類的對象是可以被序列化的實際的序列化和反序列化工作是通過ObjectOuputStream和ObjectInputStream來完成的ObjectOutputStream的writeObject方法可以把一個Java對象寫入到流中ObjectInputStream的readObject方法可以從流中讀取一個Java對象在寫入和讀取的時候雖然用的參數或返回值是單個對象但實際上操縱的是一個對象圖包括該對象所引用的其它對象以及這些對象所引用的另外的對象Java會自動幫你遍歷對象圖並逐個序列化除了對象之外Java中的基本類型和數組也是可以通過 ObjectOutputStream和ObjectInputStream來序列化的
上面的代碼給出了典型的把Java對象序列化之後保存到磁盤上以及從磁盤上讀取的基本方式 User類只是聲明了實現Serializable接口
在默認的序列化實現中Java對象中的非靜態和非瞬時域都會被包括進來而與域的可見性聲明沒有關系這可能會導致某些不應該出現的域被包含在序列化之後的字節數組中比如密碼等隱私信息由於Java對象序列化之後的格式是固定的其它人可以很容易的從中分析出其中的各種信息對於這種情況一種解決辦法是把域聲明為瞬時的即使用transient關鍵詞另外一種做法是添加一個serialPersistentFields? 域來聲明序列化時要包含的域從這裡可以看到在Java序列化機制中的這種僅在書面層次上定義的契約聲明序列化的域必須使用固定的名稱和類型在後面還可以看到其它類似這樣的契約雖然Serializable只是一個標記接口但它其實是包含有不少隱含的要求下面的代碼給出了 serialPersistentFields的聲明示例即只有firstName這個域是要被序列化的
自定義對象序列化
基本的對象序列化機制讓開發人員可以在包含哪些域上進行定制
如果想對序列化的過程進行更加細粒度的控制
就需要在類中添加writeObject和對應的 readObject方法
這兩個方法屬於前面提到的序列化機制的隱含契約的一部分
在通過ObjectOutputStream的 writeObject方法寫入對象的時候
如果這個對象的類中定義了writeObject方法
就會調用該方法
並把當前 ObjectOutputStream對象作為參數傳遞進去
writeObject方法中一般會包含自定義的序列化邏輯
比如在寫入之前修改域的值
或是寫入額外的數據等
對於writeObject中添加的邏輯
在對應的readObject中都需要反轉過來
與之對應
在添加自己的邏輯之前
推薦的做法是先調用Java的默認實現
在writeObject方法中通過ObjectOutputStream的defaultWriteObject來完成
在readObject方法則通過ObjectInputStream的defaultReadObject來實現
下面的代碼在對象的序列化流中寫入了一個額外的字符串
序列化時的對象替換
在有些情況下
可能會希望在序列化的時候使用另外一個對象來代替當前對象
其中的動機可能是當前對象中包含了一些不希望被序列化的域
比如這些域都是從另外一個域派生而來的;也可能是希望隱藏實際的類層次結構;還有可能是添加自定義的對象管理邏輯
如保證某個類在JVM中只有一個實例
相對於把無關的域都設成transient來說
使用對象替換是一個更好的選擇
提供了更多的靈活性
替換對象的作用類似於Java EE中會使用到的傳輸對象(Transfer Object)
考慮下面的例子
一個訂單系統中需要把訂單的相關信息序列化之後
通過網絡來傳輸
訂單類Order引用了客戶類Customer
在默認序列化的情況下
Order類對象被序列化的時候
其引用的Customer類對象也會被序列化
這可能會造成用戶信息的洩露
對於這種情況
可以創建一個另外的對象來在序列化的時候替換當前的Order類的對象
並把用戶信息隱藏起來
這個替換對象類OrderReplace只保存了Order的ID
在Order類的writeReplace方法中返回了一個OrderReplace對象
這個對象會被作為替代寫入到流中
同樣的
需要在OrderReplace類中定義一個readResolve方法
用來在讀取的時候再轉換回 Order類對象
這樣對調用者來說
替換對象的存在就是透明的
序列化與對象創建
在通過ObjectInputStream的readObject方法讀取到一個對象之後
這個對象是一個新的實例
但是其構造方法是沒有被調用的
其中的域的初始化代碼也沒有被執行
對於那些沒有被序列化的域
在新創建出來的對象中的值都是默認的
也就是說
這個對象從某種角度上來說是不完備的
這有可能會造成一些隱含的錯誤
調用者並不知道對象是通過一般的new操作符來創建的
還是通過反序列化所得到的
解決的辦法就是在類的readObject方法裡面
再執行所需的對象初始化邏輯
對於一般的Java類來說
構造方法中包含了初始化的邏輯
可以把這些邏輯提取到一個方法中
在readObject方法中調用此方法
版本更新
把一個Java對象序列化之後
所得到的字節數組一般會保存在磁盤或數據庫之中
在保存完成之後
有可能原來的Java類有了更新
比如添加了額外的域
這個時候從兼容性的角度出發
要求仍然能夠讀取舊版本的序列化數據
在讀取的過程中
當ObjectInputStream發現一個對象的定義的時候
會嘗試在當前JVM中查找其Java類定義
這個查找過程不能僅根據Java類的全名來判斷
因為當前JVM中可能存在名稱相同
但是含義完全不同的Java 類
這個對應關系是通過一個全局惟一標識符serialVersionUID來實現的
通過在實現了Serializable接口的類中定義該域
就聲明了該Java類的一個惟一的序列化版本號
JVM會比對從字節數組中得出的類的版本號
與JVM中查找到的類的版本號是否一致
來決定兩個類是否是兼容的
對於開發人員來說
需要記得的就是在實現了Serializable接口的類中定義這樣的一個域
並在版本更新過程中保持該值不變
當然
如果不希望維持這種向後兼容性
換一個版本號即可
該域的值一般是綜合Java類的各個特性而計算出來的一個哈希值
可以通過Java提供的serialver命令來生成
在Eclipse中
如果Java類實現了Serializable接口
Eclipse會提示並幫你生成這個serialVersionUID
在類版本更新的過程中
某些操作會破壞向後兼容性
如果希望維持這種向後兼容性
就需要格外的注意
一般來說
在新的版本中添加東西不會產生什麼問題
而去掉一些域則是不行的
序列化安全性
前面提到
Java對象序列化之後的內容格式是公開的
所以可以很容易的從中提取出各種信息
從實現的角度來說
可以從不同的層次來加強序列化的安全性
對序列化之後的流進行加密
這可以通過CipherOutputStream來實現
實現自己的writeObject和readObject方法
在調用defaultWriteObject之前
先對要序列化的域的值進行加密處理
使用一個SignedObject或SealedObject來封裝當前對象
用SignedObject或SealedObject進行序列化
在從流中進行反序列化的時候
可以通過ObjectInputStream的registerValidation方法添加ObjectInputValidation接口的實現
用來驗證反序列化之後得到的對象是否合法
RMI
RMI(Remote Method Invocation)是Java中的遠程過程調用(Remote Procedure Call
RPC)實現
是一種分布式Java應用的實現方式
它的目的在於對開發人員屏蔽橫跨不同JVM和網絡連接等細節
使得分布在不同JVM上的對象像是存在於一個統一的JVM中一樣
可以很方便的互相通訊
之所以在介紹對象序列化之後來介紹RMI
主要是因為對象序列化機制使得RMI非常簡單
調用一個遠程服務器上的方法並不是一件困難的事情
開發人員可以基於Apache MINA或是Netty這樣的框架來寫自己的網絡服務器
亦或是可以采用REST架構風格來編寫HTTP服務
但這些解決方案中
不可回避的一個部分就是數據的編排和解排(marshal/unmarshal)
需要在Java對象和傳輸格式之間進行互相轉換
而且這一部分邏輯是開發人員無法回避的
RMI的優勢在於依靠Java序列化機制
對開發人員屏蔽了數據編排和解排的細節
要做的事情非常少
JDK
之後
RMI通過動態代理機制去掉了早期版本中需要通過工具進行代碼生成的繁瑣方式
使用起來更加簡單
RMI采用的是典型的客戶端
服務器端架構
首先需要定義的是服務器端的遠程接口
這一步是設計好服務器端需要提供什麼樣的服務
對遠程接口的要求很簡單
只需要繼承自RMI中的Remote接口即可
Remote和Serializable一樣
也是標記接口
遠程接口中的方法需要拋出RemoteException
定義好遠程接口之後
實現該接口即可
如下面的Calculator是一個簡單的遠程接口
實現了遠程接口的類的實例稱為遠程對象
創建出遠程對象之後
需要把它注冊到一個注冊表之中
這是為了客戶端能夠找到該遠程對象並調用
CalculatorServer是遠程對象的Java類
在它的start方法中通過UnicastRemoteObject的exportObject把當前對象暴露出來
使得它可以接收來自客戶端的調用請求
再通過Registry的rebind方法進行注冊
使得客戶端可以查找到
客戶端的實現就是首先從注冊表中查找到遠程接口的實現對象
再調用相應的方法即可
實際的調用雖然是在服務器端完成的
但是在客戶端看來
這個接口中的方法就好像是在當前JVM中一樣
這就是RMI的強大之處
在運行的時候
需要首先通過rmiregistry命令來啟動RMI中用到的注冊表服務器
為了通過Java的序列化機制來進行傳輸
遠程接口中的方法的參數和返回值
要麼是Java的基本類型
要麼是遠程對象
要麼是實現了 Serializable接口的Java類
當客戶端通過RMI注冊表找到一個遠程接口的時候
所得到的其實是遠程接口的一個動態代理對象
當客戶端調用其中的方法的時候
方法的參數對象會在序列化之後
傳輸到服務器端
服務器端接收到之後
進行反序列化得到參數對象
並使用這些參數對象
在服務器端調用實際的方法
調用的返回值Java對象經過序列化之後
再發送回客戶端
客戶端再經過反序列化之後得到Java對象
返回給調用者
這中間的序列化過程對於使用者來說是透明的
由動態代理對象自動完成
除了序列化之外
RMI還使用了動態類加載技術
當需要進行反序列化的時候
如果該對象的類定義在當前JVM中沒有找到
RMI會嘗試從遠端下載所需的類文件定義
可以在RMI程序啟動的時候
通過JVM參數debase來指定動態下載Java類文件的URL
From:http://tw.wingwit.com/Article/program/Java/hx/201311/25699.html