談談J2SE中的序列化之接受默認序列化
首先要了解java默認的序列化行為，java將一切關于對象的信息都保存了下了，也就是說，有些時候那些不需要保存的也被保存了下來。一般情況下，我們僅僅需要保存邏輯數(shù)據(jù)就可以了。不需要保存的數(shù)據(jù)我們可以用關鍵字transient標出。
以下是一個例子：
- import java.io.*;
- public class Serial implements Serializable {
- int company_id;
- String company_addr;
- transient boolean company_flag;
- }
則company_flag字段將不會參與序列化與反序列化，但同時你也增加了為他初始值的責任。這也是序列化常常導致的問題之一。因為序列化相當于一個只接受數(shù)據(jù)流的public構(gòu)造函數(shù)，這種對象構(gòu)造方法是語言之外的。但他仍然是一種形式上的構(gòu)造函數(shù)。如若你的類不能夠通過其他方面來保證初始化，則你需要額外的提供readObject方法，首先正常的反序列化，然后對transient標示的字段進行初始化。
在不適合的時候，使用java默認的序列化行為可能會帶來速度上的影響，最糟糕的情況是，可能導致溢出。在某些數(shù)據(jù)結(jié)構(gòu)的實現(xiàn)中，經(jīng)常會充斥著各種的循環(huán)引用，而java 的默認序列化行為，并不了解你的對象結(jié)構(gòu)，其結(jié)果就是java試圖通過一種昂貴的“圖遍歷”來保存對象狀態(tài)。可想而知，不但慢而且可能溢出。這時候你就要提供自己的readObject，來代替默認的行為。
兼容性問題
兼容性歷來是復雜而麻煩的問題。
不要兼容性：
首先來看看如果我們的目的是不要兼容性，應該注意哪些。不要兼容性的場合很多，比如war3每當版本升級就不能夠讀取以前的replays。
兼容也就是版本控制，java通過一個名為UID(stream unique identifier)來控制，這個UID是隱式的，它通過類名，方法名等諸多因素經(jīng)過計算而得，理論上是一一映射的關系，也就是唯一的。如果UID不一樣的話，就無法實現(xiàn)反序列化了，并且將會得到InvalidClassException。
當我們要人為的產(chǎn)生一個新的版本(實現(xiàn)并沒有改動)，而拋棄以前的版本的話，可以通過顯式的聲名UID來實現(xiàn)：
- private static final long serialVersionUID=????;
你可以編造一個版本號，但注意不要重復。這樣在反序列化的時候老版本將得到InvalidClassException，我們可以在老版本的地方捕捉這個異常，并提示用戶升級的新的版本。
當改動不大時，保持兼容性(向下兼容性的一個特例)：
有時候你的類增加了一些無關緊要的非私有方法，而邏輯字段并不改變的時候，你當然希望老版本和新版本保持兼容性，方法同樣是通過顯式的聲名UID來實現(xiàn)。下面我們驗證一下。
老版本：
- import java.io.*;
- public class Serial implements Serializable {
- int company_id;
- String company_addr;
- public Serial1(int company_id, String company_addr) {
- this.company_id = company_id;
- this.company_addr = company_addr;
- }
- public String toString() {
- return "DATA: "+company_id+" "+
- company_addr;
- }
- }
新版本
- import java.io.*;
- public class Serial implements Serializable {
- int company_id;
- String company_addr;
- public Serial1(int company_id, String company_addr) {
- this.company_id = company_id;
- this.company_addr = company_addr;
- }
- public String toString() {
- return "DATA: "+company_id+" "+ company_addr;
- }
- public void todo(){}//無關緊要的方法
- }
首先將老版本序列化，然后用新版本讀出，發(fā)生錯誤：
- java.io.InvalidClassException: Serial.Serial1; local class incompatible: stream classdesc serialVersionUID = 762508508425139227, local class serialVersionUID = 1187169935661445676
接下來我們加入顯式的聲名UID：
- private static final long serialVersionUID=762508508425139227l;
再次運行，順利地產(chǎn)生新對象
DATA: 1001 com1
如何保持向上兼容性：
向上兼容性是指老的版本能夠讀取新的版本序列化的數(shù)據(jù)流。常常出現(xiàn)在我們的服務器的數(shù)據(jù)更新了，仍然希望老的客戶端能夠支持反序列化新的數(shù)據(jù)流，直到其更新到新的版本?？梢哉f，這是半自動的事情。
跟一般的講，因為在java中serialVersionUID是唯一控制著能否反序列化成功的標志，只要這個值不一樣，就無法反序列化成功。但只要這個值相同，無論如何都將反序列化，在這個過程中，對于向上兼容性，新數(shù)據(jù)流中的多余的內(nèi)容將會被忽略;對于向下兼容性而言，舊的數(shù)據(jù)流中所包含的所有內(nèi)容都將會被恢復，新版本的類中沒有涉及到的部分將保持默認值。利用這一特性，可以說，只要我們認為的保持serialVersionUID不變，向上兼容性是自動實現(xiàn)的。
當然，一但我們將新版本中的老的內(nèi)容拿掉，情況就不同了，即使UID保持不變，會引發(fā)異常。正是因為這一點，我們要牢記一個類一旦實現(xiàn)了序列化又要保持向上下兼容性，就不可以隨隨便便的修改了!!!
如何保持向下兼容性：
一如上文所指出的，你會想當然的認為只要保持serialVersionUID不變，向下兼容性是自動實現(xiàn)的。但實際上，向下兼容要復雜一些。這是因為，我們必須要對那些沒有初始化的字段負責。要保證它們能被使用。
所以必須要利用
- private void readObject(java.io.ObjectInputStream in)
- throws IOException, ClassNotFoundException{
- in.defaultReadObject();//先反序列化對象
- if（ver=5552）{
- //以前的版本5552
- …初始化其他字段
- }else if（ver=5550）{
- //以前的版本5550
- …初始化其他字段
- }else{
- //太老的版本不支持
- throw new InvalidClassException();
- }
- }
細心的讀者會注意到要保證in.defaultReadObject();能夠順利執(zhí)行，就必須要求serialVersionUID保持一致，所以這里的ver不能夠利用serialVersionUID了。這里的ver是一個我們預先安插好的final long ver=xxxx;并且它不能夠被transient修飾。所以保持向下的兼容性至少有三點要求：
1.serialVersionUID保持一致
2.預先安插好我們自己的版本識別標志的final long ver=xxxx;
3.保證初始化所有的域
討論一下兼容性策略：
到這里我們可以看到要保持向下的兼容性很麻煩。而且隨著版本數(shù)目的增加。維護會變得困難而繁瑣。討論什么樣的程序應該使用怎么樣的兼容性序列化策略已經(jīng)超出本文的范疇，但是對于一個游戲的存盤功能，和對于一個字處理軟件的文檔的兼容性的要求肯定不同。對于rpg游戲的存盤功能，一般要求能夠保持向下兼容，這里如果使用java序列化的方法，則可根據(jù)以上分析的三點進行準備。對于這樣的情況使用對象序列化方法還是可以應付的。對于一個字處理軟件的文檔的兼容性要求頗高，一般情況下的策略都是要求良好的向下兼容性，和盡可能的向上兼容性。則一般不會使用對象序列化技術(shù)，一個精心設計的文檔結(jié)構(gòu)，更能解決問題。
數(shù)據(jù)一致性問題、約束問題
要知道序列化是另一種形式上的“public構(gòu)造函數(shù)”，但他僅僅構(gòu)造起對象，而不作任何的檢查，這樣人很不舒服，所以必要的檢查是必須的，這利用了readObject()
- private void readObject(java.io.ObjectInputStream in)
- throws IOException, ClassNotFoundException{
- in.defaultReadObject();//先反序列化對象
- …進行檢查與初始化
- }
出于結(jié)構(gòu)化的考慮，通常使用一個名為initialize的函數(shù)，負責檢查與初始化，如果失敗拋出異常。要保持檢查與初始化是很容易被忘記的，這常常導致問題。另一個問題在于當父類沒有加入readObject()的時候，子類很容易忘記要調(diào)用對應的initialize函數(shù)。這仿佛回到了當初為什么要引入構(gòu)造函數(shù)的問題，原因就是防止子類忘記調(diào)用初始化函數(shù)引發(fā)各種問題。所以，如果要保持數(shù)據(jù)一致性，一定要加入readObject()。
安全問題
安全性的話題超出了本文的范疇，但是你應該要知道，有可能一個攻擊者會對你的類準備一個惡意的數(shù)據(jù)流企圖生成一個錯誤的類。當你需要確保你的對象數(shù)據(jù)安全的話，你一般可以利用上面的方法來檢查，并初始化，但對于某些引用不好檢查。解決方法就是對重要的部件進行保護性拷貝。這里推薦一個好方法，它不用保護性拷貝個別的域，而是直接保護性拷貝整個對象。這就是：
- Object readResolve() throws ObjectStreamException;
這個方法的用途就是，他會緊接著readObject()調(diào)用。它將會利用返回的對象代替原來反序列化的對象。也就是原來readObject()反序列化的對象將會被立即的丟棄。
- Object readResolve() throws ObjectStreamException{
- return new Serial2(this.xxx1,this.xxx2);// xxx1、xxx2是剛剛反序列化得來的，這是一種保護性拷貝
- }
這樣的話雖然在時間上有所浪費，但是對于特別的重要而安全的類，可以使用這種方法。如果數(shù)據(jù)一致性問題、約束問題通過逐一檢查來解決很麻煩，也可以利用這種方法，但要考慮好成本，
【編輯推薦】
