Skip to content
Max / Knowledge

JSONReader 分派

Difficulty
Advanced
Status
Stable
Last reviewed
2026年8月

This content is not available in your language yet.

JSONReader 把“从哪里读”和“读出什么类型”分开：reader 负责 token、编码和基础值，ObjectReader 负责目标 Java 类型。

先给答案：JSONReader 把“从哪里读”和“读出什么类型”分开：reader 负责 token、编码和基础值，…

Section titled “先给答案：JSONReader 把“从哪里读”和“读出什么类型”分开：reader 负责 token、编码和基础值，…”

JSONReader 把“从哪里读”和“读出什么类型”分开：reader 负责 token、编码和基础值，ObjectReader 负责目标 Java 类型。 正文沿“创建与分派 -> 特性位 -> 对象读取边界”展开：先确认入口和状态归属，再跟踪控制流或数据流的推进，最后落到对外可观察的结果。

主要失效边界集中在“Bean 读取通常先确认 object/array 起始 token，再由 ObjectReader 按字段名定位 FieldReader”这些场景。它们破坏的是容量、顺序、并发或生命周期前提；排查时应先确认状态是否仍由正确对象持有，再核对推进条件和清理路径。

创建与分派

Section titled “创建与分派”
JSONReader.of(String / byte[] / InputStream)
              ↓
JSONReaderJSON / JSONReaderUTF8 / JSONReaderUTF16
              ↓
readString / readInt32 / startObject / nextIfObjectStart
              ↓
ObjectReader.readObject

不同输入介质会选择不同 reader 实现，避免每个字符都经过通用抽象。JSONB 路径则使用二进制类型标记和符号表等优化，读取逻辑与 JSON 文本的字符扫描不同。

特性位

Section titled “特性位”

解析特性通常以 bit mask 组合，例如字段名智能匹配、未知字段处理、自动类型、时间格式和数组映射。位掩码让一次 reader 调用可以快速判断多个开关，但也让配置来源和优先级更难排查。

应用应区分全局默认特性、reader 局部特性和类型/字段注解，避免在多个层面重复打开高风险行为。

对象读取边界

Section titled “对象读取边界”

Bean 读取通常先确认 object/array 起始 token，再由 ObjectReader 按字段名定位 FieldReader。字段值的实际读取会递归回到 provider 查找的子 reader，因此数组、Map、日期和自定义类型可以复用同一格式层。

替代方案与代价

Section titled “替代方案与代价”

替代方案：所有类型都先读成 Map<String,Object>，再二次转换。

代价：会产生中间对象、丢失精确类型信息，并把字段匹配和转换成本支付两次。直接 reader + object reader 组合可以在 token 到字段值之间建立更短路径。

边界与踩坑

Section titled “边界与踩坑”
  • 输入介质不同会改变编码、拷贝和分配成本，基准测试必须固定输入形态。
  • 宽松字段名匹配、自动类型和未知字段忽略会扩大输入接受面，不能只看解析速度。
  • 自定义 reader 必须正确推进 token，否则错误可能在后续字段才暴露。

面试锚点

  • UTF-8 reader 为什么不能简单复用 UTF-16 字符串路径？
  • 特性位解决了什么问题，又带来什么排查成本？
  • reader 如何保证自定义类型读取后游标位置正确？
Section titled “Related”