為什么阿里巴巴要求程序員謹慎修改serialVersionUID 字段的值
序列化是一種對象持久化的手段。普遍應(yīng)用在網(wǎng)絡(luò)傳輸、RMI等場景中。類通過實現(xiàn)java.io.Serializable 接口以啟用其序列化功能。
在我的博客中，其實已經(jīng)有多篇文章介紹過序列化了，對序列化的基礎(chǔ)知識不夠了解的朋友可以參考以下幾篇文章：
在這幾篇文章中，我分別介紹過了序列化涉及到的類和接口、如何自定義序列化策略、transient關(guān)鍵字和序列化的關(guān)系等，還通過學(xué)習(xí)ArrayList對序列化的實現(xiàn)源碼深入學(xué)習(xí)了序列化。并且還拓展分析了一下序列化對單例的影響等。
但是，還有一個知識點并未展開介紹，那就是關(guān)于serialVersionUID 。這個字段到底有什么用?如果不設(shè)置會怎么樣?為什么《阿里巴巴Java開發(fā)手冊》中有以下規(guī)定：
背景知識
在展開本文的介紹之前，先來簡單介紹一些和序列化有關(guān)的知識，內(nèi)容均來自文章開頭的三個文章鏈接中。
Serializable 和 Externalizable
Java類通過實現(xiàn) java.io.Serializable 接口以啟用其序列化功能。未實現(xiàn)此接口的類將無法進行序列化或反序列化?？尚蛄谢惖乃凶宇愋捅旧矶际强尚蛄谢?。
如果讀者看過Serializable的源碼，就會發(fā)現(xiàn)，他只是一個空的接口，里面什么東西都沒有。Serializable接口沒有方法或字段，僅用于標識可序列化的語義。但是，如果一個類沒有實現(xiàn)這個接口，想要被序列化的話，就會拋出java.io.NotSerializableException異常。
它是怎么保證只有實現(xiàn)了該接口的方法才能進行序列化與反序列化的呢?
原因是在執(zhí)行序列化的過程中，會執(zhí)行到以下代碼：
- if (obj instanceof String) {
- writeString((String) obj, unshared);
- } else if (cl.isArray()) {
- writeArray(obj, desc, unshared);
- } else if (obj instanceof Enum) {
- writeEnum((Enum<?>) obj, desc, unshared);
- } else if (obj instanceof Serializable) {
- writeOrdinaryObject(obj, desc, unshared);
- } else {
- if (extendedDebugInfo) {
- throw new NotSerializableException(
- cl.getName() + "\n" + debugInfoStack.toString());
- } else {
- throw new NotSerializableException(cl.getName());
- }
- }
在進行序列化操作時，會判斷要被序列化的類是否是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ù)男问?如二進制流)，比如保存在文件中。這樣，當(dāng)再次需要這個對象的時候，從文件中讀取出二進制流，再從二進制流中反序列化出對象。
虛擬機是否允許反序列化，不僅取決于類路徑和功能代碼是否一致，一個非常重要的一點是兩個類的序列化 ID 是否一致，這個所謂的序列化ID，就是我們在代碼中定義的serialVersionUID。
如果serialVersionUID變了會怎樣
我們舉個例子吧，看看如果serialVersionUID被修改了會發(fā)生什么?
- public class SerializableDemo1 {
- public static void main(String[] args) {
- //Initializes The Object
- User1 user = new User1();
- user.setName("hollis");
- //Write Obj to File
- ObjectOutputStream oos = null;
- try {
- oos = new ObjectOutputStream(new FileOutputStream("tempFile"));
- oos.writeObject(user);
- } catch (IOException e) {
- e.printStackTrace();
- } finally {
- IOUtils.closeQuietly(oos);
- }
- }
- }
- class User1 implements Serializable {
- private static final long serialVersionUID = 1L;
- private String name;
- public String getName() {
- return name;
- }
- public void setName(String name) {
- this.name = name;
- }
- }
我們先執(zhí)行以上代碼，把一個User1對象寫入到文件中。然后我們修改一下User1類，把serialVersionUID的值改為2L。
- class User1 implements Serializable {
- private static final long serialVersionUID = 2L;
- private String name;
- public String getName() {
- return name;
- }
- public void setName(String name) {
- this.name = name;
- }
- }
然后執(zhí)行以下代碼，把文件中的對象反序列化出來：
- public class SerializableDemo2 {
- public static void main(String[] args) {
- //Read Obj from File
- File file = new File("tempFile");
- ObjectInputStream ois = null;
- try {
- ois = new ObjectInputStream(new FileInputStream(file));
- User1 newUser = (User1) ois.readObject();
- System.out.println(newUser);
- } catch (IOException e) {
- e.printStackTrace();
- } catch (ClassNotFoundException e) {
- e.printStackTrace();
- } finally {
- IOUtils.closeQuietly(ois);
- try {
- FileUtils.forceDelete(file);
- } catch (IOException e) {
- e.printStackTrace();
- }
- }
- }
- }
執(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。
這也是《阿里巴巴Java開發(fā)手冊》中規(guī)定，在兼容性升級中，在修改類的時候，不要修改serialVersionUID的原因。除非是完全不兼容的兩個版本。所以，serialVersionUID其實是驗證版本一致性的。
如果讀者感興趣，可以把各個版本的JDK代碼都拿出來看一下，那些向下兼容的類的serialVersionUID是沒有變化過的。比如String類的serialVersionUID一直都是-6849794470754667710L。
但是，作者認為，這個規(guī)范其實還可以再嚴格一些，那就是規(guī)定：
如果一個類實現(xiàn)了Serializable接口，就必須手動添加一個private static final long serialVersionUID變量，并且設(shè)置初始值。
為什么要明確定一個serialVersionUID
如果我們沒有在類中明確的定義一個serialVersionUID的話，看看會發(fā)生什么。
嘗試修改上面的demo代碼，先使用以下類定義一個對象，該類中不定義serialVersionUID，將其寫入文件。
- class User1 implements Serializable {
- private String name;
- public String getName() {
- return name;
- }
- public void setName(String name) {
- this.name = name;
- }
- }
然后我們修改User1類，向其中增加一個屬性。在嘗試將其從文件中讀取出來，并進行反序列化。
- class User1 implements Serializable {
- private String name;
- private int age;
- public String getName() {
- return name;
- }
- public void setName(String name) {
- this.name = name;
- }
- public int getAge() {
- return age;
- }
- public void setAge(int age) {
- this.age = age;
- }
- }
執(zhí)行結(jié)果：
- java.io.InvalidClassException: com.hollis.User1; local class incompatible: stream classdesc serialVersionUID = -2986778152837257883, local class serialVersionUID = 7961728318907695402
同樣，拋出了InvalidClassException，并且指出兩個serialVersionUID不同，分別是-2986778152837257883和7961728318907695402。
從這里可以看出，系統(tǒng)自己添加了一個serialVersionUID。
所以，一旦類實現(xiàn)了Serializable，就建議明確的定義一個serialVersionUID。不然在修改類的時候，就會發(fā)生異常。
serialVersionUID有兩種顯示的生成方式：
一種是默認的1L，比如：
- private static final long serialVersionUID = 1L;
另外一種是根據(jù)類名、接口名、成員方法及屬性等來生成一個64位的哈希字段，比如：
- private static final long serialVersionUID = xxxxL;
后面這種方式，可以借助IDE生成，后面會介紹。
背后原理
知其然，要知其所以然，我們再來看看源碼，分析一下為什么serialVersionUID改變的時候會拋異常?在沒有明確定義的情況下，默認的serialVersionUID是怎么來的?
為了簡化代碼量，反序列化的調(diào)用鏈如下：
- ObjectInputStream.readObject ->
- readObject0 ->
- readOrdinaryObject ->
- readClassDesc ->
- readNonProxyDesc ->
- ObjectStreamClass.initNonProxy
在initNonProxy中 ，關(guān)鍵代碼如下：
在反序列化過程中，對serialVersionUID做了比較，如果發(fā)現(xiàn)不相等，則直接拋出異常。
深入看一下getSerialVersionUID方法：
- public long getSerialVersionUID() {
- // REMIND: synchronize instead of relying on volatile?
- if (suid == null) {
- suid = AccessController.doPrivileged(
- new PrivilegedAction<Long>() {
- public Long run() {
- return computeDefaultSUID(cl);
- }
- }
- );
- }
- return suid.longValue();
- }
在沒有定義serialVersionUID的時候，會調(diào)用computeDefaultSUID 方法，生成一個默認的serialVersionUID。
這也就找到了以上兩個問題的根源，其實是代碼中做了嚴格的校驗，并且在未定義的時候自動生成了一個serialVersionUID。
IDEA提示
為了確保我們不會忘記定義serialVersionUID，可以調(diào)節(jié)一下Intellij IDEA的配置，在實現(xiàn)Serializable接口后，如果沒定義serialVersionUID的話，IDEA(eclipse一樣)會進行提示：
并且可以一鍵生成一個：
當(dāng)然，這個配置并不是默認生效的，需要手動到IDEA中設(shè)置一下：
在圖中標號3的地方(Serializable class without serialVersionUID的配置)，打上勾，保存即可。
總結(jié)
serialVersionUID是用來驗證版本一致性的。所以在做兼容性升級的時候，不要改變類中serialVersionUID的值。
特別說明一下，由于本文標題并不完全能表達本文的全部內(nèi)容，這里再強調(diào)一下：serialVersionUID 既然是驗證版本一致性的，在做版本升級的時候(非兼容性升級)，記得要修改這個字段的值哦，這樣可以避免序列化混亂。
如果一個類實現(xiàn)了Serializable接口，一定要記得定義serialVersionUID，否則會發(fā)生異常?？梢栽贗DE中通過設(shè)置，讓他幫忙提示，并且可以一鍵快速生成一個serialVersionUID。
之所以會發(fā)生異常，是因為反序列化過程中做了校驗，并且如果沒有明確定義的話，會根據(jù)類名及屬性等自動生成一個。
【本文是51CTO專欄作者Hollis的原創(chuàng)文章，作者微信公眾號Hollis(ID：hollischuang)】
