我们在开发项目中，会经常根据不同的业务设计出不同的实体关联关系表，用到的最多的就是一对多，多对一，大部分用到的都是单向关联。在这里，我们要解决双向关联查询数据出现死循环、栈溢出的问题。
我就用项目中的实体关系（表）举例说明了：
定义两张表（task_info,track_info）分别对应的实体类为：TaskInfo、TrackInfo，它们的关系是一对多，多对一双向关联，
一个任务中有多个任务的追踪信息，同时追踪信息中又能根据外键关联到任务的信息
@Entity @EntityListeners(AuditingEntityListener.class) @Data @Table(name ="scrm_clue_task_info") public class TaskInfo { * 主键Id，自动生成 @GeneratedValue(generator = "system-uuid") @GenericGenerator(name = "system-uuid", strategy = "uuid") private String id; @OneToMany(mappedBy ="taskInfo") private List<TrackInfo> trackInfoList;@Entity @Data @EntityListeners(AuditingEntityListener.class) @Table(name = "scrm_clue_track_info") public class TrackInfo { @GeneratedValue(generator = "system-uuid") @GenericGenerator(name = "system-uuid", strategy = "uuid") private String id; * 若不指定@JoinColumn,默认会生成：表名_id的外键字段 @ManyToOne(fetch = FetchType.LAZY) private TaskInfo taskInfo;定义Service层，查询taskInfo方法
@Slf4j @Service public class TaskManageServiceImpl implements TaskManageService { @Autowired private TaskInfoRepository taskInfoRepository; * 根据id查询任务详情 * @param id 任务id * @return 任务详情信息 @Override public TaskInfo findTaskDetail(String taskInfoId) { TaskInfo taskInfo = taskInfoRepository.getOne(taskInfoId); return taskInfo;在上面的service代码中，正常情况下通过findTaskDetail()方法可以根据任务的id（taskInfoId）查询到任务的基本信息以及关联到的任务追踪信息（trackInfoList）。但是由于我们之前设计的是双向关联关系，在调用查询方法的时候hibernate将结果查询出来并会调用set、get、tostring方法来序列化对象，会出现无限递归循环导致的tostring()堆栈溢出的错误：
Method threw 'java.lang.StackOverflowError' exception. Cannot evaluate com.markor.scrm.clue.entity.TaskInfo_$$_jvst491_7.toString()这个问题是因为在实体类上标注的lombok的@Data注解导致的，简单来说@Data注解会自动帮我们实现get、set、hashcode、equals、toString等方法。我们来看一下TaskInfo.class反编译中@Data注解自动帮我们实现的toString()方法：
public String toString() { return "TaskInfo(id=" + this.getId() + "trackInfoList=" + this.getTrackInfoList() + ")";看完上面的代码相信大家一定知道了，在查询到对象进行赋值的时候，会调用每个属性的toString()方法：
调用toString方法在调用toString()方法的时候会从taskInfo对象中获得trackInfoList，trackinfoList中又获得taskInfo，从而一直无限递归下去导致栈溢出。
解决方法：将@Data注解换成@getter、@setter方法，不让它帮我们自动重写toString()方法，或者自己覆盖掉toString()方法。
上面说了在hibernate查询对象序列化的时候，会对对象中每个属性进行get、set赋值。实际上在返回到接口调用到结果的过程中，spring会通过HttpMessageConverter<T>来实现将对象JSON序列化返回给前端。
这个时候我们将对象序列化的时候，要避免对象之间递归重复引用调用的坑！以下我列举解决三个方案来规避返回前端序列化堆栈溢出的问题：
如果你是使用spring jar包中自带的Jackson2JsonMessageConverter转换器
在属性上加入@JsonIgnoreProperties注解：此注解的意思是会忽略对象中的taskInfo属性，在这里要注意：是trackInfoList中的taskInfo属性：@JsonIgnoreProperties(value = {"taskInfo"}) @OneToMany(mappedBy = "taskInfo") private List<TrackInfo> trackInfoList如果你在前台需要返回另一方的结果集，也需要加上此注解：
"code": "0000", "data": { "id":"123", "trackInfoList": [ "createTime": "2020-02-16 17:56:15", "customerFeedBackInformation": "再激活", "deterMineEnterStore": "2020-02-11 17:42:52", "id": "8a85c6ca704d678401704d6d51230002", "isHaveWillingness": "1", "isWillAnswer": "1", "nextTrackingDate": "2020-03-16 17:56:12", "operatorName": "张亚楠", "operatorNumber": "0117498", "operatorPost": "大自然的搬运工", "taskLevel": "A" "createTime": "2020-02-14 17:34:03", "customerFeedBackInformation": "121", "deterMineEnterStore": "2020-02-11 17:42:52", "id": "8aaa43887042a17f0170430c479a0004", "isHaveWillingness": "1", "isWillAnswer": "1", "nextTrackingDate": "2020-02-20 17:42:52", "operatorName": "大自然的搬运工", "operatorNumber": "0117498", "taskLevel": "A" "message": "", "searchTime": 1581857081314, "success": true
@JsonIgnoreProperties(value = {"taskInfo"})
@ManyToOne(fetch = FetchType.LAZY)
private TaskInfo taskInfo;
这样的话得出的结果是taskInfo对象中有trackInfoList，而trackInfoList中不会对taskInfo重复引用，我们看一下结果：大家可能会说，为什么不在属性上使用@JsonIgnore注解？
在这里我要解释一下，此注解是忽略属性序列化，实际上就是Transient的意思，在哪个属性上面加，哪个属性就不会被序列化。如果在TaskInfo类中的trackInfoList属性上面加入@JsonIgnore，会导致返回的结果trackInfoList没有被序列化，trackInfoList结果为空，显然，这不是我们想要的结果。有两种方式
如果项目中使用FastJson来实现HttpMessageConverter<T>转换器，spring在序列化对象的时候会优先采用自己实现的序列化方案，所以调用序列化write方法会采用你自己实现的FastJson，而不是spring默认的Jackson2JsonMessageConverter转换器的方法。
所以在这里如果要用@JsonIgnoreProperties注解就没有作用了，因为此注解是package com.fasterxml.jackson.annotation包下的，fastjson是不会解析到的。
可以使用fastjson包下的@JSONField注解，这样可以序列化trackList属性的时候忽略“taskInfo”属性：
（1）在多的一方TrackInfo类中taskInfo属性加上@JSONField@ManyToOne(cascade = {CascadeType.ALL}, fetch = FetchType.LAZY) @JSONField(serialize = false) private TaskInfo taskInfo;（2）需要自己定制序列化方法：
@JSONField(serializeUsing = CusSerializer.class) private List<TrackInfo> trackInfoList;serializeUsing 的意思是使用自己定制的序列化方法，如果不填的话，它会默认一个类。
要定制序列化类，我们要实现ObjectSerializer类，实现write()方法：public class CusSerializer implements ObjectSerializer { @Override public void write(JSONSerializer serializer, Object object, Object fieldName, Type fieldType, int features) throws IOException { System.out.println("******进入CusSerializer序列化*******"); //注意：一定不要直接操作对象 //((List<TrackInfo>)object).forEach(o -> o.setTaskInfo(null)); //使用copy对象的方法来忽略taskInfo属性，再去序列化 List<TrackInfo> trackInfoList = BeanHelper.copyWithCollection(((List<TrackInfo>) object), TrackInfo.class, "taskInfo"); serializer.write(object);根据上面的代码，有的小伙伴们一定会对被注释掉直接操作对象的那行代码有所疑问，为什么不能使用呢？
因为：如果你在service类中调用了序列化的方法（很有可能是将对象序列化成字节，发送mq），此时对象为Persistent（持久化状态），service层在提交事务的时候，会发现属性有改变，执行update语句进行更新，这时trackInfo中关联的外键task_info_id就被更新没了，数据会有问题。在属性中定义自己实现的序列化方法，该属性就会调用此序列化方法的策略，进行序列化，结果和上图效果也是一样的。
笔者还有一种更简单粗暴的方法，在TaskInfo中重写getTrackInfoList()方法，在方法中去除重复引用。此方法是在返回给前端序列化之前，就已经执行了。换句话说：在执行完taskInfoRepository.getOne(taskInfoId);方法的时候就已经赋值调用完成了，代码如下：
public List<TrackInfo> getTrackInfoList() { System.out.println("********************进入getTrackInfoList方法******************"); if (!CollectionUtils.isEmpty(this.trackInfoList)) { return BeanHelper.copyWithCollection(this.trackInfoList,TrackInfo.class,"taskInfo");
|
|