serialVersionUID

serialVersionUID作用：

序列化时为了保持版本的兼容性，即在版本升级时反序列化仍保持对象的唯一性。

有两种生成方式：

一个是默认的1L，比如：private static final long serialVersionUID = 1L;

一个是根据类名、接口名、成员方法及属性等来生成一个64位的哈希字段，比如：

private static final long  serialVersionUID = xxxxL;

完整的基础内容看以下网址

http://www.cnblogs.com/xdp-gacl/p/3777987.html

当你一个类实现了Serializable接口，如果没有定义serialVersionUID，Eclipse会提供这个提示功能告诉你去定义 。在Eclipse中点击类中warning的图标一下，Eclipse就会自动给定两种生成的方式。如果不想定义它，在Eclipse的设置中也可以把它关掉的，设置如下：

Window ==> Preferences ==> Java ==> Compiler ==> Error/Warnings ==>

Potential programming problems

将Serializable class without serialVersionUID的warning改成ignore即可。

如果你没有考虑到兼容性问题时，就把它关掉，不过有这个功能是好的，只要任何类别实现了Serializable这个接口的话，如果没有加入serialVersionUID，Eclipse都会给你warning提示，这个serialVersionUID为了让该类别Serializable向后兼容。

如果你的类Serialized存到硬盘上面后，可是后来你却更改了类别的field(增加或减少或改名)，当你Deserialize时，就会出现Exception的，这样就会造成不兼容性的问题。

但当serialVersionUID相同时，它就会将不一样的field以type的预设值Deserialize，可避开不兼容性问题。

 

 

 

java文件中为什么会有serialVersionUID 。

一些java类中为什么需要重载serialVersionUID属性。

在Java中，软件的兼容性是一个大问题，尤其在使用到对象串行性的时候，那么在某一个对象已经被串行化了，可是这个对象又被修改后重新部署了，那么在这种情况下，用老软件来读取新文件格式虽然不是什么难事，但是有可能丢失一些信息。

serialVersionUID 来解决这些问题，新增的serialVersionUID必须定义成下面这种形式：static final long serialVersionUID=-2805284943658356093L；其中数字后面加上的L表示这是一个long值。通过这种方式来解决不同的版本之间的串行话问题。

提纲：

一、概述

二、Java串行化

三、引入版本编号

四、结束语

一、概述

一个程序正式发行出去之后，如果要增加一些新的功能，往往意味着同时要修改用户保存数据的方式，也就是必须更改程序保存文件的格式——通常是增加保存到文件的数据。有些时候，文件格式必须作彻底的改动，以配合实现程序的新功能。从这个意义上看，文件格式的发展/变化总是和程序的功能改进相呼应。

但是，大多数情况下，把原有的数据格式一丢了事是行不通的。动物王国中，不能适应环境意味着死亡；软件领域也相似，新软件是否支持原有的数据格式很大程度上决定了用户是否升级。

不管软件新增/改进了多少功能，不管新的文件格式是多么完美，如果新软件不能利用原来的文件格式，用户一般不太会认可新软件。解决该问题的办法包括：

● 保留老代码来读取老文件。采用这种方案一般需要额外编写一些代码，把老文件转换成新的格式（一般地，最简单的办法是先把老文件的数据转换成新的内部对象， 然后利用现有的写入新版文件格式的对象）。这种办法的好处是既保留了原有的代码，又使它与新的文件格式兼容。但是，这种办法有时可能导致丢失部分数据，不 过总要比丢失全部数据好。

●使新版软件能够读/写老文件格式。这种办法工作量较大，因为程序的新版本一般会增加一些原来没有的功能，老的数据格式中通常缺乏新功能必需的某些数据。

当新版软件对原来执行任务的方式作了根本性的变动时，丢失数据决非难得一见的偶然事件。如果新版软件采用和原来不同的方式达到同样的效果，原来的功能可能不 再有保留的必要。例如，如果一个程序原来用Swing做用户界面，现在把它改成了Web（浏览器）用户界面，原来的许多用户界面设置就不再有效。

又如，如果有一个邮件程序，原来用的是以文件夹为基础的索引，现在把它改成了以单词为基础的索引系统，在升级索引文件格式的过程中就有可能丢失许多信息；如果原来的索引文件保存了许多用户配置选项和优化措施，在新的索引系统中这些数据可能无法利用。

这类问题没有绝对完美的解决办法，但是我们可以采取一些措施，使得升级文件格式带来的负面影响尽可能小。Java串行化（Serialization）有着 简单易用的特点，日益成为一种保存文件的重要手段，有鉴于此，下面我们就来看看在软件版本变更过程中，通过Java串行化保存的文件如何保持兼容性。

二、Java串行化

Java串行化有许多优点：

●容易使用。

●如果一个对象连接到其他对象，串行化机制会保存所有相关的对象。

●如果某个对象出现多次，串行化机制只保存一次。这一点极为重要，它不仅减小了文件空间，而且即使代码写得不是很老练，也不必担心会出现无限循环（一个不老练的例子是，用递归的方式保存各个对象，却又未能有效审计哪些对象已经保存，这时就有可能陷入永无终止的循环）。

遗憾的是，Java串行化机制定义的文件格式似乎很脆弱，只要稍微改动一下类的定义，原来保存的对象就可能无法读取。例如，下面是一个简单的类定义：

public class Save implements Serializable{

String name;

public void save() throws IOException{

FileOutputStream f = new FileOutputStream("foo");

ObjectOutputStream oos = new ObjectOutputStream(f);

oos.writeObject(this);

oos.close();

}

}

如果在这个类定义中增加一个域，例如final int val = 7;，再来读取原来保存的对象，就会出现下面的异常：

java.io.InvalidClassException:

Save; local class incompatible:

stream classdesc serialVersionUID = -2805284943658356093,

local class serialVersionUID = 3419534311899376629

上例异常信息中的数字串表示类定义里各种属性的编码值：

●类的名字（Save）。

●域的名字（name）。

●方法的名字（Save）。

●已实现的接口（Serializable）。

改动上述任意一项内容（无论是增加或删除），都会引起编码值变化，从而引起类似的异常警报。这个数字序列称为“串行化版本统一标识符”（serial version universal identifier），简称UID。解决这个问题的办法是在类里面新增一个域serialVersionUID，强制类仍旧使用原来的UID。新增的域 必须是：

●static：该域定义的属性作用于整个类，而非特定的对象。

●final：保证代码运行期间该域不会被修改。

●long：它是一个64位的数值。

也就是说，新增的serialVersionUID必须定义成下面这种形式：static final long serialVersionUID=-2805284943658356093L;。其中数字后面加上的L表示这是一个long值。

当然，改动之后的类不一定能够和原来的对象兼容。例如，如果把一个域的定义从String改成了int，执行逆-串行化操作时系统就不知道如何处理该值，显示出错误信息：

java.io.InvalidClassException: Save;

incompatible types for field name。

Java串行化规范

（http://java.sun.com/j2se/1.4.1/docs/guide/serialization/spec/serialTOC.doc.html）

提供了有关兼容的改动

（http://java.sun.com/j2se/1.4.1/docs/guide/serialization/spec/version.doc7.html）

和不兼容改动

（http://java.sun.com/j2se/1.4.1/docs/guide/serialization/spec/version.doc8.html）的清单，这些清单指出了对类作了哪些改动之后仍可能读取原来串行化的数据。具体细节比较复杂，但了解其主要机制还是很容易的：

简而言之，如果文件中确实保存了所有必需的数据，那么仍有可能读取该文件，当然前提是必须处理好串行化的UID。

三、引入版本编号

许多程序都在无意之中作出了这样的假设：这种文件格式是我要用到的最后一种格式，以后不再需要制定新的格式，现在要做的是处理好在此之前的各种格式。这种程 序会试图读取格式版本更高的文件，操作进行到一半才发现某些不能识别的数据，然后就是突然崩溃。如果文件包含了大量的元数据（描述文件本身的数据），处理 起来就要容易得多。

在Java中，每一个域都由其名称显式标明，只要文件的改动不是很大（只添加了域，没有被删除或作重大更改的域），可以想象，用老软件来读取新文件格式不是什么难事，虽然有可能丢失一些信息，但可以搞清楚文件的基本情况。

文件格式随着程序功能的改变而改变。理想情况下，程序应当做到既向后兼容（新的版本能够按照老版本的格式读取，甚至可能允许更新），同时做到向前兼容（较老的软件能够识别和处理新版的文件格式）。

通常，文件的版本无法从表面上一眼看出。大多数程序不会因为文件的版本不同而更改文件扩展名，而且目前尚无统一的标记文件版本的办法。因此，有关文件格式的 版本声明只能在文件本身之内进行。如果你现在使用的文件格式还不包含版本声明，最好在下次把文件升级成一个不兼容的版本时马上加入版本标记，或者寻求一种 在当前文件格式中加入版本标记但不会带来负面影响的办法。

版本信息一般在文件的开头声明，这是因为程序必须在处理文件之前首先检查文件的版本，除非确定了文件的版本，否则不必读取文件的其余部分。

按照惯例，文件版本编号包含两个部分：主版本编号和次版本编号。一个特定版本的程序应当有最适合它处理的主-次版本号；主版本号变化意味着文件格式的重大变化，要继续使用已经非常困难，必须作出重大修改才能升级到新的版本。

文件的主次版本号之前往往还可以加入另一项内容，称为“魔术数字”，它的作用就是保证程序处理的文件类型不会有误（因为文件扩展名有可能不能唯一地标明文件 类型）。例如，Java的类文件总是以下列字节内容开头（十六进制）：CA FE BA BE。目前还没有这类数字的统一注册机构，不过UNIX在/etc/magic下提供了一个清单（但并不完整）。魔术数字一般有四个字节，取值范围很大， 所以一般不必担心会出现取值冲突的情形。

在编写和维护必须读/写文件的代码时，注意代码的向前/向后兼容性是非常必要的。在处理文件的代码中首先读取文件版本，然后根据版本号将文件剩余内容传递给适当的处理方法；如果文件的版本太老，已不再支持，程序应当给出明确的提示。

四、结束语

文件格式设计是一个极其重要的话题，但本文还有许多细节问题尚未涉及。例如，对于大型文件，我们需要随机访问，而不是从前向后依次读取文件内容的顺序访问， 这样就不必为了访问文件最后几个字节而读取整个文件。无论是XML还是Java串行化对这类随机访问的支持都不是很理想，而且这类文件格式的发展变化比普通文件更难管理，因为他们依赖于字节级的访问，稍微改动一下文件格式就可能导致不兼容。

如果要让文件具有ACID特性—— Atomicity、Consistency、Isolation和Durability，即原子性、一致性、隔离性、持久性，问题更加复杂。ACID与事务的概念密切相关，支持多用户同时访问一个文件。对于这类文件，可以考虑采用某种小型的数据库系统，例如Birdstep或Sleepycat。不过这已经进入了文件格式管理的另一个领域，既涉及到数据库管理软件的版本，也涉及到数据模式设计的版本。

撇开这些复杂的问题不谈，在实践中，很多时候我们只需简单的文件来保存数据，而且不会出现多用户并发访问，可以一次性地处理整个文件（或者至少适合使用顺序访问方式）。对于这些情形，最好在设计文件格式时就考虑版本问题，在日后的运行、维护中一定会带来不少方便。