我们在开发项目中，会经常根据不同的业务设计出不同的实体关联关系表，用到的最多的就是一对多，多对一，大部分用到的都是单向关联。在这里，我们要解决双向关联查询数据出现死循环、栈溢出的问题。
我就用项目中的实体关系（表）举例说明了：
定义两张表（task_info,track_info）分别对应的实体类为：TaskInfo、TrackInfo，它们的关系是一对多，多对一双向关联，
一个任务中有多个任务的追踪信息，同时追踪信息中又能根据外键关联到任务的信息
@Entity
@EntityListeners(AuditingEntityListener.class)
@Data
@Table(name ="scrm_clue_task_info")
public class TaskInfo {
/**
* 主键Id，自动生成
*/
@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 {
@Id
@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方法
在调用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
如果你在前台需要返回另一方的结果集，也需要加上此注解：
@JsonIgnoreProperties(value = {"taskInfo"})
@ManyToOne(fetch = FetchType.LAZY)
private TaskInfo taskInfo;
这样的话得出的结果是taskInfo对象中有trackInfoList，而trackInfoList中不会对taskInfo重复引用，我们看一下结果：
{
"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
}
大家可能会说，为什么不在属性上使用@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");
}
return trackInfoList;
网友评论