1. 程式人生 > >序列化再探討

序列化再探討

方法體 work The implement 不讓 動作 字節 們的 持久化

從以上技術的討論中我們不難體會到,序列化是Java之所以能夠出色地實現其鼓吹的兩大賣點??分布式(distributed)和跨平臺(OS independent)的一個重要基礎。TIJ(即“Thinking in Java”)談到I/O系統時,把序列化稱為“lightweight persistence”??“輕量級的持久化”,這確實很有意思。

★為什麽叫做“序列”化?

開場白裏我說更習慣於把“Serialization”稱為“序列化”而不是“串行化”,這是有原因的。介紹這個原因之前先回顧一些計算機基本的知識,我們知道現代計算機的內存空間都是線性編址的(什麽是“線性”知道吧,就是一個元素只有一個唯一的“前驅”和唯一的“後繼”,當然頭尾元素是個例外;對於地址來說,它的下一個地址當然不可能有兩個,否則就亂套了),“地址”這個概念推廣到數據結構,就相當於“指針”,這個在本科低年級大概就知道了。註意了,既然是線性的,那“地址”就可以看作是內存空間的“序號”,說明它的組織是有順序的,“序號”或者說“序列號”正是“Serialization”機制的一種體現。為什麽這麽說呢?譬如我們有兩個對象a和b,分別是類A和B的實例,它們都是可序列化的,而A和B都有一個類型為C的屬性,根據前面我們說過的原則,C當然也必須是可序列化的。

1. import java.io.*;

2. ...

3. class A implements Serializable

4. {

5. C c;

6. ...

7. }

8.

9. class B implements Serializable

10. {

11. C c;

12. ...

13. }

14.

15. class C implements Serializable

16. {

17. ...

18. }

19.

20. A a;

21. B b;

22. C c1;

23. ...

註意,這裏我們在實例化a和b的時候,有意讓他們的c屬性使用同一個C類型對象的引用,譬如c1,那麽請試想一下,但我們序列化a和b的時候,它們的c屬性在外部字節流(當然可以不僅僅是文件)裏保存的是一份拷貝還是兩份拷貝呢?序列化在這裏使用的是一種類似於“指針”的方案:它為每個被序列化的對象標上一個“序列號”(serial number),但序列化一個對象的時候,如果其某個屬性對象是已經被序列化的,那麽這裏只向輸出流寫入該屬性的序列號;從字節流恢復被序列化的對象時,也根據序列號找到對應的流來恢復。這就是“序列化”名稱的由來!這裏我們看到“序列化”和“指針”是極相似的,只不過“指針”是內存空間的地址鏈,而序列化用的是外部流中的“序列號鏈”。

使用“序列號”而不是內存地址來標識一個被序列化的對象,是因為從流中恢復對象到內存,其地址可能就未必是原來的地址了??我們需要的只是這些對象之間的引用關系,而不是死板的原始位置,這在RMI中就更是必要,在兩臺不同的機器之間傳遞對象(流),根本就不可能指望它們在兩臺機器上都具有相同的內存地址。

★更靈活的“序列化”:transient屬性和Externalizable

Serializable確實很方便,方便到你幾乎不需要做任何額外的工作就可以輕松將內存中的對象保存到外部。但有兩個問題使得Serializable的威力收到束縛:

一個是效率問題,《Core Java 2》中指出,Serializable使用系統默認的序列化機制會影響軟件的運行速度,因為需要為每個屬性的引用編號和查號,再加上I/O操作的時間(I/O和內存讀寫差的可是一個數量級的大小),其代價當然是可觀的。

另一個困擾是“裸”的Serializable不可定制,傻乎乎地什麽都給你序列化了,不管你是不是想這麽做。其實你可以有至少三種定制序列化的選擇。其中一種前面已經提到了,就是在implements Serializable的類裏面添加私有的writeObject()和readObject()方法(這種Serializable就不裸了,技術分享圖片),在這兩個方法裏,該序列化什麽,不該序列化什麽,那就由你說了算了,你當然可以在這兩個方法體裏面分別調用ObjectOutputStream.defaultWriteObject()和ObjectInputStream.defaultReadObject()仍然執行默認的序列化動作(那你在代碼上不就做無用功了?呵呵),也可以用ObjectOutputStream.writeObject()和ObjectInputStream.readObject()方法對你中意的屬性進行序列化。但虛擬機一看到你定義了這兩個方法,它就不再用默認的機制了。

如果僅僅為了跳過某些屬性不讓它序列化,上面的動作似乎顯得麻煩,更簡單的方法是對不想序列化的屬性加上transient關鍵字,說明它是個“暫態變量”,默認序列化的時候就不會把這些屬性也塞到外部流裏了。當然,你如果定義writeObject()和readObject()方法的化,仍然可以把暫態變量進行序列化。題外話,像transient、violate、finally這樣的關鍵字初學者可能會不太重視,而現在有的公司招聘就偏偏喜歡問這樣的問題 :(

再一個方案就是不實現Serializable而改成實現Externalizable接口。我們研究一下這兩個接口的源代碼,發現它們很類似,甚至容易混淆。我們要記住的是:Externalizable默認並不保存任何對象相關信息!任何保存和恢復對象的動作都是你自己定義的。Externalizable包含兩個public的方法:

1. public void writeExternal(ObjectOutput out) throws IOException;

2. public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException;

乍一看這和上面的writeObject()和readObject()幾乎差不多,但Serializable和Externalizable走的是兩個不同的流程:Serializable在對象不存在的情況下,就可以僅憑外部的字節序列把整個對象重建出來;但Externalizable在重建對象時,先是調用該類的默認構造函數(即不含參數的那個構造函數)使得內存中先有這麽一個實例,然後再調用readExternal方法對實例中的屬性進行恢復,因此,如果默認構造函數中和readExternal方法中都沒有賦值的那些屬性,特別他們是非基本類型的話,將會是空(null)。在這裏需要註意的是,transient只能用在對Serializable而不是Externalizable的實現裏面。

★序列化與克隆

從“可序列化”的遞歸定義來看,一個序列化的對象貌似對象內存映象的外部克隆,如果沒有共享引用的屬性的化,那麽應該是一個深度克隆。關於克隆的話題有可以談很多,這裏就不細說了,有興趣的話可以參考IBM developerWorks上的一篇文章:JAVA中的指針,引用及對象的clone

序列化再探討