serialVersionUID行动

ORIGINAL：未知

Java断类的serialVersionUID来验证版本号一致性的。在进行反序列化时，JVM会把传来的字节流中的serialVersionUID与本地对应实体（类）的serialVersionUID进行比較，假设同样就觉得是一致的。能够进行反序列化，否则就会出现序列化版本号不一致的异常。

Eclipse中The serializable class XXXXXX does not declare a static final serialVersionUID field of type long出现这种警告处理办法。

当採用程序的Add default Serial version ID修复时，Eclipse会加上：private static final long serialVersionUID = 1L; 



当採用程序的Add generated Serial version ID修复时。Eclipse会加上：private static final long serialVersionUID = xxxxL; 



事实上这个问题出现的详细原因是和序列化中的这个serialVersionUID有关。 



serialVersionUID 用来表明类的不同版本号间的兼容性。

有两种生成方式： 



一个是默认的1L。比方：private static final long serialVersionUID = 1L;（相应修复方法1） 



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

private static final long serialVersionUID = xxxxL;（相应修复方法2） 



在JDK中。能够利用JDK的bin文件夹下的serialver.exe工具产生这个serialVersionUID 的值，对于Test.class，运行命令： 

serialver Test   这时JVM（java虚拟机）会生成一个哈希字段。 



对照一下这个哈希字段的值与方法2中生成的字段值是一样的，可见，在CMD中使用serialver指令就是依据类名、接口名、成员方法及属性等来生成哈希字段的。 



以下来讨论java类中为什么须要重载 serialVersionUID 属性。

当两个进程在进行远程通信时。彼此能够发送各种类型的数据。不管是何种类型的数据。都会以二进制序列的形式在网络上传送。发送方须要把这个Java对象转换为字节序列，才干在网络上传送。接收方则须要把字节序列再恢复为Java对象。

　　把Java对象转换为字节序列的过程称为对象的序列化。 



　　把字节序列恢复为Java对象的过程称为对象的反序列化。 



　　对象的序列化主要有两种用途： 



　　1） 把对象的字节序列永久地保存到硬盘上，通常存放在一个文件里； 



　　2） 在网络上传送对象的字节序列。 



java.io.ObjectOutputStream代表对象输出流，它的writeObject(Object obj)方法可对參数指定的obj对象进行序列化，把得到的字节序列写到一个目标输出流中。 



java.io.ObjectInputStream代表对象输入流，它的readObject()方法从一个源输入流中读取字节序列，再把它们反序列化为一个对象，并将其返回。

仅仅有实现了Serializable和Externalizable接口的类的对象才干被序列化。Externalizable接口继承自Serializable接口，实现Externalizable接口的类全然由自身来控制序列化的行为，而仅实现Serializable接口的类能够採用默认的序列化方式 。

凡是实现Serializable接口的类都有一个表示序列化版本号标识符的静态变量：private static final long serialVersionUID; 



类的serialVersionUID的默认值全然依赖于Java编译器的实现，对于同一个类。用不同的Java编译器编译，有可能会导致不同的serialVersionUID。也有可能同样。为了提高serialVersionUID的独立性和确定性，强烈建议在一个可序列化类中显示的定义serialVersionUID。为它赋予明白的值。显式地定义serialVersionUID有两种用途： 



　　1）在某些场合，希望类的不同版本号对序列化兼容，因此须要确保类的不同版本号具有同样的serialVersionUID。在某些场合。不希望类的不同版本号对序列化兼容。因此须要确保类的不同版本号具有不同的serialVersionUID。 



　　2）当你序列化了一个类实例后，希望更改一个字段或加入一个字段。不设置serialVersionUID，所做的不论什么更改都将导致无法反序化旧有实例。并在反序列化时抛出一个异常。

假设你加入了serialVersionUID，在反序列旧有实例时，新加入或更改的字段值将设为初始化值（对象为null，基本类型为对应的初始默认值），字段被删除将不设置。 



当系统不须要序列化类时，能够去掉这些警告，做例如以下设置：Window-->Preferences-->Java，将serializable class without serialVersionUID的设置由warning改为Ignore。然后Eclipse会又一次编译程序，那些警告信息也就消失了。 



struts架构下的站点常常出现javax.servlet.ServletException: BeanUtils.populate 错误，可是本地执行又一切正常，唯一认为可能产生问题的就是server上跑了好几个站点，都是一样的架构的，怀疑是不是web容器把几个项目之间的java类给共用了，考虑到非常多类都定义了serialVersionUID字段，然后尝试删除了某个类的serialVersionUID，结果关于该类的操作就恢复正常了。网上简单查阅了一下资料。感觉是tomcat把全部类串行化时候，因为我们的几个项目非常多java类都是复制粘贴的。所造成一个非常大的类serialVersionUID它们是相同的值，所以tomcat将类相同的类名，因为不同的项目来处理同一类。这导致了一个奇怪的错误。

解决方案： 

每个项目的类具有相同的名称serialVersionUID变化是不一样的，不是直接复制粘贴。