MyBatis-Flex 实体类继承与ID生成器冲突问题解析

问题背景

在使用MyBatis-Flex框架开发时，开发者经常会抽取数据库实体类的公共属性到基类中，然后让具体实体类继承这个基类。这是一种常见的面向对象设计模式，可以避免代码重复。然而，当在基类中使用MyBatis-Flex的@Id注解并指定ID生成策略时，可能会遇到类型转换异常。

问题现象

开发者定义了一个BaseEntity基类，其中包含ID字段并配置了雪花算法ID生成器：

@Id(keyType = KeyType.Generator, value = KeyGenerators.snowFlakeId)
private String id;

然后创建了SystemIpBlacklist实体类继承BaseEntity。在测试环境中，实体类的保存操作可以正常工作，但在实际服务运行时却抛出异常：

java.lang.IllegalArgumentException: object of type cloud.astrsea.framework.model.entity.mysql.SystemIpBlacklist is not an instance of cloud.astrsea.framework.model.entity.mysql.BaseEntity

问题根源

这个问题实际上是由Spring Boot的热加载机制和类加载器导致的。在Spring Boot开发环境中，当使用DevTools等热加载工具时，同一个类可能会被不同的类加载器加载多次，导致JVM认为它们是不同的类。具体表现为：

1. 基类BaseEntity被一个类加载器加载
2. 子类SystemIpBlacklist被另一个类加载器加载
3. 虽然从代码上看是继承关系，但JVM认为它们不属于同一个类层次结构

解决方案

针对这个问题，有以下几种解决方案：

方案一：禁用热加载

在正式环境中，这个问题通常不会出现，因为类只被加载一次。如果是在开发环境中遇到此问题，可以暂时禁用热加载功能进行测试。

方案二：修改ID生成策略

将ID生成策略改为不依赖生成器的方式，例如：

@Id(keyType = KeyType.Auto)
private Long id;

或者使用数据库自增：

@Id(keyType = KeyType.Auto)
private Integer id;

方案三：自定义ID生成器

如果必须使用特定的ID生成策略，可以创建一个自定义的ID生成器：

public class CustomIdGenerator implements KeyGenerator {
    @Override
    public Object generate(Object entity, String keyColumn) {
        return IdWorker.getIdStr();
    }
}

然后在实体类中使用：

@Id(keyType = KeyType.Generator, value = CustomIdGenerator.class)
private String id;

方案四：调整类加载方式

确保基类和子类被同一个类加载器加载，可以通过以下方式实现：

1. 将基类放在独立的模块中
2. 确保基类不会被重新加载
3. 在Spring Boot配置中排除特定类的热加载

最佳实践建议

1. 谨慎使用继承：在实体类设计中，除非确实需要共享大量公共字段和行为，否则考虑使用组合而非继承。

2. ID生成策略选择：根据实际业务需求选择合适的ID生成策略，优先考虑简单可靠的方案。

3. 开发环境配置：在开发环境中合理配置热加载工具，避免因类加载问题导致的奇怪错误。

4. 测试覆盖：确保测试环境尽可能模拟生产环境，包括类加载机制。

总结

MyBatis-Flex框架中实体类继承与ID生成器的冲突问题，本质上是类加载机制导致的。通过理解问题的根本原因，开发者可以选择最适合自己项目的解决方案。在大多数情况下，调整ID生成策略或优化类加载方式都能有效解决这个问题。