案例：接口返回结果序列化耗时过长

近期开发任务中，有一项是开发一个接口，将出现在多个挂载位置的机器搜索出来，将挂载生效节点和失效节点区分开，同时要支持节点生效状态的可配置化。

本人的解决办法是将机器的唯一标识做一个key，将节点的路径作为valuelist构造出一个数据结构，同时给出节点生效状态、生效状态改变的时间、改变人等字段，最终的构造的结果模型为：List<Map<String, Model>>

Model类里面大致是：

String processor，Date processTime，List<String> effectiveNodeList，List<String> invalidNodeList

后台总的数据量是2w+4w左右，多挂载的机器数量级是1w内，后台会经过多挂载计算、同一机器多路径搜寻、数据模型构造等操作。

功能上线后发现有一个节点多挂载机器量达到800，返回的数据量大概是800KB，整个接口响应到最终数据返回的时间是20s。起初以为是后台计算性能不优，导致返回结果慢，打日志发现后台实际处理时间是700ms-800ms，与实际结果相差非常大；转变排查方式，觉得是nginx转发的时候做了限速，经过对ng文件的排查，发现数据从返回给ng的时候就已经是20s；后面灵光一闪，怀疑是返回的模型序列化为json串的时候耗时太长，在测试环境找了一个大约200台多挂载机器的节点，使用fastjson直接将结果模型序列化为String，后台处理数据耗时是500ms，序列化的耗时是5000ms，也就是5s，到这里基本确定是序列化的问题。

问题的解决靠同组另一位老哥的经验，使用Gson做了一下序列化测试，测试环境耗时只需20ms，后面就改为使用Gson序列化直接返回String类型，至于改用了Gson后续是否在这块会有隐藏的坑，等我慢慢踩，强烈希望没有。