原文出处：未知

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改为不一样，不能直接的复制粘贴过来。