Java序列化(Serializable)與反序列化

##序列化是幹什麼的## 簡單說就是爲了保存在內存中的各類對象的狀態（也就是實例變量，不是方法），而且能夠把保存的對象狀態再讀出來。雖然你能夠用你本身的各類各樣的方法來保 存object states，可是Java給你提供一種應該比你本身好的保存對象狀態的機制，那就是序列化。 ##什麼狀況下須要序列化##

1. 當你想把的內存中的對象狀態保存到一個文件中或者數據庫中時候；
2. 當你想用套接字在網絡上傳送對象的時候；
3. 當你想經過RMI傳輸對象的時候；

##序列化的幾種方式## 在Java中socket傳輸數據時，數據類型每每比較難選擇。可能要考慮帶寬、跨語言、版本的兼容等問題。比較常見的作法有兩種：一是把對象包裝成JSON字符串傳輸，二是採用java對象的序列化和反序列化。隨着Google工具protoBuf的開源，protobuf也是個不錯的選擇。對JSON,Object Serialize,ProtoBuf 作個對比。 ###Object Serialize### public interface Serializable類經過實現 java.io.Serializable 接口以啓用其序列化功能。未實現此接口的類將沒法使其任何狀態序列化或反序列化。可序列化類的全部子類型自己都是可序列化的。序列化接口沒有方法或字段，僅用於標識可序列化的語義。

要容許不可序列化類的子類型序列化，能夠假定該子類型負責保存和還原超類型的公用 (public)、受保護的 (protected) 和（若是可訪問）包 (package) 字段的狀態。僅在子類型擴展的類（父類）有一個可訪問的無參數構造方法來初始化該類的狀態時，才能夠假定子類型有此責任。若是不是這種狀況，則聲明一個類爲可序列化類是錯誤的。該錯誤將在運行時檢測到。

在反序列化過程當中，將使用該類的公用或受保護的無參數構造方法初始化不可序列化類的字段。可序列化的子類必須可以訪問無參數的構造方法。可序列化子類的字段將從該流中還原。

Java的序列化機制是經過在運行時判斷類的serialVersionUID來驗證版本一致性的。在進行反序列化時，JVM會把傳來的字節流中的serialVersionUID與本地相應實體（類）的serialVersionUID進行比較，若是相同就認爲是一致的，能夠進行反序列化，不然就會出現序列化版本不一致的異常。

serialVersionUID 用來代表類的不一樣版本間的兼容性。有兩種生成方式：

1. 一個是默認的1L，好比：private static final long serialVersionUID = 1L;
2. 一個是根據類名、接口名、成員方法及屬性等來生成一個64位的哈希字段，好比： private static final long serialVersionUID = xxxxL;

下面來討論Java類中爲何須要重載 serialVersionUID 屬性？ 當兩個進程在進行遠程通訊時，彼此能夠發送各類類型的數據。不管是何種類型的數據，都會以二進制序列的形式在網絡上傳送。發送方須要把這個Java對象轉換爲字節序列，才能在網絡上傳送；接收方則須要把字節序列再恢復爲Java對象。

1. 把Java對象轉換爲字節序列的過程稱爲對象的序列化。
2. 把字節序列恢復爲Java對象的過程稱爲對象的反序列化。

對象的序列化主要有兩種用途：（１）把對象的字節序列永久地保存到硬盤上，一般存放在一個文件中； （２）在網絡上傳送對象的字節序列；

java.io.ObjectOutputStream表明對象輸出流，它的writeObject(Object obj)方法可對參數指定的obj對象進行序列化，把獲得的字節序列寫到一個目標輸出流中。 java.io.ObjectInputStream表明對象輸入流，它的readObject()方法從一個源輸入流中讀取字節序列，再把它們反序列化爲一個對象，並將其返回。

只有實現了Serializable和Externalizable接口的類的對象才能被序列化。Externalizable接口繼承自Serializable接口，實現Externalizable接口的類徹底由自身來控制序列化的行爲，而僅實現Serializable接口的類能夠採用默認的序列化方式 。

凡是實現Serializable接口的類都有一個表示序列化版本標識符的靜態變量：private static final long serialVersionUID;

序列化運行時使用一個稱爲 serialVersionUID 的版本號與每一個可序列化類相關聯，該序列號在反序列化過程當中用於驗證序列化對象的發送者和接收者是否爲該對象加載了與序列化兼容的類。若是接收者加載的該對象的類的 serialVersionUID 與對應的發送者的類的版本號不一樣，則反序列化將會致使 InvalidClassException。可序列化類能夠經過聲明名爲serialVersionUID的字段（該字段必須是靜態 (static)、最終 (final) 的 long 型字段）顯式聲明其本身的 serialVersionUID：

ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;

若是可序列化類未顯式聲明 serialVersionUID，則序列化運行時將基於該類的各個方面計算該類的默認 serialVersionUID 值，如「Java(TM) 對象序列化規範」中所述。不過，強烈建議 全部可序列化類都顯式聲明 serialVersionUID 值，緣由是計算默認的 serialVersionUID 對類的詳細信息具備較高的敏感性，根據編譯器實現的不一樣可能千差萬別，這樣在反序列化過程當中可能會致使意外的 InvalidClassException。所以，爲保證 serialVersionUID 值跨不一樣 java 編譯器實現的一致性，序列化類必須聲明一個明確的 serialVersionUID 值。還強烈建議使用 private 修飾符顯示聲明 serialVersionUID（若是可能），緣由是這種聲明僅應用於直接聲明類 -- serialVersionUID 字段做爲繼承成員沒有用處。數組類不能聲明一個明確的 serialVersionUID，所以它們老是具備默認的計算值，可是數組類沒有匹配 serialVersionUID 值的要求。

類的serialVersionUID的默認值徹底依賴於Java編譯器的實現，對於同一個類，用不一樣的Java編譯器編譯，有可能會致使不一樣的serialVersionUID，也有可能相同。爲了提升serialVersionUID的獨立性和肯定性，強烈建議在一個可序列化類中顯示的定義serialVersionUID，爲它賦予明確的值。顯式地定義serialVersionUID有兩種用途：

1. 在某些場合，但願類的不一樣版本對序列化兼容，所以須要確保類的不一樣版本具備相同的serialVersionUID；在某些場合，不但願類的不一樣版本對序列化兼容，所以須要確保類的不一樣版本具備不一樣的serialVersionUID。
2. 當你序列化了一個類實例後，但願更改一個字段或添加一個字段，不設置serialVersionUID，所作的任何更改都將致使沒法反序化舊有實例，並在反序列化時拋出一個異常。若是你添加了serialVersionUID，在反序列舊有實例時，新添加或更改的字段值將設爲初始化值（對象爲null，基本類型爲相應的初始默認值），字段被刪除將不設置。

相關注意事項： a）序列化時，只對對象的狀態進行保存，而無論對象的方法； b）當一個父類實現序列化，子類自動實現序列化，不須要顯式實現Serializable接口； c）當一個對象的實例變量引用其餘對象，序列化該對象時也把引用對象進行序列化；

詳細描述： 序列化的過程就是對象寫入字節流和從字節流中讀取對象。將對象狀態轉換成字節流以後，能夠用java.io包中的各類字節流類將其保存到文件中，管道到另外一 線程中或經過網絡鏈接將對象數據發送到另外一主機。對象序列化功能很是簡單、強大，在RMI、Socket、JMS、EJB都有應用。對象序列化問題在網絡 編程中並非最激動人心的課題，但卻至關重要，具備許多實用意義。

1. 對象序列化能夠實現分佈式對象。主要應用例如：RMI要利用對象序列化運行遠程主機上的服務，就像在本地機上運行對象時同樣。
2. java 對象序列化不只保留一個對象的數據，並且遞歸保存對象引用的每一個對象的數據。能夠將整個對象層次寫入字節流中，能夠保存在文件中或在網絡鏈接上傳遞。利用 對象序列化能夠進行對象的「深複製」，即複製對象自己及引用的對象自己。序列化一個對象可能獲得整個對象序列。

從上面的敘述中，咱們知道了對象序列化是java編程中的必備武器，那麼讓咱們從基礎開始，好好學習一下它的機制和用法。

java序列化比較簡單，一般不須要編寫保存和恢復對象狀態的定製代碼。實現java.io.Serializable接口的類對象能夠轉換成字節流或從 字節流恢復，不須要在類中增長任何代碼。只有極少數狀況下才須要定製代碼保存或恢復對象狀態。這裏要注意：不是每一個類均可序列化，有些類是不能序列化的， 例如涉及線程的類與特定JVM有很是複雜的關係。

序列化機制： 序列化分爲兩大部分：序列化和反序列化。序列化是這個過程的第一部分，將數據分解成字節流，以便存儲在文件中或在網絡上傳輸。反序列化就是打開字節流並重構對象。對象序列化不只要將基本數據類型轉換成字節 表示，有時還要恢復數據。恢復數據要求有恢復數據的對象實例。ObjectOutputStream中的序列化過程與字節流鏈接，包括對象類型和版本信 息。反序列化時，JVM用頭信息生成對象實例，而後將對象字節流中的數據複製到對象數據成員中。

處理對象流：序列化過程和反序列化過程 java.io包有兩個序列化對象的類。ObjectOutputStream負責將對象寫入字節流，ObjectInputStream從字節流重構對象。

咱們先了解ObjectOutputStream類吧。ObjectOutputStream類擴展DataOutput接口。writeObject() 方法是最重要的方法，用於對象序列化。若是對象包含其餘對象的引用，則writeObject()方法遞歸序列化這些對象。每一個 ObjectOutputStream維護序列化的對象引用表，防止發送同一對象的多個拷貝。（這點很重要）因爲writeObject()能夠序列化整 組交叉引用的對象，所以同一ObjectOutputStream實例可能不當心被請求序列化同一對象。這時，進行反引用序列化，而不是再次寫入對象字節流。

// 序列化 today’s date 到一個文件中.
FileOutputStream f = new FileOutputStream(「tmp」); //建立一個包含恢復對象(即對象進行反序列化信息)的」tmp」數據文件
ObjectOutputStream s = new ObjectOutputStream(f);
s.writeObject(「Today」); //寫入字符串對象;
s.writeObject(new Date()); //寫入瞬態對象;
s.flush();

如今，讓咱們來了解ObjectInputStream這個類。它與ObjectOutputStream類似。它擴展DataInput接口。 ObjectInputStream中的方法鏡像DataInputStream中讀取Java基本數據類型的公開方法。readObject()方法從 字節流中反序列化對象。每次調用readObject()方法都返回流中下一個Object。對象字節流並不傳輸類的字節碼，而是包括類名及其簽名。 readObject()收到對象時，JVM裝入頭中指定的類。若是找不到這個類，則readObject()拋出 ClassNotFoundException,若是須要傳輸對象數據和字節碼，則能夠用RMI框架。ObjectInputStream的其他方法用於定製反序列化過程。

//從文件中反序列化 string 對象和 date 對象
FileInputStream in = new FileInputStream(「tmp」);
ObjectInputStream s = new ObjectInputStream(in);
String today = (String)s.readObject(); //恢復對象;
Date date = (Date)s.readObject();

定製序列化過程： 序列化一般能夠自動完成，但有時可能要對這個過程進行控制。java能夠將類聲明爲serializable，但仍可手工控制聲明爲static或transient的數據成員。

public class SimpleSerializableClass implements Serializable{
    String sToday=」Today:」;
    transient Date dtToday=new Date();
}

序列化時，類的全部數據成員應可序列化除了聲明爲transient或static的成員。將變量聲明爲transient告訴JVM咱們會負責將變元序列 化。將數據成員聲明爲transient後，序列化過程就沒法將其加進對象字節流中，沒有從transient數據成員發送的數據。後面數據反序列化時， 要重建數據成員（由於它是類定義的一部分），但不包含任何數據，由於這個數據成員不向流中寫入任何數據。記住，對象流不序列化static或 transient。咱們的類要用writeObject()與readObject()方法以處理這些數據成員。使用writeObject()與 readObject()方法時，還要注意按寫入的順序讀取這些數據成員。

//重寫writeObject()方法以便處理transient的成員。
public void writeObject(ObjectOutputStream outputStream) throws IOException{
    outputStream.defaultWriteObject();//使定製的writeObject()方法能夠利用自動序列化中內置的邏輯。
    outputStream.writeObject(oSocket.getInetAddress());
    outputStream.writeInt(oSocket.getPort());
}

//重寫readObject()方法以便接收transient的成員。
private void readObject(ObjectInputStream inputStream) throws IOException,ClassNotFoundException{
    inputStream.defaultReadObject();//defaultReadObject()補充自動序列化
    InetAddress oAddress=(InetAddress)inputStream.readObject();
    int iPort =inputStream.readInt();
    oSocket = new Socket(oAddress,iPort);
    iID=getID();
    dtToday =new Date();
}

徹底定製序列化過程： 若是一個類要徹底負責本身的序列化，則實現Externalizable接口而不是Serializable接口。Externalizable接口定義包 括兩個方法writeExternal()與readExternal()。利用這些方法能夠控制對象數據成員如何寫入字節流.類實現 Externalizable時，頭寫入對象流中，而後類徹底負責序列化和恢復數據成員，除了頭之外，根本沒有自動序列化。這裏要注意了。聲明類實現 Externalizable接口會有重大的安全風險。writeExternal()與readExternal()方法聲明爲public，惡意類可 以用這些方法讀取和寫入對象數據。若是對象包含敏感信息，則要格外當心。這包括使用安全套接或加密整個字節流。到此爲至，咱們學習了序列化的基礎部分知識。

如下來源於J2EE API： 對象的默認序列化機制寫入的內容是：對象的類，類簽名，以及非瞬態和非靜態字段的值。其餘對象的引用（瞬態和靜態字段除外）也會致使寫入那些對象。可以使用引用共享機制對單個對象的多個引用進行編碼，這樣便可將對象的圖形還原爲最初寫入它們時的形狀。

例如，要寫入可經過 ObjectInputStream 中的示例讀取的對象，請執行如下操做：

FileOutputStream fos = new FileOutputStream(「t.tmp」);
ObjectOutputStream oos = new ObjectOutputStream(fos);

oos.writeInt(12345);
oos.writeObject(「Today」);
oos.writeObject(new Date());

oos.close();

在序列化和反序列化過程當中須要特殊處理的類必須實現具備下列準確簽名的特殊方法：

private void writeObject(java.io.ObjectOutputStream stream) throws IOException;

writeObject 方法負責寫入特定類的對象狀態，以便相應的 readObject 方法能夠還原它。該方法自己沒必要與屬於對象的超類或子類的狀態有關。狀態是經過使用 writeObject 方法或使用 DataOutput 支持的用於基本數據類型的方法將各個字段寫入 ObjectOutputStream 來保存的。

private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException;

readObject 方法負責從流中讀取並還原類字段。它能夠調用 in.defaultReadObject 來調用默認機制，以還原對象的非靜態和非瞬態字段。defaultReadObject 方法使用流中的信息來分配流中經過當前對象中相應命名字段保存的對象的字段。這用於處理類發展後須要添加新字段的情形。

序列化操做不寫出沒有實現 java.io.Serializable 接口的任何對象的字段。不可序列化的 Object 的子類能夠是可序列化的。在此狀況下，不可序列化的類必須有一個無參數構造方法，以便容許初始化其字段。在此狀況下，子類負責保存和還原不可序列化的類的 狀態。常常出現的狀況是，該類的字段是可訪問的（public、package 或 protected），或者存在可用來還原狀態的 get 和 set 方法。

實現 writeObject 和 readObject 方法能夠阻止對象的序列化，這時拋出 NotSerializableException。ObjectOutputStream 致使發生異常並停止序列化進程。

實現 Externalizable 接口容許對象假定能夠徹底控制對象的序列化形式的內容和格式。調用 Externalizable 接口的方法（writeExternal 和 readExternal）來保存和恢復對象的狀態。經過類實現時，它們可使用 ObjectOutput 和 ObjectInput 的全部方法讀寫它們本身的狀態。對象負責處理出現的任何版本控制。

Enum 常量的序列化不一樣於普通的 serializable 或 externalizable 對象。enum 常量的序列化形式只包含其名稱；常量的字段值不被傳送。爲了序列化 enum 常量，ObjectOutputStream 須要寫入由常量的名稱方法返回的字符串。與其餘 serializable 或 externalizable 對象同樣，enum 常量能夠做爲序列化流中後續出現的 back 引用的目標。用於序列化 enum 常量的進程不可定製；在序列化期間，由 enum 類型定義的全部類特定的 writeObject 和 writeReplace 方法都將被忽略。相似地，任何 serialPersistentFields 或 serialVersionUID 字段聲明也將被忽略，全部 enum 類型都有一個 0L 的固定的 serialVersionUID。

基本數據（不包括 serializable 字段和 externalizable 數據）以塊數據記錄的形式寫入 ObjectOutputStream 中。塊數據記錄由頭部和數據組成。塊數據部分包括標記和跟在部分後面的字節數。連續的基本寫入數據被合併在一個塊數據記錄中。塊數據記錄的分塊因子爲 1024 字節。每一個塊數據記錄都將填滿 1024 字節，或者在終止塊數據模式時被寫入。調用 ObjectOutputStream 方法 writeObject、defaultWriteObject 和 writeFields 最初只是終止全部現有塊數據記錄。

將對象寫入流時須要指定要使用的替代對象的可序列化類，應使用準確的簽名來實現此特殊方法：

ANY-ACCESS-MODIFIER Object writeReplace() throws ObjectStreamException;

此 writeReplace 方法將由序列化調用，前提是若是此方法存在，並且它能夠經過被序列化對象的類中定義的一個方法訪問。所以，該方法能夠擁有私有 (private)、受保護的 (protected) 和包私有 (package-private) 訪問。子類對此方法的訪問遵循 java 訪問規則。

在從流中讀取類的一個實例時須要指定替代的類應使用的準確簽名來實現此特殊方法。

ANY-ACCESS-MODIFIER Object readResolve() throws ObjectStreamException;

此 readResolve 方法遵循與 writeReplace 相同的調用規則和訪問規則。

序列化類的全部子類自己都是可序列化的。這個序列化接口沒有任何方法和域，僅用於標識序列化的語意。容許非序列化類的子類型序列化，子類型能夠假定負責保存和恢復父類型的公有的、保護的和(若是可訪問)包的域的狀態。只要該類(即父類)有一個無參構造子，可初始化它的狀態，那麼子類型就可承擔上述職責；若是該類沒有無參構造函數，在這種狀況下申明一個可序列化的類是一個錯誤。此錯誤將在運行時被檢測。 ###JSON化###

UserVo src = new UserVo();
src.setName("Yaoming");
src.setAge(30);
src.setPhone(13789878978L);
	
UserVo f1 = new UserVo();
f1.setName("tmac");
f1.setAge(32);
f1.setPhone(138999898989L);
UserVo f2 = new UserVo();
f2.setName("liuwei");
f2.setAge(29);
f2.setPhone(138999899989L);
		
List<UserVo> friends = new ArrayList<UserVo>();
friends.add(f1);
friends.add(f2);
src.setFriends(friends);

// 採用Google的gson-2.2.2.jar 進行轉義：
Gson gson = new Gson();
String json = gson.toJson(src);

獲得的字符串：（字節數爲153）

{"name":"Yaoming","age":30,"phone":13789878978,"friends":[{"name":"tmac","age":32,"phone":138999898989},{"name":"liuwei","age":29,"phone":138999899989}]}

Json的優勢：明文結構一目瞭然，能夠跨語言，屬性的增長減小對解析端影響較小。缺點：字節數過多，依賴於不一樣的第三方類庫。 ###Google ProtoBuf### protocol buffers 是google內部得一種傳輸協議，目前項目已經開源（http://code.google.com/p/protobuf/）。它定義了一種緊湊得可擴展得二進制協議格式，適合網絡傳輸，而且針對多個語言有不一樣得版本可供選擇。

以protobuf-2.5.0rc1爲例，準備工做：

下載源碼，解壓，編譯，安裝：

tar zxvf protobuf-2.5.0rc1.tar.gz
./configure
./make
./make install

測試：

MacBook-Air:~ ming$ protoc --version
libprotoc 2.5.0

安裝成功！進入源碼得java目錄，用mvn工具編譯生成所需得jar包，protobuf-java-2.5.0rc1.jar

（1）編寫.proto文件，命名UserVo.proto：

package serialize;

option java_package = "serialize";
option java_outer_classname="UserVoProtos";

message UserVo{
	optional string name = 1;
	optional int32 age = 2;
	optional int64 phone = 3;
	repeated serialize.UserVo friends = 4;
}

（2）在命令行利用protoc 工具生成builder類：

protoc -IPATH=.proto文件所在得目錄 --java_out=java文件的輸出路徑  .proto的名稱

（3）編寫序列化代碼：

UserVoProtos.UserVo.Builder builder = UserVoProtos.UserVo.newBuilder();
builder.setName("Yaoming");
builder.setAge(30);
builder.setPhone(13789878978L);
		
UserVoProtos.UserVo.Builder builder1 = UserVoProtos.UserVo.newBuilder();
builder1.setName("tmac");
builder1.setAge(32);
builder1.setPhone(138999898989L);
		
UserVoProtos.UserVo.Builder builder2 = UserVoProtos.UserVo.newBuilder();
builder2.setName("liuwei");
builder2.setAge(29);
builder2.setPhone(138999899989L);
		
builder.addFriends(builder1);
builder.addFriends(builder2);
		
UserVoProtos.UserVo vo = builder.build();
		
byte[] v = vo.toByteArray();

字節數爲53

（4）反序列化：

UserVoProtos.UserVo uvo = UserVoProtos.UserVo.parseFrom(dstb);
System.out.println(uvo.getFriends(0).getName());

google protobuf 優勢：字節數很小，適合網絡傳輸節省io，跨語言 。缺點：須要依賴於工具生成代碼。

工做機制 proto文件是對數據的一個描述，包括字段名稱，類型，字節中的位置。protoc工具讀取proto文件生成對應builder代碼的類庫。protoc xxxxx --java_out=xxxxxx 生成java類庫。builder類根據本身的算法把數據序列化成字節流，或者把字節流根據反射的原理反序列化成對象。

官方的示例：https://developers.google.com/protocol-buffers/docs/javatutorial。

proto文件中的字段類型和java中的對應關係：

protobuf 在序列化和反序列化的時候，是依賴於.proto文件生成的builder類完成，字段的變化若是不表如今.proto文件中就不會影響反序列化，比較適合字段變化的狀況。作個測試：

把UserVo序列化到文件中：

UserVoProtos.UserVo vo = builder.build();
byte[] v = vo.toByteArray();
FileOutputStream fos = new FileOutputStream(dataFile);
fos.write(vo.toByteArray());
fos.close();

爲UserVo增長字段，對應的.proto文件：

package serialize;

option java_package = "serialize";
option java_outer_classname="UserVoProtos";

message UserVo{
	optional string name = 1;
	optional int32 age = 2;
	optional int64 phone = 3;
	repeated serialize.UserVo friends = 4;
	optional string address = 5;
}

從文件中反序列化回來：

FileInputStream fis = new FileInputStream(dataFile);
byte[] dstb = new byte[fis.available()];
for(int i=0;i<dstb.length;i++){
	dstb[i] = (byte)fis.read();
}
fis.close();
UserVoProtos.UserVo uvo = UserVoProtos.UserVo.parseFrom(dstb);
System.out.println(uvo.getFriends(0).getName());

三種方式對比傳輸一樣的數據，google protobuf只有53個字節是最少的。結論：