未显式声明serialVersionUID引发Java反序列化InvalidClassException问题

核心原因 #

这个异常的本质是未显式声明serialVersionUID的类，在不同编译环境下自动生成的序列化版本号不一致：

• Java规范中，如果类未显式声明serialVersionUID，JVM会根据类的结构（字段、方法、继承关系、访问修饰符等）自动计算一个哈希值作为版本号。
• 你场景中服务器（Weblogic）和客户端分别使用不同的Java 8.x JVM（可能是不同厂商，如Oracle JDK vs OpenJDK，或同一厂商的不同小版本），甚至是不同的编译器（服务器用javac，客户端用Eclipse内置的ECJ），自动计算版本号的算法可能存在细微差异，导致同一个类在两端生成的serialVersionUID完全不同。
• 问题随机出现的原因是：部分类的结构在两种编译环境下计算出的哈希值偶然一致，而另一些则不一致；或者编译缓存的残留（比如Eclipse未彻底清理旧编译文件）导致偶尔加载到版本号不同的类。

根本解决方案 #

唯一能彻底解决这个问题的办法是为所有涉及序列化的EJB相关类显式声明固定的serialVersionUID：

• 找到所有抛出异常的EJB类，以及所有实现Serializable接口的类（包括EJB实现类、远程接口、数据传输对象DTO等），添加如下代码：

  private static final long serialVersionUID = 1L; // 数值可自定义，只要两端一致即可
  

• 确保客户端和服务器端使用的这些类拥有完全相同的serialVersionUID。最优做法是将这些类打包成一个独立的JAR包，同时部署到Weblogic的EAR包中，以及添加到客户端的类路径中，避免两端分别编译导致的差异。

辅助排查与验证步骤 #

1. 清理两端编译缓存：
   • 服务器端：除了清理Weblogic缓存，还要确保重新部署的EAR包是用统一编译器编译的（比如和客户端一致的JDK/javac版本）。
   • 客户端：清空Eclipse的编译输出目录（默认是bin或target/classes），然后重新编译客户端代码，避免残留旧的类文件。
2. 检查类路径冲突：客户端类路径中不要存在多个版本的同一类，确保只加载最新的、带有显式serialVersionUID的类文件。
3. 验证编译环境一致性：尽量让服务器和客户端使用同一厂商、同一小版本的Java 8 JVM，减少自动生成版本号的差异概率（但这只是辅助，不能替代显式声明serialVersionUID）。

为什么清理缓存/重新编译无效？ #

清理缓存或重新编译只能清除旧的部署文件，但只要两端仍使用不同的编译环境自动生成serialVersionUID，同一个类的版本号依然会不一致。只有显式声明固定值，才能脱离编译环境的影响，保证两端版本号一致。

内容的提问来源于stack exchange，提问作者J Slick