前言

今天在测试环境上遇到这个问题，但是本地无法模拟出来这个问题，且网上解决办法完全不可参考，因此留下此文帮助不知所错的各位小伙伴们。本文涉及到的代码皆是伪码，涉及到的类也都是临时举例所用，只是提供一个追查类似问题的思路。首先当然要说一下，这个原因大概率还是Spring-JPA的@ManyToOne的注解的引发，网上有大把的关于如何强制持久化的例子，但是大部分都是告诉大家直接使用@ManyToOne(cascade = {CascadeType.PERSIST,CascadeType.MERGE})设置就好，虽然未必能好，这点不过多的评论。如果能解决读者遇到的问题，祝贺你，可以右上点X了。本文主要还是想提供一个追查问题的思路。

起因

问题的起因是一个校验需求，需求很简单，只是给前台的传递的数据进行一个后端校验，完全没有入库操作，但是却在测试环境遇到这样一个报错。

Caused by: org.hibernate.TransientPropertyValueException: object references an unsaved transient instance - 
save the transient instance before flushing : com.xxx.domain.School.teacher -> com.xxx.domain.Teacher

排查

首先对这个错误进行分析，多方查找该问题是保存数据的时候发现了游离态的对象导致的，于是按照这个思路进行排查。此时开始一步一步的排查：
检查代码：出现异常首先就是想到是否是个人提交的代码引发了潜在的bug，仔细排查代码发现并不存在这样的问题，但异常依旧。
回滚代码：回滚代码发现报错依然存在，此时稍微安心了一些，但是问题却时有时无，并不能保证是一个可用的状态。
定位异常：根据异常提示的位置，定位到保存Teacher的最上层位置，打上log，发布测试环境继续测试。

School school=new School();
//逻辑
Teacher teacher=teacherRepository.getOne(teacherId);
logger.info(school.toString());
school.setTeacher(teacher);
//逻辑
schoolRepository.save(school);

最终发现输出的结果teacher对象查找出来的结果{id=0}，也就是说方法getOne查出来的这个teacher对象被JAP当作一个新对象构建了。于是JPA认为这个查询出来的teacher是new出来的游离态数据。最终在测试库中发现确实有一条{id=0}的数据污染了库引发了这个问题。此时距离遇到这个问题经过了一整天，眼睛都要看瞎了。

解决

删除这个错误行，代码顺利走下去了。这点其实也给了我不少的提示：当代码异常的时候，未必就是代码的问题，也许是数据的问题。看待一个未知的问题时要多打log，多方考虑分析情况，减少时间的浪费。