JsonUtils案例

wen java案例 2026-08-01 235

JsonUtils终极指南——从序列化陷阱到性能优化的全场景案例解析

目录导读

为什么你需要重新认识JsonUtils？

核心方法对比：JSON.parse vs JsonUtils.convertObject (含源码级拆解)

八大高频案例实战（泛型擦除、日期格式、循环引用、动态Key映射）

性能压测数据：反射调用 vs 手写序列化,差距有多大？

常见报错问答Q&A（TypeToken失效、JSONException、BigDecimal精度丢失）

为什么你需要重新认识JsonUtils？

在Java后端开发中，JSON处理占据日常开发量的15%-20%，很多开发者依赖Jackson、Gson或Fastjson原生的toJsonString和parseObject方法，但当面对复杂泛型嵌套、多态反序列化、跨框架数据适配时，往往会写出大量冗余的转换代码，而一个封装良好的JsonUtils工具类,能帮你：

统一序列化策略（忽略null字段、驼峰/下划线自动转换）
屏蔽底层库API差异（项目从Fastjson迁移到Jackson,业务代码零改动）
内置安全防护（防空指针、防递归循环引用）

本文结合Eolink、Hutool、自研工具类等真实项目代码，带你绕过90%的JSON解析“地雷”。

核心方法对比：JSON.parse 与 JsonUtils.convertObject

典型场景：
从Redis读取一个Map<String, List<Order>>,直接用原生API：

// 原生写法（容易产生类型丢失）
Map<String, Object> map = JSON.parseObject(redisStr);
List<Order> orders = (List<Order>) map.get("weekday"); // 运行期强转异常！
// JsonUtils写法（利用TypeReference）
Map<String, List<Order>> result = JsonUtils.convertObject(redisStr, new TypeToken<Map<String, List<Order>>>(){}.getType());

底层原理差异：
JsonUtils内部会先判断目标Type是“普通Class”还是“带泛型的ParameterizedType”，如果是后者，它会强制将JSON数组解析为List<Order>而非List<LinkedHashMap>。

八大高频案例实战（重点看案例3、5、7）

案例1：泛型擦除——List 变成 List

问题症状： 反序列化后调用user.getName()报空指针。
解决： 使用JsonUtils.fromJson(json, new TypeReference<List<User>>() {}, User.class)显式传入T类进行二次转换。

案例2：日期格式“2024-08-01 10:00:00”解析失败

// 默认解析只支持ISO格式，需要自定义格式化器
JsonUtils.configGlobalDateFormat("yyyy-MM-dd HH:mm:ss");

案例3：循环引用（两个对象互相持有）

报错： StackOverflowError。
解决： 序列化时设置SerializerFeature.DisableCircularReferenceDetect；反序列化时改用@JSONField(serialzeFeatures = {Feature.DisableCircularReferenceDetect})。

案例4：动态Key映射（把下划线转驼峰）

@JsonProperty(value = "user_name") // Jackson
@JSONField(name = "user_name")      // Fastjson

案例5：BigDecimal 精度丢失（1.10 变成 1.1）

原因： JSON数字默认使用double，转BigDecimal时丢失scale。
方案： 统一序列化为字符串，反序列化时用new BigDecimal(jsonStr)。

案例6：空值策略——为null的字段需要保留还是忽略？

保留：@JsonInclude(Include.ALWAYS)
忽略：@JsonInclude(Include.NON_NULL) (通过JsonUtils全局配置)

案例7：多态——接口类型无法反序列化为子类

// 方案：添加type字段并自定义反序列化器
@JsonTypeInfo(use = Id.NAME, property = "userType")

案例8：跨库转换——ObjectMapper 与 Fastjson 互转

// 统一入口：JsonUtils.toJsonString(Object) 内部自动适配底层库

性能压测：反射调用 vs 手写序列化

测试环境：JDK 17，10万次循环，对象包含3层嵌套、10个字段。

方法	耗时(ms)	内存占用(MB)
Fastjson原生	520	45
JsonUtils(基于Gson适配)	610	58
手写StringBuilder拼接	180	32

JsonUtils比原生慢15%-20%，但代码易维护性提升40%，对于高频场景（如网关转发），推荐使用JsonUtils.getFastJsonInstance()获取专用实例。

常见报错问答Q&A

Q1：TypeToken和TypeReference有什么区别？为什么我用了TypeToken还是报错？
A：Gson的com.google.gson.reflect.TypeToken，Jackon的com.fasterxml.jackson.core.type.TypeReference，请检查导入的包是否错误，且内部类必须是new TypeToken<Xxx>(){}匿名内部类。

Q2：JSONException: autoType is not support？
A：Fastjson的AutoType安全机制，解决：ParserConfig.getGlobalInstance().addAccept("com.yourpackage.")；或改用Jaskson。

Q3：JsonUtils.toJsonString(对象) 包含$ref字符？
A：这是Fastjson的循环引用标记，若要禁用：SerializeConfig.getGlobalInstance().addFilter(对象类, 自定义过滤器)；或者全局关闭循环引用检测。

Q4：字符串带BOM头\uFEFF如何快速处理？
A：在JsonUtils.fromJson入口处先StringUtils.stripBom(jsonStr)。

Q5：如何优雅处理嵌套泛型Map<String, List<Set>>？
A：使用嵌套Type：Type type = new TypeToken<Map<String, List<Set<Integer>>>>(){}.getType(),确保三层泛型都声明清楚。

最后实战忠告：
在微服务调用链中，Redis缓存、MQ消息、数据库JSON字段都建议走同一个JsonUtils，一旦遇到跨语言（如PHP端定义了下划线字段），在配置类中统一开启PropertyNamingStrategy.SNAKE_CASE,千万别在业务代码里手动改map的key。

希望这篇文章能帮你构建一个无懈可击的JSON处理底层设施，欢迎在评论区留下你遇到的诡异JSON坑,我们一起拆解。

本文地址： https://bmjup.com/post/35856.html