1. 从一次“Zstd 解压报错”说起JDK25 G1GC 的静默数据损坏如果你正在把 Spark、Flink 这类大数据计算引擎从 JDK21 往 JDK25 LTS 迁移并且顺手开了-XX:UseCompactObjectHeaders想省点内存那这篇文章大概率能帮你少熬几个通宵。携程大数据平台在灰度 JDK25 的过程中踩到了一个非常隐蔽的坑作业写入 Parquet、ORC 文件时全程无异常CRC 校验也通过但下游读取时却报 Zstd 解压失败数据已经损坏且不可恢复。最终定位到根因是 JDK25 G1GC 在 Optional Evacuation 阶段错误移动了被 JNI 临界区锁定的对象属于 JVM 层面的 Bug影响 JDK 25.0.0 / 25.0.1 / 25.0.2 全部已发布版本。这篇文章不讲空泛的升级建议而是把可复制的 JVM 启动参数、JNI 边界校验代码、复现验证步骤完整交付出来。适合谁看正在做 JDK25 升级的 Java 后端、大数据平台工程师以及任何在 JNI 场景下调用 Native 压缩/加密库的开发者。核心检索词先摆出来JDK25、G1GC、Compact Object Headers、JNI、OpenJDK这几个词贯穿全文。先说结论方便你快速判断自己是否中招配置组合是否数据损坏说明JDK 25 -XX:UseG1GC是压缩数据静默损坏JDK 25 -XX:UseParallelGC否正常JDK 25 -XX:UseZGC否正常JDK 21 -XX:UseG1GC否正常JDK 25含 commit 86cec4ea G1GC是确认该 commit 为根因JDK 25含 commit 006ed5c0 G1GC否正常只要你的服务跑在 JDK25 上、用的是默认 G1GC、并且通过GetPrimitiveArrayCritical/ReleasePrimitiveArrayCritical这对 JNI 接口直接操作 Java 数组内存zstd-jni、JDK 内置 Zip/Deflate 都算就有风险。下面按排查链路一步步展开。2. 前置准备TaoToken 接入与排查环境搭建排查这类 JVM 底层 Bug光靠人肉读 GC 日志和 JDK 源码效率很低。我在整个排查链路里用 AI 工具做了几件事分析数万行 Zstd debug 日志、解析损坏的二进制帧结构、生成 JDK 编译 Workflow、在庞大的 JDK 仓库里检索 G1 相关 commit。这些场景都需要一个稳定的模型调用入口TaoToken 在这里承担的就是统一接入层的角色。TaoToken 是一个面向开发者的 AI 模型 API 聚合平台能做什么把 Claude、Gemini、GPT 等模型的调用统一到一个 API 端点上适合谁需要在自己的排查脚本、CI 流程、IDE 插件里批量调用模型的工程师。它的官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 注意 API 地址不带 UTM 参数。如果你只是想在浏览器里快速验证某个模型对 GC 日志的分析能力直接用模型对话入口就行https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。如果你打算把模型调用嵌进长期的编码/Agent 工作流比如自动分析 JDK commit diff那更适合走 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。拿到 API Key 的路径在控制台里https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite Key 管理页在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 如果你用 Claude Code 做排查脚本开发参考 https://taotoken.net/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite 。注意TaoToken 在这里只是模型调用入口不参与任何 JVM 参数配置或数据链路排查的核心仍然是 JVM 本身。3. 可复制配置JVM 启动参数与 JNI 边界校验代码3.1 先确认你是否踩坑JVM 启动参数对照第一步是确认当前服务的 GC 配置。用下面命令看运行中的 JVM 实际参数jcmd pid VM.flags | tr \n | grep -Ei UseG1GC|UseParallelGC|UseZGC|CompactObjectHeaders如果输出里同时出现-XX:UseG1GC和 JDK25就要警惕了。规避方案有两个方向任选其一# 方案 A临时规避换 GC推荐先做这个止血 -XX:UseParallelGC # 或者 -XX:UseZGC # 方案 B等 JDK 25.0.3 修复版本预计 2026-04-21 发布 # 在 25.0.3 上可以重新启用 G1 -XX:UseG1GC如果你还想保留 Compact Object Headers 的内存收益可以单独测试它是否与问题相关。实测下来关闭-XX:UseCompactObjectHeaders后问题仍可复现所以它并不是根因只是恰好和 G1GC 一起被开启# 关闭紧凑对象头问题依旧说明不是它导致的 -XX:-UseCompactObjectHeaders3.2 JNI 边界校验代码在压缩前后加一道防线既然损坏是静默的那就在 JNI 边界上主动加校验。下面这段 Java 代码在调用 zstd-jni 压缩后立即对压缩结果做一次解压回验一旦发现不一致就抛出异常并记录原始数据哈希避免损坏数据落盘。import com.github.luben.zstd.Zstd; import java.util.Arrays; public class ZstdBoundaryCheck { /** * 压缩并立即回验防止 JNI 临界区对象被 GC 移动导致的静默损坏 * param raw 原始字节 * return 校验通过的压缩字节 */ public static byte[] compressWithVerify(byte[] raw) { byte[] compressed Zstd.compress(raw); // 立即解压回验 byte[] restored Zstd.decompress(compressed, raw.length); if (!Arrays.equals(raw, restored)) { // 记录原始数据哈希便于后续定位 int rawHash Arrays.hashCode(raw); int restoredHash Arrays.hashCode(restored); throw new IllegalStateException( Zstd boundary check failed! rawHash rawHash , restoredHash restoredHash , rawLen raw.length , compressedLen compressed.length); } return compressed; } }这段代码的代价是压缩后多一次解压CPU 开销大约增加 30% 到 50%。在排查阶段可以全量开启定位到问题后可以改成采样校验比如每 1000 次压缩抽检 1 次。3.3 复现脚本用 JDK 内置 Deflate 快速验证zstd-jni 需要额外依赖如果你想用 JDK 自带的 Zip/Deflate 库快速验证下面这段代码同样能触发问题因为它底层也是 JNI 实现import java.util.zip.Deflater; import java.util.zip.Inflater; import java.util.Arrays; import java.util.Random; public class DeflateRepro { public static void main(String[] args) throws Exception { Random rnd new Random(42); for (int i 0; i 100000; i) { byte[] raw new byte[8192]; rnd.nextBytes(raw); Deflater deflater new Deflater(); deflater.setInput(raw); deflater.finish(); byte[] compressed new byte[16384]; int clen deflater.deflate(compressed); deflater.end(); Inflater inflater new Inflater(); inflater.setInput(compressed, 0, clen); byte[] restored new byte[8192]; int rlen inflater.inflate(restored); inflater.end(); if (rlen ! raw.length || !Arrays.equals(raw, restored)) { System.out.println(CORRUPTED at iteration i , rlen rlen , rawLen raw.length); return; } } System.out.println(No corruption detected in 100000 iterations); } }在 JDK25 G1GC 下跑这个脚本配合下面这组参数提高 GC 触发频率能显著提升复现概率java -XX:UseG1GC \ -Xmx256m -Xms256m \ -XX:G1HeapRegionSize1m \ -XX:InitiatingHeapOccupancyPercent15 \ -XX:G1MixedGCLiveThresholdPercent85 \ DeflateRepro关键参数说明-Xmx256m把堆压小让 GC 更频繁-XX:InitiatingHeapOccupancyPercent15让 Mixed GC 更早触发-XX:G1MixedGCLiveThresholdPercent85提高老年代区域被选入回收集合的概率从而更容易命中 Optional Evacuation 阶段。4. 验证请求与成功结果如何确认问题已定位4.1 用 GC 日志确认 Optional Evacuation 是否发生要确认问题是否出在 Optional Evacuation 阶段需要打开详细 GC 日志-Xlog:gc*,gcphasesdebug,gcergo*trace:filegc.log:time,uptime,level,tags在 gc.log 里搜索Optional Evacuation关键字如果看到类似下面的输出说明该阶段确实在执行[info][gc,phases] GC(12) Optional Evacuation: 3 regions, 2.1ms4.2 用 TaoToken 模型对话验证日志分析结果把 gc.log 和 Zstd 的 debug 日志片段贴到模型对话里让模型帮你提取关键信息。比如你可以这样提问“以下是一段 JDK25 G1GC 日志请找出 Optional Evacuation 阶段被移动的 region 数量并判断是否存在 pinned 对象被移动的迹象。”模型对话入口https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。4.3 成功结果长什么样当你把 GC 换成 ParallelGC 或 ZGC 后重新跑 3.3 的复现脚本预期输出是No corruption detected in 100000 iterations同时 gc.log 里不再出现 Optional Evacuation 相关的 region 移动记录。如果你有条件编译带 commit id 的 JDK可以进一步验证基于 commit 006ed5c0 编译的 JDK25 G1GC 跑复现脚本无损坏基于 commit 86cec4ea 编译的 JDK25 G1GC 能偶现损坏。这就把根因锁定到了 JDK-8343782 这个 commit 上。5. 本篇常见错排查5.1 报错 “Src size is incorrect” 但 CRC 校验通过这是最迷惑人的现象。Parquet 默认开启parquet.page.write-checksum.enabledtrueCRC 校验的是压缩后写入文件的字节流而损坏发生在压缩阶段——C 层把数据写到了已经被 GC 移动的旧地址上写入的字节流本身是“自洽”的所以 CRC 能过。但解压时按 Zstd 格式解析就失败了。排查方向不要只信 CRC要在压缩后立即做解压回验参考 3.2 的代码。5.2 物理机集群不复现Docker 集群偶现这个差异让很多人误以为是 OS 或内核兼容性问题。实际原因是 Executor 复用率不同资源充足的 YARN 集群里 Executor 复用率低、GC 次数少问题难触发小集群或 Docker 环境里 Executor 资源紧张、复用率高多次 GC 后容易命中。验证方法在大集群里设置spark.dynamicAllocation.maxExecutors限制 Executor 数量提高复用率就能复现。5.3 切换 ORC Zstd 实现后不复现误判为 zstd-jni 问题ORC 2.0 以上版本 Zstd 压缩支持两种实现airlift aircompressor 的纯 Java 实现和 zstd-jni 的 C 实现。通过-Dorc.compression.zstd.impljava切到纯 Java 实现后问题消失容易让人以为是 zstd-jni 的适配问题。实际上纯 Java 实现不走 JNI 临界区自然不会触发 GC 移动 pinned 对象的 Bug。根因在 JVM不在 zstd-jni。5.4 关闭 Compact Object Headers 后问题仍在很多人第一反应是 JEP 519 紧凑对象头改变了对象内存布局导致的。实测关闭-XX:-UseCompactObjectHeaders后问题仍可复现可以排除。真正相关的是 G1GC 的 Optional Evacuation 逻辑和对象头压缩无关。5.5 用 JDK26/27 测试时 Spark 起不来JDK26 移除了jdk.internal.ref.Cleaner类Spark 初始化时需要加载它导致 Spark 无法在 JDK26 运行。需要先改 Spark 代码适配才能在 JDK26/27 上验证问题是否已修复。这也是为什么排查初期只能在 JDK25 各版本之间做二分。6. 后续怎么走接入文档与长期方案短期止血方案很明确JDK25 上把 G1GC 换成 ParallelGC 或 ZGC等 25.0.3 发布后再切回 G1。中期方案是在 JNI 边界加校验参考 3.2 的代码采样开启即可不必全量。长期方案是跟进 OpenJDK 社区的 backport 进展JDK-8377811 已经在 jdk25u-dev 里实现了修复。如果你要把这套排查逻辑沉淀成团队内部的自动化流程比如让 CI 在每次 JDK 升级后自动跑一遍 JNI 边界校验可以把模型调用嵌进流程里做日志分析。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite API Key 在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。如果你用 Claude Code 写排查脚本参考 https://taotoken.net/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite 。需要长期跑编码/Agent 工作流的走 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。最后留一个我踩过的坑排查初期我一直以为是 zstd-jni 在 JDK25 上的适配问题在 zstd-jni 仓库提了 issue 才发现方向偏了。后来是先用 GC 日志确认 Optional Evacuation 阶段有 region 移动再用不同 commit 的 JDK 做二分才把根因锁定到 JDK-8343782。所以顺序很重要——先确认 GC 行为再怀疑库最后才动 JDK 源码。