如果一个对象与另一个对象之间存在互相引用(bi-directional relationship)，序列化该对象就会出现stackoverflow异常，这篇文章主要介绍使用jackson序列化工具处理该问题的几种解决方案。

一.Infinite Recursion

首先不要被文章标题所误导，该问题并不是因为使用了jpa/hibernate的双向关联关系才会出现，简书上这篇文章说该异常根本原因在于hibernate的lazyload，我认为是一本正经的胡说八道，先来看一个简单的例子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public class Customer {
    private Long id;
    private List<Card> cardList;
    //constructor getter setter...
}
public class Card {
    private Long id;
    private Customer customer;
    //constructor getter setter...
}
//测试环境 junit, assertj
public class CustomerTest {
    @Test
    public void serialize() throws Exception {
        Customer customer = new Customer();
        Card card = new Card();
        //相互引用
        card.setCustomer(customer);
        customer.addCard(card);
        ObjectMapper objectMapper = new ObjectMapper();
        Assertions.assertThatThrownBy(() -> objectMapper.writeValueAsString(customer))
                .hasMessageStartingWith("Infinite recursion (StackOverflowError)");
    }
}

上例中消费者与信用卡之间存在双向的一对多关系，序列化其中任意一个对象都会导致StackOverflowError，换句话说只要两个对象之间存在互相引用，就无法直接序列化，即便是在js中也不例外，看代码:

1
2
3
4
5
6
7
8
9
10
11
//测试环境 mocha,shouldjs
var should = require('should');
describe('json', function () {
    it('如果两个对象互相引用,则无法直接序列化', function () {
        var foo = {};
        var bar = {};
        foo.bar = bar;
        bar.foo = foo;
        should(function(){ JSON.stringify(foo);}).throw('Converting circular structure to JSON');
    });
});

综上所述，这锅hibernate不接。问题介绍完毕，下面来看看当前热门的序列化工具jackson提供了哪些方法来处理该问题，以下讨论的方法截至jackson2.8.4版本。

二.@JsonIgnore

应用JsonIgnore注解后，代码看起来像这样

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class Customer {
    private Long id;
    private List<Card> cardList;
    //constructor getter setter...
}
public class Card {
    private Long id;
    @JsonIgnore
    private Customer customer;
    //constructor getter setter...
}
//serialize customer, result should like
// {
//     "id": 1,
//     "cardList": [
//         {
//             "id": 1
//         }
//     ]
// }

该注解忽略card对象的customer属性，从而避免了无限递归的问题。需要说明的是JsonIgnore注解的设计初衷并不是用于解决该问题，但由于该方法简单粗暴易于理解，因此相当一部分程序员还是选择了该方法。下面说说我不推荐使用的理由:

  1. 使用了该注解后，如果你希望单独序列化一个card对象，那么json的接收端无法得知关于customer的任何信息
  2. 当服务端接受到客户端发送过来的json字符串，并希望反序列化为card对象时，其customer属性永远为null

换言之，当你感觉某个属性需要使用JsonIgnore注解的时候，你应该先考虑是否可以直接删除该属性。拿上面的例子来说，也许你需要的只是在Card类中删除customer属性。JsonIgnore属性正确的应用场景应该是实体中类似于createAt,updateAt这样的字段，这些字段仅由服务端维护，且不需要发送至客户端，(注：password字段也不应该使用该注解，应该使用@JsonProperty(access = JsonProperty.Access.WRITE_ONLY)，因为你可能希望接受客户端发送的password)

三.@JsonManagedReference与@JsonBackReference

使用该方法后，代码看起来像这样

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public class Customer {
    private Long id;
    @JsonManagedReference("customer-card") //当一个类中存在多个@JsonManagedReference注解时，其value值才是必须的
    private List<Card> cardList;
    //constructor getter setter...
}
public class Card {
    private Long id;
    @JsonBackReference("customer-card") //同上
    private Customer customer;
    //constructor getter setter...
}
//serialize customer, result should like
// {
//     "id": 1,
//     "cardList": [
//         {
//             "id": 1
//         }
//     ]
// }

@JsonManagedReference与@JsonBackReference生来就是为了解决Infinite Recursion问题。它与@JsonIgnore最大的不同在于反序列化时，标注JsonIgnore注解的属性始终为null，而使用这对注解的反序列化结果为两个互相引用的对象。然而这对注解同样不推荐使用，以下是原因:

  1. 相信你也看到了，它的序列化结果与使用@JsonIgnore一模一样，当你需要单独序列化card对象时，Json接收端无法知道该card属于哪个customer。
  2. JsonBackReference只能使用在一对多关系中"一"的一端，这意味着当你有Card与CardCategory两个类时，关系的维护端在CardCategory类，序列化信用卡类别可以得到该类别的所有信用卡，而序列化信用卡却无法得到该信用卡的类别，这显然不是你想要的。

综上所述，然并卵。

四.@JsonIdentityInfo

使用该方法后，代码看起来像这样

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
@JsonIdentityInfo(generator = ObjectIdGenerators.PropertyGenerator.class, property = "id", scope = Customer.class)
public class Customer {
    private Long id;
    private List<Card> cardList;
    //constructor getter setter...
}
@JsonIdentityInfo(generator = ObjectIdGenerators.PropertyGenerator.class, property = "id", scope = Card.class)
public class Card {
    private Long id;
    private Customer customer;
    //constructor getter setter...
}
//为了更好的演示该注解，我在customer对象中添加了两张card
//serialize customer, result should like
// {
//     "id": 1,
//     "cardList": [
//         {
//             "id": 1,
//             "customer": 1
//         },
//         {
//             "id": 2,
//             "customer": 1
//         }
//     ]
// }

效果简直完美，当该注解检测到本次序列化中有重复对象时，使用指定的生成器生成一个替代对象(上例中的id)，序列化card对象不会丢失customer信息，反序列化时能够完整的将对象恢复到序列化前的状态，顺便完美的规避的数据冗余，看上去非常美好。（注：要开始装B了！）但是通信原理告诉我们，数据格式的信息冗余度越低，则对其编解码需求的运算量越大，同时在信息传输过程中，越容易受到噪声干扰而失真(参见香农信息论与回答老鼠喝药问题的正确姿势)。（注：装B结束！）下面是应用了该注解后，序列化customer.cardList的结果:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
// 理想
[
    {
        "id": 1,
        "customer": {
            "id": 1,
            "cardList": [1, 2]
        }
    },
    {
        "id": 2,
        "customer": {
            "id": 1,
            "cardList": [1, 2]
        }
    }
]
// 现实(WTF)
[
    {
        "id": 1,
        "customer": {
            "id": 1,
            "cardList": [
                1,
                {
                    "id": 2,
                    "customer": 1
                }
            ]
        }
    },
    2
]

从上面惨不忍睹的现实中可以看出，jackson序列化对象时使用深度优先遍历(Depth-first-traversal)，在card1.customer.cardList中写入了card2的信息，后面出现的card2则被替换成其id。也许你会说丑是丑了点，但信息量并没有减少，在json的接收端经过一些特殊处理依然可以将其反序列化至原来的状态。这也正如我前面所说的，该方法增加了编码与解码所需的运算量，这意味着你可能需要为该注解引入额外的libarary来进行序列化与反序列化（例如JSOG），考虑到json的接收端可能是各种平台(android,ios,web)，因此该方案的实用性依然非常有限。

五.@JsonView

使用该方法后，代码看起来像这样

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
public class Customer {
    public interface CustomerWithCard{}
    @JsonView({CustomerWithCard.class, Card.CardWithCustomer.class})
    private Long id;
    @JsonView(CustomerWithCard.class)
    private List<Card> cardList;
    //constructor getter setter...
}
public class Card {
    public interface CardWithCustomer{}
    @JsonView({Customer.CustomerWithCard.class, CardWithCustomer.class})
    private Long id;
    @JsonView(CardWithCustomer.class)
    private Customer customer;
    //constructor getter setter...
}
public class CustomerTest {
    @Test
    public void serialize() throws Exception {
        Customer customer1 = new Customer(1L);
        Card card1 = new Card(1L, customer1);
        Card card2 = new Card(2L, customer1);
        customer1.addCard(card1);
        customer1.addCard(card2);
        List<Card> list = Arrays.asList(card1, card2);
        ObjectMapper objectMapper = new ObjectMapper();
        //序列化时不包括没有@JsonView注解的属性
        objectMapper.configure(MapperFeature.DEFAULT_VIEW_INCLUSION, false);
        //序列化需要先指定View
        Assertions.assertThat(objectMapper.writerWithView(Customer.CustomerWithCard.class).writeValueAsString(customer))
                .isNotEmpty();
        Assertions.assertThat(objectMapper.writerWithView(Card.CardWithCustomer.class).writeValueAsString(list))
                .isNotEmpty();
    }
}

下面是序列化的结果

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
//serialize customer use CustomerWithCard view
{
    "id": 1,
    "cardList": [
        {
            "id": 1
        },
        {
            "id": 2
        }
    ]
}
//serialize card use CardWithCustomer view
[
    {
        "id": 1,
        "customer": {
            "id": 1
        }
    },
    {
        "id": 2,
        "customer": {
            "id": 1
        }
    }
]

这种方法的缺点是配置麻烦了一些，但总算勉强能用，下面顺带提一下如何在springmvc(4.3.4版本)中使用该方法，使用了该方法的controller看起来像这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
@RestController
@RequestMapping(value = "/api", produces = MediaType.APPLICATION_JSON_UTF8_VALUE)
public class CustomerController {
    private CustomerService customerService;
    public CustomerController(CustomerService customerService) {
        this.customerService = customerService;
    }
    @GetMapping("/customer/{id}")
    @JsonView(Customer.CustomerWithCard.class)
    public Customer getCustomerById(@PathVariable Long id){
        return customerService.findById(id);
    }
    @GetMapping("/customer/{customerId}/card")
    @JsonView(Card.CardWithCustomer.class)
    public List<Card> listCardByCustomerId(@PathVariable Long customerId){
        return customerService.listCardByCustomerId(customerId);
    }
    @GetMapping("/customer/{customerId}/card")
    @JsonView(Card.CardWithCustomer.class)
    public Page<Card> listCardByCustomerIdWithPage(@PathVariable Long customerId, Pageable pageable){
        return customerService.listCardByCustomerIdWithPage(customerId, pageable);
    }
}

需要注意的是springmvc默认配置MapperFeature.DEFAULT_VIEW_INCLUSION为false，因此如果你在控制器方法上指定了要返回的JsonView，返回的实体类中所有没有该JsonView注解的属性都不会被序列化，这往往正是我们需要的效果，然而也正因为如此，上面代码中带物理分页的listCardByCustomerIdWithPage方法只会返回空对象，因为spring data的PageImpl类中的属性是没有JsonView注解的，我们还需要针对它做一些额外的配置，代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
/**
 * 用于解决使用json view,并且 MapperFeature.DEFAULT_VIEW_INCLUSION 为false的情况下
 * spring data的page对象无法正确序列化的问题
 * @return
 */
@Bean
public Module springDataPageModule() {
    return new SimpleModule().addSerializer(Page.class, new JsonSerializer<Page>() {
        @Override
        public void serialize(Page page, JsonGenerator gen, SerializerProvider serializers) throws IOException {
            gen.writeStartObject();
            gen.writeFieldName("size");
            gen.writeNumber(page.getSize());
            gen.writeFieldName("number");
            gen.writeNumber(page.getNumber());
            gen.writeFieldName("totalElements");
            gen.writeNumber(page.getTotalElements());
            gen.writeFieldName("last");
            gen.writeBoolean(page.isLast());
            gen.writeFieldName("totalPages");
            gen.writeNumber(page.getTotalPages());
            gen.writeObjectField("sort", page.getSort());
            gen.writeFieldName("first");
            gen.writeBoolean(page.isFirst());
            gen.writeFieldName("numberOfElements");
            gen.writeNumber(page.getNumberOfElements());
            gen.writeFieldName("content");
            serializers.defaultSerializeValue(page.getContent(),gen);
            gen.writeEndObject();
        }
    });
}

六.Conclusion

以上每种方法都有各自的弊端。推荐使用者优先考虑后两种方案。如果我对以上方法的理解存在偏差，或者有人对于该问题有更好的解决方案，欢迎与我讨论。

参考链接：