Spring Boot微服务中特定JPA/Hibernate表重复存储问题排查

一、先排查Hibernate相关配置问题 #

• 检查实体类主键配置：确认这两张表的实体@Id注解的生成策略是否正确。比如用GenerationType.IDENTITY时，数据库表的主键是否真的是自增类型；如果用GenerationType.SEQUENCE，序列配置是否在多实例环境下正常工作，会不会出现序列重复分配的情况。
• 验证equals()和hashCode()实现：这两个方法如果依赖了未持久化的外键字段，或者逻辑错误，会导致Hibernate的Session缓存无法识别重复实体，进而触发多次插入。对比其他无问题表的实体实现，看有没有差异。
• 核对事务边界：检查这两张表的持久化操作是否处于正确的事务中。比如是否误用了PROPAGATION_REQUIRES_NEW传播行为，导致每次调用都开启新事务；或者事务未正确提交/回滚，引发重复执行。

二、结合K8s多实例环境的特殊排查点 #

• 排查请求幂等性：K8s环境的负载均衡、网关或客户端可能存在超时重试机制，同一请求被多次分发到不同实例执行。如果这两张表对应的接口没做幂等处理（比如没加请求唯一标识校验），就会产生重复记录——其他表可能因为有业务唯一约束（比如联合索引）挡住了重复插入，而这两张表恰好缺失。
• 检查分布式事务逻辑：如果这两张表的操作涉及跨服务调用或分布式事务，K8s环境下的网络波动可能导致事务补偿机制重复触发，进而重复插入数据。
• 补全数据库唯一约束：先给这两张表添加业务层面的唯一索引（比如外键字段+核心业务字段的组合），这样即使代码层面有问题，数据库也会抛出异常，快速定位重复插入的触发场景。

三、针对“非循环代码却多次持久化”的针对性排查 #

• 检查AOP切面/全局拦截器：有没有全局的日志、监控或事务切面，不小心重复调用了持久化方法？比如切面逻辑错误地嵌套执行了save操作。
• 查看Spring事件监听：如果实体类发布了生命周期事件（比如@PostPersist），有没有监听器再次触发了持久化逻辑？
• 打印调用栈跟踪：在这两张表的save方法处添加调试日志，打印当前线程的调用栈：

  logger.debug("触发持久化，调用栈: {}", Arrays.toString(Thread.currentThread().getStackTrace()));
  

  下次出现问题时，通过日志就能明确是哪里重复调用了持久化操作。

四、复现问题的实用技巧 #

• 开启详细日志：在DEV环境临时开启Hibernate的SQL日志和统计日志：

  spring.jpa.show-sql=true
  spring.jpa.properties.hibernate.format_sql=true
  spring.jpa.properties.hibernate.generate_statistics=true
  

  这样能清晰看到插入SQL的执行次数、时机和Session的操作统计。
• 模拟高并发：用JMeter或Locust工具对目标接口压测，同时观察数据库插入情况，大概率能触发偶发的重复问题。

内容的提问来源于stack exchange，提问作者jashan khangura