JAVA序列號中serialVersionUID的示例分析

這篇文章給大家分享的是有關JAVA序列號中serialVersionUID的示例分析的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

serialVersionUID 的規范

Serializable 和 Externalizable

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

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

序列號在寫成二進制流的時候，會調用如下的方法：

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

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

transient 不需要被序列化

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

什么是 serialVersionUID

序列化是將對象的狀態信息轉換為可存儲或傳輸的形式的過程。我們都知道，Java對象是保存在JVM的堆內存中的，也就是說，如果JVM堆不存在了，那么對象也就跟著消失了。

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

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

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

為什么必須設置默認的 serialVersionUID 值

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

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

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

執行結果：

java.io.InvalidClassException: com.hollis.User1; local class incompatible: stream classdesc serialVersionUID = -2986778152837257883, local class serialVersionUID = 7961728318907695402

同樣，拋出了InvalidClassException，并且指出兩個serialVersionUID不同，分別是-2986778152837257883和7961728318907695402。

從這里可以看出，系統自己添加了一個serialVersionUID。

所以，一旦類實現了Serializable，就建議明確的定義一個serialVersionUID。不然在修改類的時候，就會發生異常。

serialVersionUID有兩種顯示的生成方式：

一種是默認的1L，比如：

private static final long serialVersionUID = 1L;

另外一種是根據類名、接口名、成員方法及屬性等來生成一個64位的哈希字段，比如：

private static final long serialVersionUID = xxxxL;

后面這種方式，可以借助IDE生成，后面會介紹。

背后原理

為了簡化代碼量，反序列化的調用鏈如下：

在initNonProxy中 ，關鍵代碼如下：

在反序列化過程中，對serialVersionUID做了比較，如果發現不相等，則直接拋出異常。

深入看一下getSerialVersionUID方法：

在沒有定義serialVersionUID的時候，會調用computeDefaultSUID 方法，生成一個默認的serialVersionUID。

這也就找到了以上兩個問題的根源，其實是代碼中做了嚴格的校驗，并且在未定義的時候自動生成了一個serialVersionUID。

IDEA提示

為了確保我們不會忘記定義serialVersionUID，可以調節一下Intellij IDEA的配置，在實現Serializable接口后，如果沒定義serialVersionUID的話，IDEA（eclipse一樣）會進行提示：

并且可以一鍵生成一個：

當然，這個配置并不是默認生效的，需要手動到IDEA中設置一下：

在圖中標號3的地方（Serializable class without serialVersionUID的配置），打上勾，保存即可。

感謝各位的閱讀！關于“JAVA序列號中serialVersionUID的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！