寫(xiě)代碼的時(shí)候習(xí)慣性喜歡把model類(lèi)實(shí)現(xiàn)Serializable接口, 既然實(shí)現(xiàn)了Serializable接口, 那么想當(dāng)然的需要定義一個(gè)serialVersionUID, 難受就難受到serialVersionUID的值, 不好取啊, 看著就難受好么.
- 值太短? 看著好丑, 人家都是長(zhǎng)長(zhǎng)的, 我不能短.
- 亂敲一通搞的很長(zhǎng), 強(qiáng)迫癥表示很難受
So, 我就找到了一款能自動(dòng)幫你生成serialVersionUID的插件, 只要安裝, 自動(dòng)生成一步到位, 給你絲滑般的感受.
But, serialVersionUID生成是可以了, 但是秉承著知其然要知其所以然的態(tài)度, 要知道
- 它在序列化中的作用到底是什么?
- 為什么實(shí)現(xiàn)Serializable接口都要定義serialVersionUID?
- 為什么<<阿里巴巴Java開(kāi)發(fā)手冊(cè)>>要求謹(jǐn)慎修改serialVersionUID 字段的值?
尋找這些一步一步來(lái)
安裝GenerateSerialVersionUID插件
在線安裝
打開(kāi)設(shè)置頁(yè)面, 選擇plugins, 再點(diǎn)擊Browse Repositories選項(xiàng)進(jìn)入在線插件安裝頁(yè)面, 頁(yè)面搜索GenerateSerialVersionUID, 點(diǎn)擊右側(cè)Install
安裝完成重啟即可, 搞定啦[手動(dòng)摔刀]
離線安裝
去jetbrains官網(wǎng)上選擇看著順眼的版本下載插件安裝包, 將插件安裝包解壓, 解壓出的文件夾復(fù)制or剪切到idea安裝路徑下的plugins文件夾中, 然后重啟idea, 搞定啦[再摔刀]
深入了解serialVersionUID
安裝插件并不是目的, 目的是去解刨serialVersionUID, 眾所周知, serialVersionUID是作用在序列化過(guò)程中的, 序列化不是我們要挖掘的問(wèn)題[序列化同學(xué)你走開(kāi)], 但是我們可以通過(guò)對(duì)序列化的實(shí)驗(yàn)來(lái)了解serialVersionUID[序列化同學(xué)你回來(lái)!!!]
serialVersionUID的作用
眾所周知, Java對(duì)象是保存在JVM的堆內(nèi)存中的, 那么如果堆不存在了, 那么對(duì)象也就跟著消失了, 而序列化提供了一種方案, 可以讓你在即使JVM停機(jī)的情況下也能把對(duì)象保存下來(lái)的方案, 把Java對(duì)象序列化成可存儲(chǔ)或傳輸?shù)男问剑ㄈ缍M(jìn)制流），比如保存在文件中认然。這樣娩井，當(dāng)再次需要這個(gè)對(duì)象的時(shí)候骤菠，從文件中讀取出二進(jìn)制流畅厢，再?gòu)亩M(jìn)制流中反序列化出對(duì)象, 所以, 序列化就是將對(duì)象的狀態(tài)信息轉(zhuǎn)換為可存儲(chǔ)或傳輸?shù)男问降倪^(guò)程
那么serialVersionUID在這期間起到了什么作用?
其實(shí)虛擬機(jī)是否允許反序列化饲嗽，不僅取決于類(lèi)路徑和功能代碼是否一致拟杉，一個(gè)非常重要的一點(diǎn)是兩個(gè)類(lèi)的序列化 ID 是否一致翅娶，這個(gè)所謂的序列化ID，就是我們?cè)诖a中定義的serialVersionUID
為什么實(shí)現(xiàn)Serializable接口都要定義serialVersionUID?
如果我們沒(méi)有在類(lèi)中明確的定義一個(gè)serialVersionUID的話昼浦，看看會(huì)發(fā)生什么.
下面用代碼舉一個(gè)例子:
先使用以下類(lèi)定義一個(gè)對(duì)象馍资，該類(lèi)中不定義serialVersionUID，將其寫(xiě)入文件关噪。
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 String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
然后我們修改User1類(lèi)鸟蟹，向其中增加一個(gè)屬性。在嘗試將其從文件中讀取出來(lái)使兔，并進(jìn)行反序列化建钥。
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();
}
}
}
}
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，并且指出兩個(gè)serialVersionUID不同, 并且說(shuō)明了具體的serialVersionUID 的值.
這是因?yàn)椋?strong>在進(jìn)行反序列化時(shí)虐沥，JVM會(huì)把傳來(lái)的字節(jié)流中的serialVersionUID與本地相應(yīng)實(shí)體類(lèi)的serialVersionUID進(jìn)行比較熊经，如果相同就認(rèn)為是一致的，可以進(jìn)行反序列化欲险，否則就會(huì)出現(xiàn)序列化版本不一致的異常镐依，即是InvalidCastException
從這里可以看出，系統(tǒng)自己添加了一個(gè)serialVersionUID, 并且兩次添加的serialVersionUID不一致天试。
那么, 到這里也就知道為什么不能隨意修改serialVersionUID的值了, 如果你修改了serialVersionUID的值的話, 那么之前序列化過(guò)的對(duì)象無(wú)論相同與否, 在反序列化的時(shí)候都會(huì)報(bào)錯(cuò)
這也是《阿里巴巴Java開(kāi)發(fā)手冊(cè)》中規(guī)定槐壳，在兼容性升級(jí)中，在修改類(lèi)的時(shí)候喜每，不要修改serialVersionUID的原因务唐。除非是完全不兼容的兩個(gè)版本。所以 serialVersionUID其實(shí)是驗(yàn)證版本一致性的灼卢。
所以绍哎，一旦類(lèi)實(shí)現(xiàn)了Serializable来农，就建議明確的定義一個(gè)serialVersionUID鞋真。不然在修改類(lèi)的時(shí)候，就會(huì)發(fā)生異常沃于。
知其然, 要知其所以然
我們?cè)賮?lái)看看源碼涩咖，分析一下為什么serialVersionUID改變的時(shí)候會(huì)拋異常海诲？在沒(méi)有明確定義的情況下，默認(rèn)的serialVersionUID是怎么來(lái)的檩互？
為了簡(jiǎn)化代碼量特幔，反序列化的調(diào)用鏈如下：
ObjectInputStream.readObject ->
readObject0 ->
readOrdinaryObject ->
readClassDesc ->
readNonProxyDesc ->
ObjectStreamClass.initNonProxy
在initNonProxy中 ，關(guān)鍵代碼如下：
在反序列化過(guò)程中闸昨，對(duì)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();
}
在沒(méi)有定義serialVersionUID的時(shí)候拍嵌，會(huì)調(diào)用computeDefaultSUID 方法，生成一個(gè)默認(rèn)的serialVersionUID循诉。
這也就找到了以上兩個(gè)問(wèn)題的根源横辆，其實(shí)是代碼中做了嚴(yán)格的校驗(yàn)，并且在未定義的時(shí)候自動(dòng)生成了一個(gè)serialVersionUID茄猫。
END;
