[已解决]报异常java.io.InvalidClassException的解决方法|对象序列化实现Serializable会出现java.io.InvalidClassException的异常

一、前言

今天在增加完新功能后，部署的时候，突然就遇到了java.io.InvalidClassException的问题，这些都是我们平常不注意细节造成的后果。

具体异常如下

分析异常：Caused by:java. io. InvalidClassException: com. eastcom xxx.xxxxxx. bean. AlarmReq; local class incompatible: stream classdesc serialversionUID =1631280650588763177, local class seriaiversionuId = 6638111461888145730

二、分析原因

首先我们的系统架构，是因为要将对象通过

AlarmReq alarmReq= JSONObject.toJavaObject(json,AlarmReq.class);
redisQueue = redisTaskContainer.getRedisQueue();
redisQueue.pushFromHead(alarmReq);

上述方法会将对象序列化到redis内存中，然后又再通过 redisTemplate.getValueSerializer().deserialize() 方法将数据反序列化到bean对象，这样的话，如果改动了这个bean对象的话，即加了属性的话，就会导致serialVersionUID会变，而且当时我们的bean对象即上述的AlarmReq对象，当时是没有加serialVersionUID的。

由于序列化时该类的serialVersionUID是JVM根据类名及其属性的哈希值生成的。当类的属性有变动时，serialVersionUID也会相应变动，从而导致redis中的老数据反序列化为AlarmReq bean对象时，serialVersionUID匹配不上而失败，会报出java. io. InvalidClassException。

三、解决问题

知道原因了，我们就可以解决问题了

方法1：不考虑和老数据兼容的话，直接在你实现了Serializable的这个对象加一段serialVersionUID代码，如果还报InvalidClassException，将redis上的老数据清除

private static final long serialVersionUID = 1L;

方法2：兼容老数据，找到老数据的serialVersionUID，就是上述报错的地方，会将老数据的serialVersionUID报出来，比如我这里的老数据的就是1631280650588763177 这一串，你只要加 UID=1631280650588763177 这个就可以了。

private static final long serialVersionUID = 1631280650588763177L;

四、总结

可能好多人在写对象以及序列化对象的时候，是没有加private static final long serialVersionUID的，但是也没有见到有报InvalidClassException异常的，那是因为你部署的单体系统架构，实时序列化和反序列化的，每次系统重启就又重新实例对象，所以即使改变了对象增加属性，也不会出现老对象和新对象serialVersionUID 不一致的情况，所以也就不会出现java. io. InvalidClassException。

所以以后你们写对象并且要序列化的话，一定要随手加上serialVersionUID这段代码。

如果你们去看源码，HashMap、ArrayList 等这些神级代码的时候，你们可以看到，他们都是加了 serialVersionUID 代码的