MyBatis-Plus中Page.records默认值引发的序列化问题解析

问题背景

在使用MyBatis-Plus进行分页查询时，Page对象的records字段默认被初始化为Collections.emptyList()。这个设计在大多数情况下工作良好，但在某些特定场景下可能会引发问题。

问题现象

当开发者使用Dubbo进行跨服务调用，并且使用fastjson2进行序列化/反序列化时，如果Page对象中的records字段保持默认的空列表状态，在反序列化过程中可能会抛出UnsupportedOperationException异常。

技术分析

1. 默认值设计

MyBatis-Plus中Page类的records字段默认被设置为Collections.emptyList()，这是一个不可变(immutable)的空列表实现。这种设计有以下优点：

• 节省内存，所有空列表共享同一个实例
• 避免不必要的对象创建
• 明确表示这是一个不可修改的列表

2. 问题根源

问题出现在fastjson2的反序列化过程中。当fastjson2尝试反序列化Page对象时，它会尝试使用List.add()方法向records列表中添加元素。由于Collections.emptyList()是不可变列表，任何修改操作都会抛出UnsupportedOperationException。

3. 复现条件

这个问题需要同时满足以下条件才会出现：

1. 使用Dubbo进行跨服务调用
2. 使用fastjson2作为序列化工具
3. Page对象的records字段保持默认值(空列表)
4. 反序列化时尝试修改records列表

解决方案探讨

方案1: 修改MyBatis-Plus默认值

将Page.records的默认值从Collections.emptyList()改为new ArrayList<>()。这种修改可以：

• 避免反序列化时的异常
• 保持列表的可修改性

但需要考虑的副作用：

• 每次创建Page对象都会新建一个ArrayList实例
• 可能影响现有依赖于不可变列表特性的代码

方案2: 升级fastjson2

fastjson2的最新版本可能已经修复了这个问题。开发者可以尝试升级到最新版本，看是否能解决序列化问题。

方案3: 自定义Page实现

开发者可以创建自己的Page子类，覆盖默认的records字段初始化逻辑，根据实际需求选择合适的列表实现。

最佳实践建议

1. 对于需要跨服务传输的Page对象，建议在服务边界处进行转换，使用可修改的列表实现
2. 考虑使用DTO模式，避免直接传输MyBatis-Plus的内部数据结构
3. 如果性能不是关键因素，可以使用new ArrayList<>()作为默认值来避免潜在问题

总结

MyBatis-Plus中Page.records默认值的设计在大多数情况下是合理且高效的，但在特定的序列化场景下可能会引发问题。开发者需要根据实际应用场景选择合适的解决方案，权衡性能、安全性和兼容性等因素。理解这些底层机制有助于开发者更好地使用MyBatis-Plus框架，并避免潜在的问题。