一次JPA联表查询,竟让我服务器无限循环崩溃?!

2025-12-12 0 282

那天晚上,我正窝在电脑前写 Spring Boot 项目,耳机里放着轻音乐,猫趴在键盘旁边。

一切看似岁月静好,直到我敲下一个 innocently 的 JPA 查询语句:

刷新接口,准备看返回的 JSON,结果浏览器直接——炸了。

没错,页面疯狂刷新、日志滚屏,最后 Eclipse 哭着给我抛了一个熟悉又讨厌的错误:

那一刻,我整个人都不好了。“这……是我写错了吗?我只是查个表啊!”

那场“无限递归”的噩梦

事情要从我的实体类说起。那时我定义了两个表:User 和 Department。

  • 每个用户属于一个部门;
  • 每个部门有多个用户。

于是我很自然地写了这样的实体:

是不是看起来很正常?我信心满满地执行了 userRepository.findAll()。然后就触发了那场“无限递归”的地狱循环。

原因很简单:

  • User 中的 Department 包含 users;
  • Department 又返回 User;
  • User 又嵌套 Department;
  • 就这样,一层套一层,递归到天荒地老。

Spring 序列化 JSON 时,根本停不下来,直到栈爆了。

遇见“温柔”的 @JsonBackReference

我苦思冥想,直到看到一个答案上写着:

我试了试。

在 User 里加上:

在 Department 里加上:

我重启项目,再次调用接口~哇!终于不炸了!结果只显示了:

而不是无限嵌套的“俄罗斯套娃”。

那一刻,我感动得差点给 @JsonBackReference 立个牌位。

那么 @JsonManagedReference 和 @JsonBackReference 究竟干嘛的?

其实它俩就像一对恋人:

  • @JsonManagedReference:是“正向”一方,告诉 Jackson:“你可以序列化我!”
  • @JsonBackReference:是“反向”一方,告诉 Jackson:“我别参与序列化,否则会无限循环!”

这对注解常用于 双向关联(bidirectional relationship) 的场景。

举个例子:

  • 一个部门下有很多员工;
  • 员工反向指向部门。

如果都序列化,就死循环。加上这两个注解后,Jackson 就知道该“止步”了。

那 @JSONField(serialize = false) 又是啥?

当我以为事情就这么结束时,另一个坑又出现了。

项目里某个模块用的是 FastJSON 库,而不是 Jackson。我重新跑接口,发现——递归又回来了!因为 FastJSON 并不识别 @JsonBackReference。

于是我又查资料,发现 FastJSON 的对应解决方案是:

意思是:

我赶紧在 User 类上加上:

问题又一次解决了!

Json 序列化背后的真相

我后来想了很久,其实问题的根本原因不是注解本身,而是JPA 的双向关系JSON 的树形结构之间的“理念冲突”:

当 JPA 在内存里维护“相互引用”时,Jackson/FastJSON 却只能线性地展开。于是,注解其实是让两者“和平共处”的调节器。

实战:Spring JPA 联表查询 + 注解完美配合

举个最常见的例子:

我们要查询一个部门的所有员工。

如果没加注解,这个接口直接会炸掉。但如果你的 Department 类里是这样写的:

User 类里是这样写的:

那查询结果就会完美输出:

没有递归,没有爆栈,干净利落。

常见误区:你可能犯过这些错

误区一:只加一边的注解

很多人只在 User 上加 @JsonBackReference,结果 Department 输出不了用户列表。其实要配对使用,一对组合才能互相识别

误区二:混用懵圈

如果你同时用了 FastJSON 和 Jackson,结果可能完全反着来。解决办法:

  • 如果项目使用 Spring Boot 默认的 Jackson,只用 @JsonBackReference;
  • 如果使用 FastJSON,就用 @JSONField(serialize = false);
  • 如果不确定,就两个都加。

误区三:以为 @Transient 能解决

@Transient 会直接让字段在 JPA 层忽略,根本查不到数据。别搞混。

给刚入坑的同学一个建议

很多人学 JPA 时,都只关注 CRUD,但实际上——

尤其是当你第一次在项目里写出这种查询:

却发现接口报错、序列化卡死,那一刻,你就会明白:

后记:@JsonBackReference 的温柔与克制

写到这里,我忍不住有点感慨。

@JsonBackReference 像极了一个在关系中学会克制的人。它不是不爱,而是知道——

它静静地站在反向引用那一边,说:

程序世界,也有温柔与边界。总结

最后,我们把今天的知识点捋一捋:

END

Spring JPA 的联表查询其实并不可怕,可怕的是我们对“关系”的不了解。

就像现实世界的情感一样,每一段关系都需要有“界限”——

下次当你遇到 JSON 无限递归时,记得微笑着给 @JsonBackReference 一个拥抱。

因为那一刻,它不是让你少了点什么,而是帮你挽救了整个系统。

我是小米,一个喜欢分享技术的31岁程序员。如果你喜欢我的文章,欢迎关注我的微信公众号“软件求生”,获取更多技术干货!

收藏 (0) 打赏

感谢您的支持,我会继续努力的!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

申明:本文由第三方发布,内容仅代表作者观点,与本网站无关。对本文以及其中全部或者部分内容的真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。本网发布或转载文章出于传递更多信息之目的,并不意味着赞同其观点或证实其描述,也不代表本网对其真实性负责。

左子网 编程相关 一次JPA联表查询,竟让我服务器无限循环崩溃?! https://www.zuozi.net/35688.html

常见问题
  • 1、自动:拍下后,点击(下载)链接即可下载;2、手动:拍下后,联系卖家发放即可或者联系官方找开发者发货。
查看详情
  • 1、源码默认交易周期:手动发货商品为1-3天,并且用户付款金额将会进入平台担保直到交易完成或者3-7天即可发放,如遇纠纷无限期延长收款金额直至纠纷解决或者退款!;
查看详情
  • 1、描述:源码描述(含标题)与实际源码不一致的(例:货不对板); 2、演示:有演示站时,与实际源码小于95%一致的(但描述中有”不保证完全一样、有变化的可能性”类似显著声明的除外); 3、发货:不发货可无理由退款; 4、安装:免费提供安装服务的源码但卖家不履行的; 5、收费:价格虚标,额外收取其他费用的(但描述中有显著声明或双方交易前有商定的除外); 6、其他:如质量方面的硬性常规问题BUG等。 注:经核实符合上述任一,均支持退款,但卖家予以积极解决问题则除外。
查看详情
  • 1、左子会对双方交易的过程及交易商品的快照进行永久存档,以确保交易的真实、有效、安全! 2、左子无法对如“永久包更新”、“永久技术支持”等类似交易之后的商家承诺做担保,请买家自行鉴别; 3、在源码同时有网站演示与图片演示,且站演与图演不一致时,默认按图演作为纠纷评判依据(特别声明或有商定除外); 4、在没有”无任何正当退款依据”的前提下,商品写有”一旦售出,概不支持退款”等类似的声明,视为无效声明; 5、在未拍下前,双方在QQ上所商定的交易内容,亦可成为纠纷评判依据(商定与描述冲突时,商定为准); 6、因聊天记录可作为纠纷评判依据,故双方联系时,只与对方在左子上所留的QQ、手机号沟通,以防对方不承认自我承诺。 7、虽然交易产生纠纷的几率很小,但一定要保留如聊天记录、手机短信等这样的重要信息,以防产生纠纷时便于左子介入快速处理。
查看详情

相关文章

猜你喜欢
发表评论
暂无评论
官方客服团队

为您解决烦忧 - 24小时在线 专业服务