淺析 SpringMVC 中返回對象的循環引用問題
本文轉載自微信公眾號「Kirito的技術分享」，作者kiritomoe 。轉載本文請聯系Kirito的技術分享公眾號。
問題發現
今天這個話題還是比較輕松的，可能很多朋友也都遇到過這個問題。
@RestController、@ResponseBody 等注解是我們在寫 Web 應用時打交道最多的注解了，我們經常有這樣的需求：返回一個對象給前端，SpringMVC 幫助我們序列化成 JSON 對象。而今天我要分享的話題也不是什么高深的內容，那就是返回對象中存在循環引用時問題的探討。
該問題非常簡單容易復現，直接上代碼。
準備兩個存在循環引用的對象：
- @Data
- public class Person {
- private String name;
- private IdCard idCard;
- }
- @Data
- public class IdCard {
- private String id;
- private Person person;
- }
在 SpringMVC 的 controller 中直接返回存在循環引用的對象：
- @RestController
- public class HelloController {
- @RequestMapping("/hello")
- public Person hello() {
- Person person = new Person();
- person.setName("kirito");
- IdCard idCard = new IdCard();
- idCard.setId("xxx19950102xxx");
- person.setIdCard(idCard);
- idCard.setPerson(person);
- return person;
- }
- }
執行 curl localhost:8080/hello 發現，直接報了一個 StackOverFlowError：
StackOverFlow
問題剖析
不難理解這中間發生了什么，從堆棧和常識中都應當了解到一個事實，SpringMVC 默認使用了 jackson 作為 HttpMessageConverter，這樣當我們返回對象時，會經過 jackson 的 serializer 序列化成 json 串，而另一個事實便是 jackson 是無法解析 java 中的循環引用的，套娃式的解析，最終導致了 StackOverFlowError。
有人會說，為什么你會有循環引用呢?天知道業務場景有多奇葩，既然 Java 沒有限制循環引用的存在，那就肯定會有某一合理的場景存在該可能性，如果你在線上的一個接口一直平穩運行著，知道有一天，碰到了一個包含循環引用的對象，你看著打印出來的 StackOverFlowError 的堆棧，開始懷疑人生，是哪個小(大)可(S)愛(B)干的這種事!
我們先假設循環引用存在的合理性，如何解決該問題呢?最簡單的解法：單向維護關聯，參考 Hibernate 中的 OneToMany 關聯中單向映射的思想，這需要干掉 IdCard 中的 Person 成員變量。或者，借助于 jackson 提供的注解，指定忽略循環引用的字段，例如這樣：
- @Data
- public class IdCard {
- private String id;
- @JsonIgnore
- private Person person;
- }
當然，我也翻閱了一些資料，嘗試尋求 jackson 更優雅的解決方式，例如這兩個注解：
- @JsonManagedReference
- @JsonBackReference
但在我看來，似乎他們并沒有什么大用場。
當然，你如果不嫌棄經常出安全漏洞的 fastjson，也可以選擇使用 FastJsonHttpMessageConverter 替換掉 jackson 的默認實現，像下面這樣：
- @Bean
- public HttpMessageConverters fastJsonHttpMessageConverters() {
- //1、定義一個convert轉換消息的對象
- FastJsonHttpMessageConverter fastConverter = new FastJsonHttpMessageConverter();
- //2、添加fastjson的配置信息
- FastJsonConfig fastJsonConfig = new FastJsonConfig();
- SerializerFeature[] serializerFeatures = new SerializerFeature[]{
- // 輸出key是包含雙引號
- // SerializerFeature.QuoteFieldNames,
- // 是否輸出為null的字段,若為null 則顯示該字段
- // SerializerFeature.WriteMapNullValue,
- // 數值字段如果為null，則輸出為0
- SerializerFeature.WriteNullNumberAsZero,
- // List字段如果為null,輸出為[],而非null
- SerializerFeature.WriteNullListAsEmpty,
- // 字符類型字段如果為null,輸出為"",而非null
- SerializerFeature.WriteNullStringAsEmpty,
- // Boolean字段如果為null,輸出為false,而非null
- SerializerFeature.WriteNullBooleanAsFalse,
- // Date的日期轉換器
- SerializerFeature.WriteDateUseDateFormat,
- // 循環引用
- //SerializerFeature.DisableCircularReferenceDetect,
- };
- fastJsonConfig.setSerializerFeatures(serializerFeatures);
- fastJsonConfig.setCharset(Charset.forName("UTF-8"));
- //3、在convert中添加配置信息
- fastConverter.setFastJsonConfig(fastJsonConfig);
- //4、將convert添加到converters中
- HttpMessageConverter<?> converter = fastConverter;
- return new HttpMessageConverters(converter);
- }
你可以自定義一些 json 轉換時的 feature，當然我今天主要關注 SerializerFeature.DisableCircularReferenceDetect 這一屬性，只要不顯示開啟該特性，fastjson 默認就能處理循環引用的問題。
如上配置后，讓我們看看效果：
- {"idCard":{"id":"xxx19950102xxx","person":{"$ref":".."}},"name":"kirito"}
已經正常返回了，fastjson 使用了"$ref":".." 這樣的標識，解決了循環引用的問題，如果繼續使用 fastjson 反序列化，依舊可以解析成同一對象，其實我在之前的文章中已經介紹過這一特性了《gson 替換 fastjson 引發的線上問題分析》。
使用 FastJsonHttpMessageConverter 可以徹底規避掉循環引用的問題，這對于返回類型不固定的場景十分有幫助，而 @JsonIgnore 只能作用于那些固定結構的循環引用對象上。
問題思考
值得一提的是，為什么一般標準的 JSON 類庫并沒有如此關注循環引用的問題呢?fastjson 看起來反而是個特例，我覺得主要還是 JSON 這種序列化的格式就是為了通用而存在的，$ref 這樣的契約信息，并沒有被 JSON 的規范去定義，fastjson 可以確保 $ref 在序列化、反序列化時能夠正常解析，但如果是跨框架、跨系統、跨語言等場景，這一切都是個未知數了。說到底，這還是 Java 語言的循環引用和 JSON 通用規范不包含這一概念之間的 gap(可能 JSON 規范描述了這一特性，但我沒有找到，如有問題，煩請指正)。
我到底應該選擇 @JsonIgnore 還是使用 FastJsonHttpMessageConverter 呢?經歷了上面的思考，我覺得各位看官應該能夠根據自己的場景選擇合適的方案了。
總結下，如果選擇 FastJsonHttpMessageConverter ，改動較大，如果有較多的存量接口，建議做好回歸，以確認解決循環引用問題的同時，別引入了其他不兼容的改動。并且，需要基于你的使用場景評估方案，如果出現了循環引用，fastjson 會使用 $ref 來記錄引用信息，請確認你的前端或者接口方能夠識別該信息，因為這可能并不是標準的 JSON 規范。你也可以選擇 @JsonIgnore 來實現最小改動，但也同時需要注意，如果根據序列化的結果再次反序列化，引用信息可不會自動恢復。
