写代码的时候习惯性喜欢把model类实现Serializable接口, 既然实现了Serializable接口, 那么想当然的需要定义一个serialVersionUID, 难受就难受到serialVersionUID的值, 不好取啊, 看着就难受好么.
- 值太短? 看着好丑, 人家都是长长的, 我不能短.
- 乱敲一通搞的很长, 强迫症表示很难受
So, 我就找到了一款能自动帮你生成serialVersionUID的插件, 只要安装, 自动生成一步到位, 给你丝滑般的感受.
But, serialVersionUID生成是可以了, 但是秉承着知其然要知其所以然的态度, 要知道
- 它在序列化中的作用到底是什么?
- 为什么实现Serializable接口都要定义serialVersionUID?
- 为什么<<阿里巴巴Java开发手册>>要求谨慎修改serialVersionUID 字段的值?
寻找这些一步一步来
安装GenerateSerialVersionUID插件
在线安装
打开设置页面, 选择plugins, 再点击Browse Repositories选项进入在线插件安装页面, 页面搜索GenerateSerialVersionUID, 点击右侧Install
安装完成重启即可, 搞定啦[手动摔刀]
离线安装
去jetbrains官网上选择看着顺眼的版本下载插件安装包, 将插件安装包解压, 解压出的文件夹复制or剪切到idea安装路径下的plugins文件夹中, 然后重启idea, 搞定啦[再摔刀]
深入了解serialVersionUID
安装插件并不是目的, 目的是去解刨serialVersionUID, 众所周知, serialVersionUID是作用在序列化过程中的, 序列化不是我们要挖掘的问题[序列化同学你走开], 但是我们可以通过对序列化的实验来了解serialVersionUID[序列化同学你回来!!!]
serialVersionUID的作用
众所周知, Java对象是保存在JVM的堆内存中的, 那么如果堆不存在了, 那么对象也就跟着消失了, 而序列化提供了一种方案, 可以让你在即使JVM停机的情况下也能把对象保存下来的方案, 把Java对象序列化成可存储或传输的形式（如二进制流），比如保存在文件中。这样，当再次需要这个对象的时候，从文件中读取出二进制流，再从二进制流中反序列化出对象, 所以, 序列化就是将对象的状态信息转换为可存储或传输的形式的过程
那么serialVersionUID在这期间起到了什么作用?
其实虚拟机是否允许反序列化，不仅取决于类路径和功能代码是否一致，一个非常重要的一点是两个类的序列化 ID 是否一致，这个所谓的序列化ID，就是我们在代码中定义的serialVersionUID
为什么实现Serializable接口都要定义serialVersionUID?
如果我们没有在类中明确的定义一个serialVersionUID的话，看看会发生什么.
下面用代码举一个例子:
先使用以下类定义一个对象，该类中不定义serialVersionUID，将其写入文件。
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类，向其中增加一个属性。在尝试将其从文件中读取出来，并进行反序列化。
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;
}
}
执行结果：
java.io.InvalidClassException: com.hollis.User1; local class incompatible: stream classdesc serialVersionUID = -2986778152837257883, local class serialVersionUID = 7961728318907695402
抛出了InvalidClassException，并且指出两个serialVersionUID不同, 并且说明了具体的serialVersionUID 的值.
这是因为，在进行反序列化时，JVM会把传来的字节流中的serialVersionUID与本地相应实体类的serialVersionUID进行比较，如果相同就认为是一致的，可以进行反序列化，否则就会出现序列化版本不一致的异常，即是InvalidCastException
从这里可以看出，系统自己添加了一个serialVersionUID, 并且两次添加的serialVersionUID不一致。
那么, 到这里也就知道为什么不能随意修改serialVersionUID的值了, 如果你修改了serialVersionUID的值的话, 那么之前序列化过的对象无论相同与否, 在反序列化的时候都会报错
这也是《阿里巴巴Java开发手册》中规定，在兼容性升级中，在修改类的时候，不要修改serialVersionUID的原因。除非是完全不兼容的两个版本。所以 serialVersionUID其实是验证版本一致性的。
所以，一旦类实现了Serializable，就建议明确的定义一个serialVersionUID。不然在修改类的时候，就会发生异常。
知其然, 要知其所以然
我们再来看看源码，分析一下为什么serialVersionUID改变的时候会抛异常？在没有明确定义的情况下，默认的serialVersionUID是怎么来的？
为了简化代码量，反序列化的调用链如下：
ObjectInputStream.readObject ->
readObject0 ->
readOrdinaryObject ->
readClassDesc ->
readNonProxyDesc ->
ObjectStreamClass.initNonProxy
在initNonProxy中 ，关键代码如下：
在反序列化过程中，对serialVersionUID做了比较，如果发现不相等，则直接抛出异常。
深入看一下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的时候，会调用computeDefaultSUID 方法，生成一个默认的serialVersionUID。
这也就找到了以上两个问题的根源，其实是代码中做了严格的校验，并且在未定义的时候自动生成了一个serialVersionUID。
END;
