geng本质的问题有三层：

验收标准：

必须显式配置：

APM Agent 在业务方法退出阶段，为打印方法调用日志，对完整查询结果对象执行 JSON 序列化。查询结果Yi经是一个超大 DataFrame，序列化过程又在堆上创建了巨大的字符数组，Zui终在 SerializeWriter.expandCapacity 阶段耗尽堆内存。

结果集密集型查询系统Ke以支持慢查询，但不应该让单次在线请求无限制地返回明细数据。

大结果集本身Yi经危险，但geng危险的是二次放大。

本次事故还暴露出一个geng大的架构问题：所有Neng力共享同一个 JVM。

动作：

线程栈显示，OOM 发生在 JSON 序列化扩容阶段：

flowchart LR    A --> B    B --> C    C --> D    D --> E / byte 缓冲区"]    E --> F

第一层：结果集过大

结果集密集型查询系统天然允许用户查询宽表、明细数据和多维分析结果。一旦服务端缺少硬性限制，请求可Neng返回远超预期的数据量。

这类问题的危险之处在于：它通常不是持续内存泄漏，而是瞬时内存洪峰。查询结束后堆可Neng又Neng回落，因此Ru果只kan长期堆趋势，hen容易误判。

仅在服务入口限制 pageSize 还不够。还要确保数据源适配层不会绕过分页。

从架构角度kan，这不是简单的“内存给少了”，而是故障域边界不清晰：

当 rows 超过阈值时输出 warn 日志或指标事件。这样下一次排查时不需要再从堆转储反推是否被超大 limit 打穿。

你懂的，结果集一上来整个服务就歇菜了。

这不是一次单点 Bug 修复复盘，而是一次关于「大对象、同步请求、APM 观测、JVM 堆、查询入口隔离」的系统性治理。

说实话，这类问题hen容易被忽略，直到OOM发生。

大结果集进入堆只是第一步。真正触发 OOM 的可Neng是：

使用 Eclipse MAT 打开 .hprof 后 查kan Dominator Tree。关键发现是：

java.lang.OutOfMemoryError  -> SerializeWriter.expandCapacity  -> SerializeWriter.writeString  -> JSON.toJSONString  -> APM Monitor finally log  -> 查询结果统计方法  -> 在线查询执行方法  -> Web Controller execute

这个栈非常关键。它说明：

建议将服务拆分为两个运行时集群：

咱就是说这样Nenggeng好地隔离风险。

为什么百度不收录我的文章？

有人会问，为什么百度不收录我的文章？ 答案hen简单： 因为你的文章不够独特，或者说不够有价值。 你得让百度认为你的内容是用户需要的。 怎么Zuo到呢？ 多写一些原创、有用的内容就行了。 对了还有个小技巧，多用些长尾关键词啥的。 但说实话，这dou是表面功夫，Zui重要的是你的内容要真正对用户有帮助。

必要时临时移除高风险 Agent

Ru果 APM 平台无法快速支持返回值黑名单或大对象裁剪，Ke以在预发环境验证移除 Agent 后的行为，再决定是否在生产临时下线该 Agent。 尤其是结果集密集型查询系统，必须明确区分： 短期目标不是立即重构系统，而是先避免进程 因为同类请求 OOM。 常见放大点包括： 典型风险包括： 从用户视角kan，问题可Neng表现为： 目标：查询峰值不再影响基础服务可用性。 这个动作的取舍是： 在高并发、结果集密集型数据查询类系统中，在线查询接口往往承担着非常复杂的运行时压力。这类系统常见于报表分析、实时数据检索、多维查询、在线导出和数据服务平台等场景： 原因hen简单： 这些对象叠加后10GB 堆仍然可Neng被快速耗尽。 因此，排查 OOM 不Neng只问“谁查了hen多数据”，还要问“谁把这些数据又复制、展开、序列化了一遍”。 排查过程中，还需要排除几个常见误区： 双集群架构Neng否生效，关键在网关路由。 不Neng让一个在线 HTTP 请求承载无限明细数据。 遇到 OOM 后第一反应往往是把 JVM 堆从 10GB 调到 12GB 或 16GB。这Ke以降低短期故障概率，但不Neng解决根因。 需要建立一个明确原则： 需要重点排查： 超限策略有两种： 目标：不再因为 APM 全量序列化大结果集导致 OOM。 所以本次事故中，堆上同时存在： 把它们放在同一个 JVM 中，本质上是让低波动Neng力承担高波动Neng力的风险。 查询Ke以慢，但不Neng无限放大；观测Ke以细，但不Neng复制世界；系统Ke以承载重负载，但重负载不Neng拖垮基础Neng力。 前端限制、产品约定、默认 pageSize dou不是安全边界。真正的安全边界只Neng在服务端。 它的目标不是永远低延迟，而是可控承压： 生产环境表现为： 它提醒我们： 一个成熟的解决方案不应该停留在“这次 OOM 修好了”，而应沉淀为一套稳定性边界： geng推荐长期采用“明确拒绝或显式提示截断”，避免用户误以为拿到了完整数据。 JSON 序列化通常会构造中间字符缓冲区。对于超大对象来说这相当于在原始业务对象之外再申请一份甚至多份大内存。 本次 OOM 的直接原因是 APM 对超大查询结果Zuo完整 JSON 序列化，但它揭示的问题远不止一个 Agent 配置。 它的目标是高可用和低延迟。即使查询集群发生 OOM、重启或扩缩容，基础Neng力也不应该被拖垮。 在线查询用于交互式分析，必须有服务端硬上限；超大明细数据应进入异步导出或离线任务链路。 为了后续可观测，建议每次在线查询至少记录： 对高风险对象，APM 应遵循：

flowchart TB    U --> G    G --> B    G --> Q    B --> DB1    Q --> DB2

Base Cluster

Base Cluster 承载低波动、高可用的基础Neng力：

query:  execute:    max-page-size:     rows-warn-threshold: 

服务端收到请求后应执行以下逻辑： 一个常见隐患是：入口处 pageSize=，但底层 ResultSet 解析仍然使用无限读取，Zui终返回 rows 远大于入口限制。这种情况必须通过日志和单测验证。 Ru果外层 rows列表达到数百万行，即使每行只有少量字段，也足以在 JVM 堆上形成 GB 级对象。 对于 APM 和日志系统，应建立明确规则： 面对 JVM OOM，单kan日志通常不够。比较可靠的方法是把三类证据串起来： 本次问题的直接触发点是： 本次事故发生在一个 Java 数据查询服务中，JVM 堆配置约10GB。故障发生时在线查询接口正在处理大结果集，堆转储显示多个 Tomcat 工作线程持有 GB 级对象，Zui终在 JSON 序列化缓冲区扩容时触发java.lang.OutOfMemoryError 。 Ru果在线查 询 、 定时任务 、 导 出 、 登 录 、权限 、 基 础元 数 据 接口dou部署 在 同 一 个 JVM 中 ， 那 么 一 个 大 查 询峰 值 就 可 Neng影响 所 有 Neng 力 。

 query finished: viewId=xxx, rows=, columns=, costMs=, source=starrocks, sqlHash=abc123 

而不是 ：

只依赖 前 端限制 是 不够 的 。 后 端必 须 有统一 配 置 ， 例 如 ：

 query: execute: max-page-size : rows-warn-threshold : 

结论 是 ： 这是一 次 由 大 结 果 集触发 、 由 APM 全 量序列 化 放 大 的 瞬 时堆 内 存 事 故 。

但如 果 只 把 问题归 因 于 APM ， 是 不完 整 的 。

无论选择哪 种 方 案 ， dou只Neng 算止血 。 因 为只要 服务 端仍允许 超 大 结 果 集进 入 堆 ， 后续仍 可 Neng 在 HTTP 响 应 、 缓 存 或 业 务逻 辑 中 再 次触发 OOM 。

建议 SLO ：

对 于 高 并 发 、 结 果 集密 集 型 查 询系 统 ， 比较 合 理 的拆 分 方 式 不是 简 单按 Controller 或 业 务模 块拆 ， 而 是按运行 时资源 特 征拆 。

加 内 存只 Neng增 加 缓冲 区 ， 不Neng 改 变 系 统的 风 险模型 。

同 时应避免 Base Cluster 同 步阻 塞依赖 Query Cluster 。 如 果确 实需 要 跨集 群 调 用 ， 也 应设 置 超 时 、降 级 和隔 离 策 略 。

建议 分 三阶 段推 进 。

Query Cluster 承载 高 内 存 、 高波 动 、允 许慢 的 查 询 负载 ：

对 于 这 类 系 统 ， 基 础 接口 和 查 询 接口 的资 源模 型完 全 不 同 ：

推荐 日志 从 “ 打 印 对象 ” 改为 “ 打 印摘 要 ” ：

 query finished: viewId=xxx, rows=2345678, columns=12, costMs=1234, source=starrocks, sqlHash=abc123def456 

正 确顺序 应 该 是 ：

用 户 发 起 查 询 请 求 ；

网 关 转 发 请 求 到 API Gateway ；

API Gateway 根 据 请 求 特 性 路 由 到 不 同 集 群 ；

如 果 请 求 属 于 高 并 发 、 结 果 集密 集 型 查 询 ， 路 由 到 Query Cluster ；

Query Cluster 负 责 处 理 查 询逻 辑 并返 回 结 果 ；

Base Cluster 保 持 低 波 动 、 高 可 用 ， 支 持 核 心 业 务 流 程 。

总 结

本 文 回 答 一 个典 型 的 工 程 问 题 ： 当 一 个 高 并 发 、 结 果 集密 集 型 Java 数 据 查 询服 务 在 大 结 果 集 场 景 下 出 现堆 内 存 OOM 时 ， 如 何 从 现 象定 位 到 根 因 ， 并 进 一 步沉淀 出 可 持 续 的 稳 定 性架 构 ？

一次 生 产环 境 OOM暴露 出 一 个容 易 被忽 略 的 问 题 ： 真正压垮 JVM 的 不一 定 是 数 据 库查 询 本 身 ， 而 可 Neng 是查 询结 果 进 入 JVM 后 ， 被 日志 、 APM 或响 应序列 化 二 次放 大 。

因此 ， 治 理策 略 也 必 须分层 ：

第 一层 ： 结 果 集 过 大 ；

第 二层 ： 二 次 放 大 ；

第 三层 ： 故 障域 边 界 不 清晰 ； 业 务Neng 力 共享 同 一 个 JVM 导 致 风 险共担 ； 解 决方 案 包 括 业 务拆 分 和资 源隔 离 等 策 略 来提 高 系 统稳 定 性 和可 持 续性 ； Zui 后 ， 强 调 了持 续监 管 和优 化 系统 配 置 以 预 防 未 来 故 障发 生 的 重 要性 。 你 说 对 不 对 ？ 说 实 话 ， 这 篇 文 章 写 得 还挺 有 感 想 的 ！ 哈 哈 ， 希望 你 会喜欢 ！ 咱 就 是 说 ， 一 个 好 文 章 不仅 要 有 技术 内 涵 ， 还 得 让 人读 着舒 心 ！ 那 个 那 个 ， 我 们 下 篇 文 章 再 见 ！ 你懂的 ！ 拜拜 ！

---