携程大数据平台运行着大规模的 Spark、Flink 计算集群，为充分发挥 JDK25 LTS 版本在内存效率与运行性能上的优势，我们启动了 JDK 升级计划，并完成了 多个引擎 对 JDK25 的适配改造，开始向生产环境灰度推进。然而就在灰度期间，我们遭遇了一个极为罕见的问题：Spark、Flink 写入的 Parquet、ORC 文件出现部分损坏——写入过程无任何报错，CRC 校验也完全通过，损坏只在下游读取时才会暴露。本文记录了我们如何从一个"Zstd 解压报错"出发，借助多款 AI 工具辅助分析，历经代码排查、JDK 版本二分、自建编译环境等多个阶段，最终将问题根因锁定到 JDK25 G1GC 的一个内部优化 Bug，并推动 OpenJDK 社区完成 backport 修复。文章还将深度解析 G1 GC 的 Optional Evacuation 机制与 JNI Pinning 原理，以及 AI 工具在整个排查链路中的具体作用。
Fastjson 是阿里巴巴开源的高性能 JSON 序列化处理库，其主要以处理小数据时速度最快而著称，功能全面。Fastjson1.X版本目前已停止维护，被Fastjson2.X代替，但1.X版本国内被广泛使用，通过学习其技术架构，剖析架构上优缺点，对技术人员提升软件设计工程实践能力很有价值。 首先我们对“序列化 / 反序列化”概念上建立直观认识，把Java对象转化为JSON格式的字符串的过程叫做序列化操作，反之则叫反序列化。如果把“序列化 / 反序列化”放到整个计算机系统的坐标系里，可以把它看成一次数据的“跨边界搬家”。 对象在“内存世界”里活得很好，但只要一离开进程地址空间（网络、磁盘、数据库、浏览器、异构语言），就必须先打成包裹（序列化），到对岸再拆包裹（反序列化）。
近几年，许多 Java 应用默认启用了 TTL Agent。它以 Java Agent 方式在运行期增强，实现线程上下文在线程池/异步执行间的透明传递，无需改造 Runnable 或线程池，真正做到了对业务代码的零侵入。 但我们也观察到：若使用不当，可能带来稳定性隐患，如上下文污染、线程/内存泄漏、CPU 异常等。本文将简要回顾 TTL 的工作原理，并结合近期生产案例，给出可复现的问题现象与避坑实践。
