一、前言
今天在增加完新功能后， 部署的时候，突然就遇到了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 代码的
五、使用idea工具自动生成
1、按照下图所示，设置好后，不要忘记点击【Apply】应用一下
2、在实现了 Serializable的bean类下， 鼠标移到bean类名处，按住 alt+enter，就会自动弹出【Add serialVersionUID field】
选中即可自动生成啦，
