serialVersionUID有什么用

這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)serialVersionUID有什么用，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

序列化是一種對象持久化的手段。普遍應(yīng)用在網(wǎng)絡(luò)傳輸、RMI等場景中。類通過實現(xiàn) java.io.Serializable 接口以啟用其序列化功能。

但是，還有一個知識點并未展開介紹，那就是關(guān)于serialVersionUID 。這個字段到底有什么用？如果不設(shè)置會怎么樣？

背景知識

先來簡單介紹一些和序列化有關(guān)的知識，

Serializable 和 Externalizable

Java類通過實現(xiàn) java.io.Serializable 接口以啟用其序列化功能。未實現(xiàn)此接口的類將無法進行序列化或反序列化。可序列化類的所有子類型本身都是可序列化的。

如果讀者看過Serializable的源碼，就會發(fā)現(xiàn)，他只是一個空的接口，里面什么東西都沒有。Serializable接口沒有方法或字段，僅用于標識可序列化的語義。但是，如果一個類沒有實現(xiàn)這個接口，想要被序列化的話，就會拋出java.io.NotSerializableException異常。

它是怎么保證只有實現(xiàn)了該接口的方法才能進行序列化與反序列化的呢？

原因：

在進行序列化操作時，會判斷要被序列化的類是否是Enum、Array和Serializable類型，如果都不是則直接拋出NotSerializableException。

Java中還提供了Externalizable接口，也可以實現(xiàn)它來提供序列化能力。

Externalizable繼承自Serializable，該接口中定義了兩個抽象方法：writeExternal()與readExternal()。

當(dāng)使用Externalizable接口來進行序列化與反序列化的時候需要開發(fā)人員重寫writeExternal()與readExternal()方法。否則所有變量的值都會變成默認值。

transient

transient 關(guān)鍵字的作用是控制變量的序列化，在變量聲明前加上該關(guān)鍵字，可以阻止該變量被序列化到文件中，在被反序列化后，transient 變量的值被設(shè)為初始值，如 int 型的是 0，對象型的是 null。

自定義序列化策略

在序列化過程中，如果被序列化的類中定義了writeObject 和 readObject 方法，虛擬機會試圖調(diào)用對象類里的 writeObject 和 readObject 方法，進行用戶自定義的序列化和反序列化。

如果沒有這樣的方法，則默認調(diào)用是 ObjectOutputStream 的 defaultWriteObject方法以及 ObjectInputStream 的 defaultReadObject 方法。

用戶自定義的 writeObject 和 readObject 方法可以允許用戶控制序列化的過程，比如可以在序列化的過程中動態(tài)改變序列化的數(shù)值。

所以，對于一些特殊字段需要定義序列化的策略的時候，可以考慮使用transient修飾，并自己重寫writeObject 和 readObject 方法，如java.util.ArrayList中就有這樣的實現(xiàn)。

以上，就是一些讀者需要掌握和和序列化有關(guān)的知識。

我們隨便找?guī)讉€Java中實現(xiàn)了序列化接口的類，如String、Integer等，我們可以發(fā)現(xiàn)一個細節(jié)，那就是這些類除了實現(xiàn)了Serializable外，還定義了一個serialVersionUID

那么，到底什么是serialVersionUID呢？為什么要設(shè)置這樣一個字段呢？

什么是serialVersionUID

序列化是將對象的狀態(tài)信息轉(zhuǎn)換為可存儲或傳輸?shù)男问降倪^程。我們都知道，Java對象是保存在JVM的堆內(nèi)存中的，也就是說，如果JVM堆不存在了，那么對象也就跟著消失了。

而序列化提供了一種方案，可以讓你在即使JVM停機的情況下也能把對象保存下來的方案。就像我們平時用的U盤一樣。把Java對象序列化成可存儲或傳輸?shù)男问剑ㄈ缍M制流），比如保存在文件中。這樣，當(dāng)再次需要這個對象的時候，從文件中讀取出二進制流，再從二進制流中反序列化出對象。

虛擬機是否允許反序列化，不僅取決于類路徑和功能代碼是否一致，一個非常重要的一點是兩個類的序列化 ID 是否一致，這個所謂的序列化ID，就是我們在代碼中定義的serialVersionUID。

如果serialVersionUID變了會怎樣

我們舉個例子吧，看看如果serialVersionUID被修改了會發(fā)生什么？

把一個User1對象寫入到文件中。然后我們修改一下User1類，把serialVersionUID的值改為2L。

然后執(zhí)行代碼把文件中的對象反序列化出來：

執(zhí)行結(jié)果如下：

java.io.InvalidClassException: com.hollis.User1; local class incompatible: stream classdesc serialVersionUID = 1, local class serialVersionUID = 2

可以發(fā)現(xiàn)，以上代碼拋出了一個java.io.InvalidClassException，并且指出serialVersionUID不一致。

這是因為，在進行反序列化時，JVM會把傳來的字節(jié)流中的serialVersionUID與本地相應(yīng)實體類的serialVersionUID進行比較，如果相同就認為是一致的，可以進行反序列化，否則就會出現(xiàn)序列化版本不一致的異常，即是InvalidCastException。

在兼容性升級中，在修改類的時候，不要修改serialVersionUID的原因。除非是完全不兼容的兩個版本。所以，serialVersionUID其實是驗證版本一致性的。

如果讀者感興趣，可以把各個版本的JDK代碼都拿出來看一下，那些向下兼容的類的serialVersionUID是沒有變化過的。比如String類的serialVersionUID一直都是-6849794470754667710L。

但是，小編認為，這個規(guī)范其實還可以再嚴格一些，那就是規(guī)定：

如果一個類實現(xiàn)了Serializable接口，就必須手動添加一個private static final long serialVersionUID變量，并且設(shè)置初始值。

為什么要明確定一個serialVersionUID

如果我們沒有在類中明確的定義一個serialVersionUID的話，看看會發(fā)生什么。

嘗試修改上面的demo代碼，先使用以下類定義一個對象，該類中不定義serialVersionUID，將其寫入文件。

然后我們修改User1類，向其中增加一個屬性。在嘗試將其從文件中讀取出來，并進行反序列化。

上述就是小編為大家分享的serialVersionUID有什么用了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道。