当缺少serialVersionUID
时,Eclipse会发出警告。
可序列化类Foo不声明静态final long类型的serialVersionUID字段
什么是serialVersionUID
,为什么重要?请显示缺少serialVersionUID
会导致问题的示例。
答案 0 :(得分:2101)
java.io.Serializable
的文档可能与您将获得的解释一样好:
序列化运行时将每个可序列化类与版本号相关联,称为
serialVersionUID
,在反序列化期间使用该版本号来验证序列化对象的发送方和接收方是否已加载与该方对象兼容的类序列化。如果接收者为对象加载了一个类,该类具有与相应发送者类的serialVersionUID
不同的serialVersionUID
,那么反序列化将导致InvalidClassException
。可序列化类可以通过声明名为serialVersionUID
的字段来明确声明其自己的long
,该字段必须是静态的,最终的,并且类型为ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;
:serialVersionUID
如果可序列化类没有显式声明
serialVersionUID
,那么序列化运行时将根据类的各个方面计算该类的默认serialVersionUID
值,如Java(TM)中所述。 )对象序列化规范。但是,强烈建议所有可序列化类都显式声明serialVersionUID
值,因为默认的InvalidClassExceptions
计算对类详细信息非常敏感,可能会因编译器实现而异,并且因此在反序列化期间可能会导致意外serialVersionUID
。因此,为了保证跨不同java编译器实现的一致serialVersionUID
值,可序列化类必须声明显式serialVersionUID
值。强烈建议显式serialVersionUID
声明尽可能使用私有修饰符,因为此类声明仅适用于立即声明的类{{1}}字段作为继承成员无效。
答案 1 :(得分:441)
如果你的序列化只是因为你必须为了实现而序列化(例如,你关心序列化HTTPSession
,例如......如果它存储与否,你可能不关心de-serializing
表单对象),然后你可以忽略它。
如果您实际使用的是序列化,那么只有您计划直接使用序列化存储和检索对象才有意义。 serialVersionUID
表示您的班级版本,如果班级的当前版本与其先前版本不向后兼容,则应增加该版本。
大多数情况下,您可能不会直接使用序列化。如果是这种情况,请单击快速修复选项生成默认SerialVersionUID
,不要担心。
答案 2 :(得分:282)
我不能错过这个机会来插入Josh Bloch的书Effective Java(第2版)。第11章是Java序列化不可或缺的资源。
Per Josh,自动生成的UID是基于类名,已实现的接口以及所有公共成员和受保护成员生成的。以任何方式更改任何这些都将更改serialVersionUID
。因此,只有当您确定不会将一个以上版本的类序列化时(无论是跨进程还是稍后从存储中检索),您都不需要弄乱它们。
如果您暂时忽略它们,稍后发现需要以某种方式更改类但保持与旧版本类的兼容性,则可以使用JDK工具 serialver 生成旧类上的serialVersionUID
,并在新类上显式设置。 (根据您的更改,您可能还需要通过添加writeObject
和readObject
方法来实现自定义序列化 - 请参阅Serializable
javadoc或上述第11章。)
答案 3 :(得分:128)
您可以告诉Eclipse忽略这些serialVersionUID警告:
窗口>偏好> Java>编译器>错误/警告>潜在的编程问题
如果你不知道,你可以在本节中启用很多其他警告(甚至有一些报告为错误),其中许多是非常有用的:
还有更多。
答案 4 :(得分:102)
serialVersionUID
有助于序列化数据的版本控制。序列化时,其值与数据一起存储。反序列化时,将检查相同的版本以查看序列化数据如何与当前代码匹配。
如果要对数据进行版本设置,通常以serialVersionUID
为0开始,并将其与类的每个结构更改一起改变,这会改变序列化数据(添加或删除非瞬态字段)。
内置的反序列化机制(in.defaultReadObject()
)将拒绝从旧版本的数据中反序列化。但是如果你愿意,你可以定义自己的readObject() - 函数,它可以读回旧数据。然后,此自定义代码可以检查serialVersionUID
以了解数据所在的版本并决定如何对其进行反序列化。如果您存储的代码化数据能够存储多个版本的代码,则此版本控制技术非常有用。
但是如此长时间存储序列化数据并不常见。使用序列化机制临时将数据写入例如高速缓存或通过网络将其发送到具有相同版本的代码库相关部分的另一程序更为常见。
在这种情况下,您对维护向后兼容性不感兴趣。您只关心确保通信的代码库确实具有相同类型的相关类。为了便于进行此类检查,您必须像以前一样维护serialVersionUID
,并且在更改类时不要忘记更新它。
如果您忘记更新字段,最终可能会得到两个不同版本的类,这些类具有不同的结构但具有相同的serialVersionUID
。如果发生这种情况,默认机制(in.defaultReadObject()
)将不会检测到任何差异,并尝试反序列化不兼容的数据。现在,您最终可能会遇到神秘的运行时错误或静默失败(空字段)。这些类型的错误可能很难找到。
为了帮助这个用例,Java平台为您提供了不手动设置serialVersionUID
的选择。相反,类结构的哈希将在编译时生成并用作id。这种机制将确保您永远不会有具有相同id的不同类结构,因此您将无法获得上述难以跟踪的运行时序列化失败。
但自动生成的ID策略有一个缺点。也就是说,同一类的生成的id可能在编译器之间有所不同(如上面的Jon Skeet所述)。因此,如果您在使用不同编译器编译的代码之间传递序列化数据,则建议手动维护ID。
如果您在提到的第一个用例中向后兼容您的数据,您也可能希望自己维护ID。这是为了获得可读的ID,并且可以更好地控制它们何时以及如何变化。
答案 5 :(得分:68)
什么是 serialVersionUID ,为什么要使用它?
SerialVersionUID
是每个类的唯一标识符,JVM
使用它来比较类的版本,确保在反序列化期间加载序列化期间使用相同的类。
指定一个可以提供更多控制,但如果您没有指定,JVM会生成一个。生成的值可能因不同编译器而异。此外,有时您只是出于某种原因要求禁止对旧序列化对象[backward incompatibility
]进行反序列化,在这种情况下,您只需更改serialVersionUID即可。
默认的serialVersionUID计算对类非常敏感 细节可能因编译器实现而异,并且可以 因此导致意外
InvalidClassException
期间 反序列化。
因此,您必须声明serialVersionUID,因为它为我们提供了更多控制。
This article在这个主题上有一些好处。
答案 6 :(得分:51)
原始问题询问'为什么这很重要'和'示例'这个Serial Version ID
会有用。好吧,我找到了一个。
假设您创建了一个Car
类,将其实例化,并将其写入对象流。扁平的汽车对象在文件系统中存在一段时间。同时,如果通过添加新字段修改Car
类。稍后,当您尝试读取(即反序列化)展平的Car
对象时,您将获得java.io.InvalidClassException
- 因为所有可序列化的类都会自动获得唯一标识符。当类的标识符不等于展平对象的标识符时,抛出此异常。如果您真的考虑过它,则会因为添加新字段而抛出异常。您可以通过声明显式serialVersionUID来自行控制版本控制来避免抛出此异常。明确声明serialVersionUID
(因为不必计算)也会带来很小的性能优势。因此,最好在创建Serializable类时将其自己的serialVersionUID添加到Serializable类中,如下所示:
public class Car {
static final long serialVersionUID = 1L; //assign a long value
}
答案 7 :(得分:34)
如果您永远不需要将对象序列化为字节数组并发送/存储它们,那么您无需担心它。如果这样做,那么你必须考虑你的serialVersionUID,因为对象的反序列化器会将它与它的类加载器所具有的对象版本相匹配。在Java语言规范中阅读更多相关内容。
答案 8 :(得分:33)
如果你在类上得到这个警告,你从未想过序列化,并且你没有声明自己implements Serializable
,那通常是因为你继承了一个实现Serializable的超类。通常,最好委托给这样的对象而不是使用继承。
所以,而不是
public class MyExample extends ArrayList<String> {
public MyExample() {
super();
}
...
}
DO
public class MyExample {
private List<String> myList;
public MyExample() {
this.myList = new ArrayList<String>();
}
...
}
并在相关方法中调用myList.foo()
而不是this.foo()
(或super.foo()
)。 (这并不适合所有情况,但仍然经常使用。)
我经常看到人们扩展JFrame等,当他们真的只需要委托给它时。 (这也有助于在IDE中自动完成,因为JFrame有数百种方法,当你想在课堂上调用自定义方法时,你不需要这些方法。)
警告(或serialVersionUID)不可避免的一种情况是,从AbstractAction扩展(通常在匿名类中),只添加actionPerformed-method。我认为在这种情况下不应该有警告(因为你通常无法在类的不同版本中对这些匿名类进行可靠的序列化和反序列化),但我不确定编译器如何识别它。
答案 9 :(得分:22)
要理解字段serialVersionUID的重要性,应该了解序列化/反序列化的工作原理。
当Serializable类对象被序列化时,Java Runtime将序列版本号(称为serialVersionUID)与此序列化对象相关联。在反序列化此序列化对象时,Java Runtime将序列化对象的serialVersionUID与类的serialVersionUID匹配。如果两者都相等,则只进行反序列化的进一步处理,否则抛出InvalidClassException。
因此我们得出结论,为了使序列化/反序列化过程成功,序列化对象的serialVersionUID必须等同于该类的serialVersionUID。如果程序员在程序中明确指定serialVersionUID值,那么相同的值将与序列化对象和类相关联,而不管序列化和反序列化平台(例如,序列化可以通过使用sun或类似于windows的平台来完成) MS JVM和反序列化可能位于使用Zing JVM的不同平台Linux上。
但是如果程序员没有指定serialVersionUID,那么在执行任何对象的Serialization \ DeSerialization时,Java运行时会使用自己的算法来计算它。此serialVersionUID计算算法因JRE而异。对象序列化的环境也可能是使用一个JRE(例如:SUN JVM),而反序列化发生的环境是使用Linux Jvm(zing)。在这种情况下,与序列化对象关联的serialVersionUID将与在反序列化环境中计算的类的serialVersionUID不同。反过来反序列化也不会成功。因此,为了避免这种情况/问题,程序员必须始终指定Serializable类的serialVersionUID。
答案 10 :(得分:19)
首先,我需要解释序列化 序列化允许将对象转换为流,通过网络发送该对象或保存到文件或保存到DB以供字母使用。
有一些序列化规则 。
对象只有在其类或其超类实现Serializable接口时才可序列化
对象是可序列化的(本身实现了Serializable接口),即使它的超类不是。但是,可序列化类的层次结构中的第一个超类(不实现Serializable接口)必须具有无参数构造函数。如果违反了此规则,readObject()将在运行时生成java.io.InvalidClassException
所有基本类型都是可序列化的。
瞬态字段(带有瞬态修饰符)未被序列化(即,未保存或恢复)。实现Serializable的类必须标记不支持序列化的类的瞬态字段(例如,文件流)。
静态字段(带有静态修饰符)未序列化。
当对象被序列化时JAVA Runtime关联称为serialVersionID的序列版本号。
我们需要serialVersionID: 在反序列化期间验证发送方和接收方是否与序列化兼容。如果接收方加载了具有不同serialVersionID的类,则反序列化将结束 InvalidClassCastException 。
可序列化类可以通过声明名为“serialVersionUID”的字段来明确声明其自己的serialVersionUID,该字段必须是static,final和long类型:。
让我们试试这个例子。
import java.io.Serializable;
public class Employee implements Serializable {
private static final long serialVersionUID = 1L;
private String empname;
private byte empage;
public String getEmpName() {
return name;
}
public void setEmpName(String empname) {
this.empname = empname;
}
public byte getEmpAge() {
return empage;
}
public void setEmpAge(byte empage) {
this.empage = empage;
}
public String whoIsThis() {
StringBuffer employee = new StringBuffer();
employee.append(getEmpName()).append(" is ).append(getEmpAge()).append("
years old "));
return employee.toString();
}
}
创建序列化对象
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectOutputStream;
public class Writer {
public static void main(String[] args) throws IOException {
Employee employee = new Employee();
employee.setEmpName("Jagdish");
employee.setEmpAge((byte) 30);
FileOutputStream fout = new
FileOutputStream("/users/Jagdish.vala/employee.obj");
ObjectOutputStream oos = new ObjectOutputStream(fout);
oos.writeObject(employee);
oos.close();
System.out.println("Process complete");
}
}
Deserializ the object
import java.io.FileInputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
public class Reader {
public static void main(String[] args) throws ClassNotFoundException,
IOException {
Employee employee = new Employee();
FileInputStream fin = new
FileInputStream("/users/Jagdish.vala/employee.obj");
ObjectInputStream ois = new ObjectInputStream(fin);
employee = (Employee) ois.readObject();
ois.close();
System.out.println(employee.whoIsThis());
}
}
注意:现在更改Employee类的serialVersionUID并保存:
private static final long serialVersionUID = 4L;
执行Reader类。不执行Writer类,您将获得异常。
Exception in thread "main" java.io.InvalidClassException:
com.jagdish.vala.java.serialVersion.Employee; local class incompatible:
stream classdesc serialVersionUID = 1, local class serialVersionUID = 4
at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:616)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1623)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1518)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1774)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
at com.krishantha.sample.java.serialVersion.Reader.main(Reader.java:14)
答案 11 :(得分:18)
至于缺少serialVersionUID可能导致问题的示例:
我正在研究这个Java EE应用程序,它由一个使用EJB
模块的Web模块组成。 Web模块远程调用EJB
模块并传递实现POJO
的{{1}}作为参数。
这个Serializable
类打包在EJB jar中,并且位于Web模块的WEB-INF / lib中自己的jar中。它们实际上是同一个类,但是当我打包EJB模块时,我解压缩这个POJO的jar以将它与EJB模块一起打包。
对POJO's
的调用因下面的例外而失败,因为我没有声明EJB
:
serialVersionUID
答案 12 :(得分:18)
不要打扰,默认计算非常好,足以满足99,9999%的情况。如果你遇到问题,你可以 - 正如已经说明的那样 - 引入UID作为需求(非常不可能)
答案 13 :(得分:15)
我通常在一个上下文中使用serialVersionUID
:当我知道它将离开Java VM的上下文时。
当我为我的应用程序使用ObjectInputStream
和ObjectOutputStream
时,或者如果我知道我使用的库/框架将使用它时,我就会知道这一点。 serialVersionID确保不同版本或供应商的不同Java VM将正确地互操作,或者如果在VM外部存储和检索它,例如HttpSession
,即使在重新启动和升级应用程序服务器期间,会话数据也可以保留。 / p>
对于所有其他情况,我使用
@SuppressWarnings("serial")
因为大多数情况下默认serialVersionUID
就足够了。其中包括Exception
,HttpServlet
。
答案 14 :(得分:14)
字段数据表示存储在类中的一些信息。
类实现Serializable
接口,
所以eclipse自动提供声明serialVersionUID
字段。让我们从那里的值1开始。
如果您不希望发出警告,请使用以下命令:
@SuppressWarnings("serial")
答案 15 :(得分:11)
SerialVersionUID用于对象的版本控制。您也可以在类文件中指定serialVersionUID。不指定serialVersionUID的后果是,当您在类中添加或修改任何字段时,已经序列化的类将无法恢复,因为为新类和旧序列化对象生成的serialVersionUID将不同。 Java序列化过程依赖于正确的serialVersionUID来恢复序列化对象的状态,并在serialVersionUID不匹配的情况下抛出java.io.InvalidClassException
了解详情:http://javarevisited.blogspot.com/2011/04/top-10-java-serialization-interview.html#ixzz3VQxnpOPZ
答案 16 :(得分:10)
如果CheckStyle可以验证实现Serializable的类上的serialVersionUID是否具有良好的值,即它与串行版本ID生成器将产生的值匹配,那将是很好的。例如,如果你有一个包含大量可序列化DTO的项目,记住要删除现有的serialVersionUID并重新生成它是一件痛苦的事,目前唯一的方法(据我所知)来验证这是为每个类重新生成并比较旧的。这非常痛苦。
答案 17 :(得分:9)
为什么在Java SerialVersionUID
类中使用Serializable
?
在serialization
期间,Java运行时为类创建版本号,以便稍后可以对其进行反序列化。此版本号在Java中称为SerialVersionUID
。
SerialVersionUID
用于版本化序列化数据。如果类SerialVersionUID
与序列化实例匹配,则只能对类进行反序列化。当我们不在我们的类中声明SerialVersionUID
时,Java运行库会为我们生成它,但不推荐它。建议将SerialVersionUID
声明为private static final long
变量以避免默认机制。
当您通过实现标记接口Serializable
将类声明为java.io.Serializable
时,Java运行时通过使用默认的序列化机制将该类的实例保留到磁盘中,前提是您尚未使用{{1接口。
另见Why use SerialVersionUID inside Serializable class in Java
答案 18 :(得分:7)
如果你想修改大量没有设置serialVersionUID的类,同时保持与旧类的兼容性,那么像IntelliJ Idea,Eclipse这样的工具会因为生成随机数而无法工作一堆文件一气呵成。我提出了以下bash脚本(我很抱歉Windows用户,考虑购买Mac或转换为Linux)以轻松修改serialVersionUID问题:
base_dir=$(pwd)
src_dir=$base_dir/src/main/java
ic_api_cp=$base_dir/target/classes
while read f
do
clazz=${f//\//.}
clazz=${clazz/%.java/}
seruidstr=$(serialver -classpath $ic_api_cp $clazz | cut -d ':' -f 2 | sed -e 's/^\s\+//')
perl -ni.bak -e "print $_; printf qq{%s\n}, q{ private $seruidstr} if /public class/" $src_dir/$f
done
你保存这个脚本,比如说add_serialVersionUID.sh给〜/ bin。然后在Maven或Gradle项目的根目录中运行它,如:
add_serialVersionUID.sh < myJavaToAmend.lst
此.lst包含以下列格式添加serialVersionUID的java文件列表:
com/abc/ic/api/model/domain/item/BizOrderTransDO.java
com/abc/ic/api/model/domain/item/CardPassFeature.java
com/abc/ic/api/model/domain/item/CategoryFeature.java
com/abc/ic/api/model/domain/item/GoodsFeature.java
com/abc/ic/api/model/domain/item/ItemFeature.java
com/abc/ic/api/model/domain/item/ItemPicUrls.java
com/abc/ic/api/model/domain/item/ItemSkuDO.java
com/abc/ic/api/model/domain/serve/ServeCategoryFeature.java
com/abc/ic/api/model/domain/serve/ServeFeature.java
com/abc/ic/api/model/param/depot/DepotItemDTO.java
com/abc/ic/api/model/param/depot/DepotItemQueryDTO.java
com/abc/ic/api/model/param/depot/InDepotDTO.java
com/abc/ic/api/model/param/depot/OutDepotDTO.java
此脚本使用引擎盖下的JDK serialVer工具。因此,请确保您的$ JAVA_HOME / bin位于PATH中。
答案 19 :(得分:6)
这个问题在Joshua Bloch的Effective Java中有很好的记录。一本非常好的书,必读。我将概述以下一些原因:
序列化运行时为每个可序列化类提供了一个名为Serial版本的编号。此编号称为serialVersionUID。现在这个数字后面有一些数学,它基于类中定义的字段/方法出来。对于同一个类,每次都会生成相同的版本。在反序列化期间使用此数字来验证序列化对象的发送方和接收方是否已加载与序列化兼容的该对象的类。如果接收者为具有与相应发送者类的serialVersionUID不同的对象加载了一个类,则反序列化将导致InvalidClassException。
如果类是可序列化的,您还可以通过声明名为“serialVersionUID”的字段来明确声明自己的serialVersionUID,该字段必须是static,final和long类型。大多数IDE都像Eclipse一样帮助你生成那个长字符串。
答案 20 :(得分:6)
每次对象被序列化时,对象都标有对象类的版本ID号。该ID称为serialVersionUID,它是根据有关类结构的信息计算的。假设您创建了一个Employee类,它的版本号为#333(由JVM分配),现在当您序列化该类的对象时(假设为Employee对象),JVM会将UID指定为#333。
考虑一种情况 - 将来你需要编辑或更改你的类,在你修改它的情况下,JVM会为它分配一个新的UID(假设#444)。 现在,当您尝试反序列化员工对象时,JVM会将序列化对象的(员工对象)版本ID(#333)与类的类别(即#444(因为它已更改)进行比较。相比之下,JVM会发现两个版本的UID都不同,因此反序列化将失败。 因此,如果每个类的serialVersionID由程序员自己定义。即使该类在将来进化,它也是一样的,因此即使类被更改,JVM也总是会发现该类与序列化对象兼容。有关更多信息,请参阅HEAD FIRST JAVA的第14章。
答案 21 :(得分:2)
一个简单的解释:
您要序列化数据吗?
串行化基本上是将类数据写入文件/流/等。反序列化将数据读回到类中。
您打算投产吗?
如果您仅使用不重要/伪造的数据进行测试,则不必担心(除非您直接测试序列化)。
这是第一个版本吗?
如果是,请设置serialVersionUID=1L
。
这是第二,第三等产品版本吗?
现在您需要担心serialVersionUID
,并应深入研究它。
基本上,如果在更新需要编写/读取的类时未正确更新版本,则在尝试读取旧数据时会出现错误。
答案 22 :(得分:0)
总而言之,此字段用于检查序列化数据是否可以正确反序列化。序列化和反序列化通常由程序的不同副本进行-例如,服务器将对象转换为字符串,而客户端将收到的字符串转换为对象。该字段告诉双方,对于该对象是什么,它们具有相同的想法。此字段在以下情况下有帮助:
您在不同位置(例如1个服务器和100个客户端)有许多不同的程序副本。如果您要更改对象,更改版本号而忘记更新一个该客户端,它将知道他无法反序列化
您已将数据存储在某个文件中,然后稍后尝试使用带有修改后的对象的程序的更新版本打开它-如果您保持正确的版本,您将知道此文件不兼容
什么时候重要?
最明显的是-如果向对象添加一些字段,则较旧的版本将无法使用它们,因为它们的对象结构中没有这些字段。
不太明显-反序列化对象时,字符串中不存在的字段将保留为NULL。如果您已从对象中删除了字段,则较旧的版本会将字段保留为allways-NULL,如果较旧的版本依赖于此字段中的数据,则可能导致行为异常(无论如何,您都是出于某种目的而创建它的:-))
最不明显-有时您更改了某些领域的含义。例如,当您12岁时,“自行车”下的意思是“自行车”,但是当您18岁时,您的意思是“摩托车”-如果您的朋友邀请您“骑自行车穿越城市”,那么您将是唯一一个骑自行车,您将无法理解在各个领域保持相同含义的重要性:-)
答案 23 :(得分:0)
首先回答您的问题,当我们不在类中声明SerialVersionUID时,Java运行时会为我们生成它,但是该过程对许多类元数据敏感,包括字段数,字段类型,字段访问修饰符,由类实现的接口等。因此,建议自行声明它,Eclipse会警告您相同的情况。
序列化: 我们经常与重要对象一起工作,这些对象的状态(对象变量中的数据)是如此重要,以至于在将对象状态发送到其他计算机的情况下,我们不会因为电源/系统故障(或)网络故障而丢失它。此问题的解决方案称为“持久性”,它仅表示持久性(保存/保存)数据。序列化是实现持久性的许多其他方法之一(通过将数据保存到磁盘/内存)。保存对象的状态时,重要的是为对象创建一个标识,以便能够正确地将其读回(反序列化)。此唯一标识是ID,是SerialVersionUID。
答案 24 :(得分:0)
什么是SerialVersionUID? 答案:-假设有两个人,一个来自总部,另一个来自ODC,都将分别执行序列化和反序列化。在这种情况下,为了验证ODC中的接收者是经过身份验证的人,JVM会创建一个唯一ID,称为SerialVersionUID。
根据情况,这是一个很好的解释,
为什么使用SerialVersionUID?
序列化:在序列化时,每个对象发送方JVM都会保存一个唯一标识符。 JVM负责根据发送方系统中存在的相应.class文件生成该唯一ID。
反序列化:反序列化时,接收方JVM会将与对象关联的唯一ID与本地类Unique ID进行比较,即JVM还将基于对应的.class文件创建唯一ID。它存在于接收器系统中。如果两个唯一ID都匹配,则将仅执行反序列化。否则,我们将获得Runtime Exception,显示InvalidClassException。这个唯一的标识符不过是SerialVersionUID