是由于软件测试上有同学提到说,什么该字段在程序刚运行时,导致jvm激增,所以吸引了我的注意
MybatisPlus Generator自动生成的entity中就经常带有这个,
而且我在开发代码的时候VO,以及DTO常常是直接复制对应的entity,所以也保不齐我对应的VO等对象也保留了这个(惭愧表情包),印象中之前就学过,不过忘得差不多了,所以就于此复习一下
在Java中，implements Serializable和serialVersionUID是与对象序列化（serialization）相关的概念，特别是在需要将对象的状态持久化、传输或者缓存时会用到。下面详细解释这些概念以及在MyBatis-Plus中它们的使用场景。
持久化：将对象的状态保存到一个存储介质（如文件、数据库）中，以便后续可以恢复。
传输：通过网络传输对象，比如在分布式系统中，从一个JVM传递到另一个JVM。
缓存：将对象放入缓存中，以便于快速恢复对象状态。
版本控制：在反序列化时，JVM会检查传入的字节流中的serialVersionUID是否与本地对应类的serialVersionUID一致。如果一致，说明序列化的版本是兼容的，可以安全地进行反序列化。如果不一致，会抛出InvalidClassException，防止版本不兼容带来的问题。
手动定义serialVersionUID可以避免某些情况下因类的微小变动（如增加一个方法或字段）导致的反序列化失败。一个常见的定义方式是：
private static final long serialVersionUID = 1L;
对于不同的序列化机制，如JSON序列化、数据库存储以及其他的自定义序列化方案，serialVersionUID 并不起作用。下面详细讨论serialVersionUID在不同场景中的作用和局限性，以及其他场景中的序列化方式。
import com.fasterxml.jackson.databind.ObjectMapper;
public class User {
private String name;
private int age;
// Getters and Setters
}
ObjectMapper objectMapper = new ObjectMapper();
User user = new User();
user.setName("John");
user.setAge(30);
// 序列化
String jsonString = objectMapper.writeValueAsString(user);
// 反序列化
User user2 = objectMapper.readValue(jsonString, User.class);
serialVersionUID 的适用场景
综上所述，serialVersionUID 的适用场景主要局限于Java内置的序列化机制。当你在分布式系统中使用Java对象的原生序列化和反序列化时，serialVersionUID 可以确保不同版本的类之间的兼容性。如果你的应用程序不使用Java内置的序列化机制，而是使用JSON、XML或其他格式进行序列化，那么 serialVersionUID 并不需要关注。
举个我在项目中遇到的例子
当时我在实现一个OJ系统,其中有个类似github,leetcode的提交记录等等的情况,我是懒得放到个人主页,于是我直接放到首页中,其中对应的数据该在后端中怎么存呢?
我联想到了bitmap,可惜他只能是二值,而我们需要保留提交记录中一天提交了多少次呀,所以是不可行的,那么bitmap不行,没有其他的数据结构能同样省空间了吗?有那就CountMinSketch,但是他是概率数据结构,也就是说可能会有误差(也就是误差率以及误差距离越小那么消耗更多的空间,底层思路实现和bloomfilter类似)
这是我当时写的小测试:
public class TestCountMinScratch {
public static void main(String[] args) {
CountMinSketch sketch = new CountMinSketch(0.001, 0.99, 1);
// 对数据进行更新
sketch.add("2024-5-16",1);
sketch.add("2024-5-16",1);
sketch.add("2024-5-16",1);
// 查询频率
long frequency = sketch.estimateCount("2024-5-16");
System.out.println("Frequency of 'example': " + frequency);
}
}
这个是当时最后没用上的代码,最后选择用了hash结合一定的编码来进行处理,考虑到通常展示的365个天数的提交记录应该也不会很耗时间,又能具有准确性
下面是之前使用CountMinSketch的代码:
@Component
public class CountMinSketchFactory {
/**
* 误差率:确保与最大为真实值*(1+epsOfTotalCount)
* 最小同理
*/
private final static double epsOfTotalCount=0.07;
/**
* 置信度:置信度为 0.99 意味着我们希望在 99% 的情况下，查询估计的误差在指定的误差率范围内。
* 也就是99%的情况在上面我们推出的范围中
*/
private final static double confidence=0.99;
/**
* 在随机数生成和某些概率数据结构中（如 CountMinSketch），种子（seed） 是一个初始值，用于初始化随机数生成器或哈希函数。它的作用是确保随机过程在相同的种子下每次运行都产生相同的结果。
*/
private final static int seed=1;
@Autowired
private BitmapRedisTemplate bitmapRedisTemplate;
public CountMinSketch getCountMinSketch(Long uid) {//todo:这里是否适合双检加锁?
String s = bitmapRedisTemplate.opsForValue().get(RedisConstant.USER_COMMIT_STATICS + uid);
if(s==null) {
return new CountMinSketch(epsOfTotalCount, confidence, seed);
}else{
return JSONUtil.toBean(s, CountMinSketch.class);
}
}
public void storeCountMinSketch(Long uid,CountMinSketch countMinSketch) {
bitmapRedisTemplate.opsForValue().set(RedisConstant.USER_COMMIT_STATICS + uid, JSONUtil.toJsonStr(countMinSketch));
}
}
对于这个情况我原本是打算使用redis来存储的,毕竟是微服务项目,于是我开始两个方案进行对比,分别是项目应用场景1年内的情况以及放大到10年内的提交次数,在序列化到redis之后,却发现countminSketch没有任何变化,原先我还觉得这数据结构这么厉害,结果打开数据一看,什么都没有,这可能也正是json序列化与jdk序列化的区别吧,而且在这次测试中hash在时间消耗上差距并不大,所以选用了hash
每个serialVersionUID都是静态且final修饰,而且他们也不会被GC所清理,而且消耗空间也不会特别大,除非类爆炸现象,可能当时我没注意听,不然这个现象不可能是一个软件测试的问题,对了有必要的话,还是保留着,毕竟难免可能之后会用到
最后再提一嘴像那些dto什么的以及vo什么的就不需要了,因为你根本不会用到把他们当做一个对象传