序列化的serialVersionUID小结.

serialVersionUID的使用
1当你一个类实现了Serializable接口，如果没有显示的定义serialVersionUID，Eclipse会提供这个提示功能告诉你去定义 。在Eclipse中点击类中warning的图标一下，Eclipse就会 自动给定两种生成的方式。

如果不想定义它，在Eclipse的设置中也 可以把它关掉的，设置如下： Window ==> Preferences ==> Java ==> Compiler ==> Error/Warnings ==> Potential programming problems 将Serializable class without serialVersionUID的warning改成ignore即可。

两种serialVersionUID的异同

两种方式：

一个是默认的1L，如：private static final long serialVersionUID = 1L;
一个是根据类名、接口名、成员方法及属性等来生成一个64位的哈希字段
private static final long serialVersionUID =-130285025186444366L;

共同点，就是都能实现，保持版本的兼容性。在类版本升级时反序列化仍保持对象的唯一性。

不同点是：1生成方式不同。2，第一种方式，在可兼容的前提下，可以保留旧版本号，如果不兼容，或者想让它不兼容，就手工递增版本号。1L->2L->3L…..
3,第二种方式，是根据类的结构产生的hash值。增减一个属性、方法等，都可能导致这个值产生变化。我想这种方式适用于这样的场景：

开发者认为每次修改类后就需要生成新的版本号，不想向下兼容，操作就是删除原有serialVesionUid声明语句，再自动生成一下。一般采用第一种就行了，简单。第二种能够保证每次更改类结构后改变版本号，但还是要手工去生成，并不是修改了类，会提示你要去更新这个SerialVersionUid，所以虽然看上去很cool，实际上让人很迷惑。

Java的序列化机制
Java的序列化机制是通过在运行时判断类的serialVersionUID来验证版本一致性的。在进行反序列化时，JVM会把传来的字节流中的serialVersionUID与本地相应实体（类）的serialVersionUID进行比较，如果相同就认为是一致的，可以进行反序列化，否则就会出现序列化版本不一致的异常。(InvalidCastException)

我的思考（我的理解而已，不一定正确）
这个考虑的就是软件版本兼容的问题。比如我们类版本1的一个对象序列化了，一段时间后，我们修改了这个类，那么相应的serialVersionUID的改变可以控制，先前被序列化的对象还能不能反序列化。