主頁 > 知識(shí)庫 > J2SE中的序默認(rèn)序列化

J2SE中的序默認(rèn)序列化

熱門標(biāo)簽:服務(wù)器配置 Linux服務(wù)器 科大訊飛語音識(shí)別系統(tǒng) 銀行業(yè)務(wù) Mysql連接數(shù)設(shè)置 阿里云 電子圍欄 團(tuán)購網(wǎng)站
要保存的也被保存了下來。一般情況下,我們僅僅需要保存邏輯數(shù)據(jù)就可以了。不需要保存的數(shù)據(jù)我們可以用關(guān)鍵字transient標(biāo)出。

  以下是一個(gè)例子:

  import java.io.*;

  public class Serial implements Serializable {
  int company_id;
  String company_addr;

  transient boolean company_flag;
  }

  則company_flag字段將不會(huì)參與序列化與反序列化,但同時(shí)你也增加了為他初始值的責(zé)任。這也是序列化常常導(dǎo)致的問題之一。因?yàn)樾蛄谢喈?dāng)于一個(gè)只接受數(shù)據(jù)流的public構(gòu)造函數(shù),這種對(duì)象構(gòu)造方法是語言之外的。但他仍然是一種形式上的構(gòu)造函數(shù)。如若你的類不能夠通過其他方面來保證初始化,則你需要額外的提供readObject方法,首先正常的反序列化,然后對(duì)transient標(biāo)示的字段進(jìn)行初始化。

  在不適合的時(shí)候,使用java默認(rèn)的序列化行為可能會(huì)帶來速度上的影響,最糟糕的情況是,可能導(dǎo)致溢出。在某些數(shù)據(jù)結(jié)構(gòu)的實(shí)現(xiàn)中,經(jīng)常會(huì)充斥著各種的循環(huán)引用,而java的默認(rèn)序列化行為,并不了解你的對(duì)象結(jié)構(gòu),其結(jié)果就是java試圖通過一種昂貴的“圖遍歷”來保存對(duì)象狀態(tài)??上攵坏铱赡芤绯?。這時(shí)候你就要提供自己的readObject,來代替默認(rèn)的行為。

  兼容性問題

  兼容性歷來是復(fù)雜而麻煩的問題。

  不要兼容性:

  首先來看看如果我們的目的是不要兼容性,應(yīng)該注意哪些。不要兼容性的場(chǎng)合很多,比如war3每當(dāng)版本升級(jí)就不能夠讀取以前的replays。

  兼容也就是版本控制,java通過一個(gè)名為UID(stream unique identifier)來控制,這個(gè)UID是隱式的,它通過類名,方法名等諸多因素經(jīng)過計(jì)算而得,理論上是一一映射的關(guān)系,也就是唯一的。如果UID不一樣的話,就無法實(shí)現(xiàn)反序列化了,并且將會(huì)得到InvalidClassException。

  當(dāng)我們要人為的產(chǎn)生一個(gè)新的版本(實(shí)現(xiàn)并沒有改動(dòng)),而拋棄以前的版本的話,可以通過顯式的聲名UID來實(shí)現(xiàn):

  private static final long serialVersionUID=????;

  你可以編造一個(gè)版本號(hào),但注意不要重復(fù)。這樣在反序列化的時(shí)候老版本將得到InvalidClassException,我們可以在老版本的地方捕捉這個(gè)異常,并提示用戶升級(jí)的新的版本。

  當(dāng)改動(dòng)不大時(shí),保持兼容性(向下兼容性的一個(gè)特例):

  有時(shí)候你的類增加了一些無關(guān)緊要的非私有方法,而邏輯字段并不改變的時(shí)候,你當(dāng)然希望老版本和新版本保持兼容性,方法同樣是通過顯式的聲名UID來實(shí)現(xiàn)。下面我們驗(yà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(){}//無關(guān)緊要的方法
  }

  首先將老版本序列化,然后用新版本讀出,發(fā)生錯(cuò)誤:

  java.io.InvalidClassException: Serial.Serial1; local class incompatible: stream classdesc serialVersionUID = 762508508425139227, local class serialVersionUID = 1187169935661445676

  接下來我們加入顯式的聲名UID:

  private static final long serialVersionUID=762508508425139227l;


  再次運(yùn)行,順利地產(chǎn)生新對(duì)象

  DATA: 1001 com1

  如何保持向上兼容性:

  向上兼容性是指老的版本能夠讀取新的版本序列化的數(shù)據(jù)流。常常出現(xiàn)在我們的服務(wù)器的數(shù)據(jù)更新了,仍然希望老的客戶端能夠支持反序列化新的數(shù)據(jù)流,直到其更新到新的版本??梢哉f,這是半自動(dòng)的事情。

  跟一般的講,因?yàn)樵趈ava中serialVersionUID是唯一控制著能否反序列化成功的標(biāo)志,只要這個(gè)值不一樣,就無法反序列化成功。但只要這個(gè)值相同,無論如何都將反序列化,在這個(gè)過程中,對(duì)于向上兼容性,新數(shù)據(jù)流中的多余的內(nèi)容將會(huì)被忽略;對(duì)于向下兼容性而言,舊的數(shù)據(jù)流中所包含的所有內(nèi)容都將會(huì)被恢復(fù),新版本的類中沒有涉及到的部分將保持默認(rèn)值。利用這一特性,可以說,只要我們認(rèn)為的保持serialVersionUID不變,向上兼容性是自動(dòng)實(shí)現(xiàn)的。

  當(dāng)然,一但我們將新版本中的老的內(nèi)容拿掉,情況就不同了,即使UID保持不變,會(huì)引發(fā)異常。正是因?yàn)檫@一點(diǎn),我們要牢記一個(gè)類一旦實(shí)現(xiàn)了序列化又要保持向上下兼容性,就不可以隨隨便便的修改了?。。?

  測(cè)試也證明了這一點(diǎn),有興趣的讀者可以自己試一試。
   如何保持向下兼容性:

  一如上文所指出的,你會(huì)想當(dāng)然的認(rèn)為只要保持serialVersionUID不變,向下兼容性是自動(dòng)實(shí)現(xiàn)的。但實(shí)際上,向下兼容要復(fù)雜一些。這是因?yàn)?,我們必須要?duì)那些沒有初始化的字段負(fù)責(zé)。要保證它們能被使用。

  所以必須要利用

  private void readObject(java.io.ObjectInputStream in)
  throws IOException, ClassNotFoundException{
  in.defaultReadObject();//先反序列化對(duì)象
  if(ver=5552){
  //以前的版本5552
  …初始化其他字段
  }else if(ver=5550){
  //以前的版本5550
  …初始化其他字段
  }else{
  //太老的版本不支持
  throw new InvalidClassException();
  }
  }

  細(xì)心的讀者會(huì)注意到要保證in.defaultReadObject();能夠順利執(zhí)行,就必須要求serialVersionUID保持一致,所以這里的ver不能夠利用serialVersionUID了。這里的ver是一個(gè)我們預(yù)先安插好的final long ver=xxxx;并且它不能夠被transient修飾。所以保持向下的兼容性至少有三點(diǎn)要求:

  1.serialVersionUID保持一致

  2.預(yù)先安插好我們自己的版本識(shí)別標(biāo)志的final long ver=xxxx;

  3.保證初始化所有的域

  討論一下兼容性策略:

  到這里我們可以看到要保持向下的兼容性很麻煩。而且隨著版本數(shù)目的增加。維護(hù)會(huì)變得困難而繁瑣。討論什么樣的程序應(yīng)該使用怎么樣的兼容性序列化策略已經(jīng)超出本文的范疇,但是對(duì)于一個(gè)游戲的存盤功能,和對(duì)于一個(gè)字處理軟件的文檔的兼容性的要求肯定不同。對(duì)于rpg游戲的存盤功能,一般要求能夠保持向下兼容,這里如果使用java序列化的方法,則可根據(jù)以上分析的三點(diǎn)進(jìn)行準(zhǔn)備。對(duì)于這樣的情況使用對(duì)象序列化方法還是可以應(yīng)付的。對(duì)于一個(gè)字處理軟件的文檔的兼容性要求頗高,一般情況下的策略都是要求良好的向下兼容性,和盡可能的向上兼容性。則一般不會(huì)使用對(duì)象序列化技術(shù),一個(gè)精心設(shè)計(jì)的文檔結(jié)構(gòu),更能解決問題。

  數(shù)據(jù)一致性問題、約束問題

  要知道序列化是另一種形式上的“public構(gòu)造函數(shù)”,但他僅僅構(gòu)造起對(duì)象,而不作任何的檢查,這樣人很不舒服,所以必要的檢查是必須的,這利用了readObject()

  private void readObject(java.io.ObjectInputStream in)
  throws IOException, ClassNotFoundException{
  in.defaultReadObject();//先反序列化對(duì)象
  …進(jìn)行檢查與初始化
  }

  出于結(jié)構(gòu)化的考慮,通常使用一個(gè)名為initialize的函數(shù),負(fù)責(zé)檢查與初始化,如果失敗拋出異常。要保持檢查與初始化是很容易被忘記的,這常常導(dǎo)致問題。另一個(gè)問題在于當(dāng)父類沒有加入readObject()的時(shí)候,子類很容易忘記要調(diào)用對(duì)應(yīng)的initialize函數(shù)。這仿佛回到了當(dāng)初為什么要引入構(gòu)造函數(shù)的問題,原因就是防止子類忘記調(diào)用初始化函數(shù)引發(fā)各種問題。所以,如果要保持?jǐn)?shù)據(jù)一致性,一定要加入readObject()。

  安全問題

  安全性的話題超出了本文的范疇,但是你應(yīng)該要知道,有可能一個(gè)攻擊者會(huì)對(duì)你的類準(zhǔn)備一個(gè)惡意的數(shù)據(jù)流企圖生成一個(gè)錯(cuò)誤的類。當(dāng)你需要確保你的對(duì)象數(shù)據(jù)安全的話,你一般可以利用上面的方法來檢查,并初始化,但對(duì)于某些引用不好檢查。解決方法就是對(duì)重要的部件進(jìn)行保護(hù)性拷貝。這里推薦一個(gè)好方法,它不用保護(hù)性拷貝個(gè)別的域,而是直接保護(hù)性拷貝整個(gè)對(duì)象。這就是:

  Object readResolve() throws ObjectStreamException;

  這個(gè)方法的用途就是,他會(huì)緊接著readObject()調(diào)用。它將會(huì)利用返回的對(duì)象代替原來反序列化的對(duì)象。也就是原來readObject()反序列化的對(duì)象將會(huì)被立即的丟棄。

  Object readResolve() throws ObjectStreamException{
  return new Serial2(this.xxx1,this.xxx2);// xxx1、xxx2是剛剛反序列化得來的,這是一種保護(hù)性拷貝
  }

  這樣的話雖然在時(shí)間上有所浪費(fèi),但是對(duì)于特別的重要而安全的類,可以使用這種方法。如果數(shù)據(jù)一致性問題、約束問題通過逐一檢查來解決很麻煩,也可以利用這種方法,但要考慮好成本,和注意下面的局限性。 利用readResolve()有一個(gè)明顯的缺點(diǎn),就是當(dāng)父類實(shí)現(xiàn)了readResolve(),子類將變得無叢下手。如果一個(gè)保護(hù)的或者是公有的父類的readResolve()存在,并且子類也沒有改寫它,將會(huì)使得子類反序列化的時(shí)候最終得到一個(gè)父類的對(duì)象,這既不是我們要得結(jié)果,也不容易發(fā)現(xiàn)這種錯(cuò)誤。而讓子類重寫readResolve()無疑是一個(gè)負(fù)擔(dān)。也就是說對(duì)于要繼承的類而言,實(shí)現(xiàn)readResolve()來保護(hù)類不是一個(gè)好方法。我們只能利用第一種方法寫一個(gè)保護(hù)性的readObject()。

  所以我的建議是:一般情況下,只有對(duì)于final的類采用readResolve()來進(jìn)行保護(hù)。

標(biāo)簽:萍鄉(xiāng) 衡水 衢州 大理 蚌埠 江蘇 棗莊 廣元

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《J2SE中的序默認(rèn)序列化》,本文關(guān)鍵詞  ;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 收縮
    • 微信客服
    • 微信二維碼
    • 電話咨詢

    • 400-1100-266