在调用栈层面调试 Java 文件 I/O，就是把每一次 native 的 write() 系统调用回追到触发它的 Java 业务方法 —— 这是 IDE 断点触及不到、coredump 也无法保存的信息。本文用时间旅行回放演示如何做到：录制运行中的 Java 进程，在 write() 上打断点，从 JNI 层向上重建完整的 Java 调用栈，直至你的 Files.write 调用方。

立即申请 OpenResty XRay 试用

IDE 断点和 coredump 在 Java 文件 I/O 排查中的短板

大多数 Java 开发者最先拿起的两类工具，都无法回答"是哪个业务方法触发了这次文件写入"：

  • IDE 断点止步于 JVM 边界。 它们可以在 Java 方法上暂停，但无法在 libc 中的底层 write() 系统调用处打断点 —— 而这里才是文件写入真正离开程序的地方。
  • Native 调用栈止步于 JNI 层。 挂上 C 层调试器执行 bt，能追到 Java_sun_nio_ch_FileDispatcherImpl_write0 就断了 —— 无法看到是哪个 Java 方法触发了它。
  • coredump 只是单一时刻的快照。 coredump 抓取的是某一瞬间的状态，无法还原走到那一刻的执行路径，也就没法回退查看之前的每次 write 或当时的 Java 调用栈。

时间旅行回放同时填上这两个缺口：它记录整个执行过程，让你在时间线上前后自由导航；同时允许在 native 系统调用上打断点，并在任何一次断点处重建完整的 Java 调用栈。

从 native write() 系统调用重建完整的 Java 调用栈

这套重建能力由两个部分协同完成：

  1. UDB 记录 JVM 进程的整个执行过程，因此你可以在任何系统调用处暂停 —— 包括 libc 中的 write() —— 并沿时间线向前或向后单步。

  2. OpenResty XRay 提供了一个 Y 语言脚本 java-udb.y.py，在 UDB 中加载后会新增一个 java_bt 命令。java_bt 会在任意断点上打印完整的 Java 调用栈 —— 从 C:__libc_write 一路向上穿过 JNI 层直到业务方法 —— 把原生 bt 只能看到的 C 层回溯变成一条端到端的完整路径。

后文将在真实 Java 进程上演示录制、打断点、重建这一整套流程。

用时间旅行回放一步步调试 Java 文件 I/O

下面 5 步将录制运行中的 Java 进程、在 native 的 write() 系统调用上打断点，并重建每一次 write 背后的 Java 调用栈：

步骤一：录制应用执行轨迹

首先使用 UDB 的 Live Record 工具录制 Java 应用的执行过程：

  1. 使用 Live Record 工具录制一个正在运行的 Java 应用样本。

  2. 使用 UDB 工具加载录制样本，并设置调试环境：

udb -ex "set pagination off" -ex "set python print-stack full" java.rec

步骤二：定位文件操作断点

在 UDB 环境中，设置断点捕获文件写入操作：

start 1> break write
start 1> c
Continuing.
[Switching to Thread 3923049.3923068]

Thread 20 "Thread-0" hit Breakpoint 1.768, 0x00007ffff7cfdb40 in write () from /tmp/undodb.3976686.1747987405.935444.61ae9aec99c4629b/debuggee-1-bus1z2h5/symbol-files/lib64/libc.so.6

步骤三：分析底层 C 调用栈

使用 bt 命令查看当前的 C 层调用栈：

4% 7,955> bt
#0  0x00007ffff7cfdb40 in write () from /tmp/undodb.3976686.1747987405.935444.61ae9aec99c4629b/debuggee-1-bus1z2h5/symbol-files/lib64/libc.so.6
#1  0x00007ffff7e32c5f in Java_sun_nio_ch_FileDispatcherImpl_write0 (env=0x7ffff0181290, clazz=<optimized out>, fdo=<optimized out>, address=140733730265536, len=81)
    at src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c:118
#2  0x00007fffe0baacf6 in ?? ()
#3  0x000000062a39ed70 in ?? ()

从 C 调用栈可以看到系统底层的 write 系统调用被触发，但这仅显示了 JNI 层面的信息，无法直接看到 Java 业务代码的完整调用路径。

步骤四：分析 Java 完整调用栈

  1. 加载 OpenResty XRay 提供的 Java 调用栈分析工具：
4% 7,955> source java-udb.y.py
  1. 使用 java_bt 命令获取完整的 Java 调用栈：
4% 7,955> java_bt
Start tracing...
C:__libc_write
sun.nio.ch.FileDispatcherImpl:write0(Native Method)
@FileDispatcherImpl.java:62
sun.nio.ch.FileDispatcherImpl:write
@IOUtil.java:114
sun.nio.ch.IOUtil:writeFromNativeBuffer
@IOUtil.java:75
sun.nio.ch.IOUtil:write
@IOUtil.java:67
sun.nio.ch.IOUtil:write
@FileChannelImpl.java:288
sun.nio.ch.FileChannelImpl:write
@Channels.java:89
java.nio.channels.Channels:writeFully
@Channels.java:158
java.nio.channels.Channels$1:write
@StreamEncoder.java:223
sun.nio.cs.StreamEncoder:writeBytes
@StreamEncoder.java:325
sun.nio.cs.StreamEncoder:implClose
@StreamEncoder.java:165
sun.nio.cs.StreamEncoder:close
@OutputStreamWriter.java:252
java.io.OutputStreamWriter:close
@BufferedWriter.java:263
java.io.BufferedWriter:close
@Files.java:3579
java.nio.file.Files:write
@Processor.java:42
FileWriterTask:run
@Thread.java:840
java.lang.Thread:run

通过这个完整的 Java 调用栈，我们可以清晰地看到从业务代码 FileWriterTask:run 方法开始，经过 Java 标准库的 Files.write 方法，一直到底层系统调用的完整路径。这对于理解应用的文件操作行为、定位性能瓶颈或排查文件操作相关问题具有关键价值。一旦识别出触发调用的业务方法，OpenResty XRay 还可以实时抓取传给这个方法的参数值，无需 Java agent、也无需字节码插桩。

跨时间对比文件写入调用栈

UDB 的时间旅行调试能力是其最强大的特性之一。通过这一功能，我们可以在录制的执行轨迹中自由地前进或回溯，精确定位到不同的文件操作时间点，并全面分析每次写入操作的完整上下文和调用栈。这种能力在排查复杂的文件操作问题时尤为关键。

为了验证这一点，我们可以继续执行程序，捕获下一个文件写入操作：

8% 16,337> c
Continuing.

Thread 20 "Thread-0" hit Breakpoint 1.768, 0x00007ffff7cfdb40 in write () from /tmp/undodb.3976686.1747987405.935444.61ae9aec99c4629b/debuggee-1-bus1z2h5/symbol-files/lib64/libc.so.6

8% 16,337> java_bt
Start tracing...
C:__libc_write
sun.nio.ch.FileDispatcherImpl:write0(Native Method)
@FileDispatcherImpl.java:62
sun.nio.ch.FileDispatcherImpl:write
@IOUtil.java:114
sun.nio.ch.IOUtil:writeFromNativeBuffer
@IOUtil.java:75
sun.nio.ch.IOUtil:write
@IOUtil.java:67
sun.nio.ch.IOUtil:write
@FileChannelImpl.java:288
sun.nio.ch.FileChannelImpl:write
@Channels.java:89
java.nio.channels.Channels:writeFully
@Channels.java:158
java.nio.channels.Channels$1:write
@StreamEncoder.java:223
sun.nio.cs.StreamEncoder:writeBytes
@StreamEncoder.java:325
sun.nio.cs.StreamEncoder:implClose
@StreamEncoder.java:165
sun.nio.cs.StreamEncoder:close
@OutputStreamWriter.java:252
java.io.OutputStreamWriter:close
@BufferedWriter.java:263
java.io.BufferedWriter:close
@Files.java:3579
java.nio.file.Files:write
@Processor.java:203
CoreWriterTask:run
@Thread.java:840
java.lang.Thread:run

通过对比两次捕获的调用栈，我们可以清晰地看到：

  1. 第一次写入操作来自 FileWriterTask:run 方法（位于 Processor.java:42）
  2. 第二次写入操作则来自 CoreWriterTask:run 方法（位于 Processor.java:203）

这种分析方法不仅适用于文件写入操作，同样可以应用于文件读取、网络通信等各类 I/O 场景。如果你想从更宏观的角度看，OpenResty XRay 还能分析 Java 应用的 CPU、off-CPU 和磁盘 I/O 使用，且无需 JVM 安全点。

OpenResty XRay 与 UDB 结合的动态分析能力让我们能够全面洞察应用中的文件操作行为模式，突破了传统调试方法仅能捕获单一时刻状态的局限。特别是在进程已经终止或不存在的情况下，相较于传统 GDB 的 coredump 分析，UDB 的回溯分析能力展现出其独特的优势。

coredump 仅能提供程序崩溃瞬间的静态快照，无法重现崩溃前一段时间的完整执行路径；而 UDB 通过其录制功能，即使在原始进程不再运行的情况下，依然赋予 OpenResty XRay 在完整程序执行历史中自如穿梭的能力，可以精确检视任意时间点的程序状态与行为细节，真正实现了时间维度上的全方位调试。

常见问题

如何看到一次 Java 文件写入的完整调用栈？

在录制的 JVM 运行中对 native 的 write() 系统调用打断点（UDB 里执行 break write），然后运行 java_bt —— 通过 source java-udb.y.py 加载 OpenResty XRay 的 Y 语言脚本后新增的命令。它会打印完整的 Java 栈：从最底部的 C:__libc_write 到最顶端触发写入的业务方法。

时间旅行调试和 coredump 分析有什么区别？

coredump 是崩溃瞬间的单时刻快照 —— 你可以查看状态，但无法回放程序是怎么走到那里的。时间旅行调试记录整个执行过程，你可以前后单步、在任意系统调用上暂停，并在过去运行中的任何时刻重建调用栈。

为什么 C 层 bt 只看到 JNI，看不到 Java 业务方法？

C 层调试器的 bt 命令是在遍历 C 栈帧。当 Java 代码触发一次文件写入时，C 层回溯只能追到 JNI 入口 Java_sun_nio_ch_FileDispatcherImpl_write0 就断了 —— 因为 JVM 的解释器帧和 JIT 帧并不是标准的 C 栈帧。你需要一个懂 JVM 的工具来展开它们；OpenResty XRay 的 java_bt 就是做这件事的。

总结

UDB 结合 OpenResty XRay 提供的 Java 调用栈分析能力，为开发者提供了前所未有的应用行为洞察力。通过时间旅行调试和完整调用栈分析，开发者可以：

  1. 精确定位文件操作的来源和上下文
  2. 深入分析 I/O 性能瓶颈
  3. 高效排查文件操作相关的问题
  4. 全面验证文件操作的安全性和正确性

这种深度分析能力对于开发 Java 应用尤为重要，特别是在现在这个微服务成常态的时代，这种深度分析能力简直就是救命稻草。

希望本文的实战演示能帮助您更好地理解和体会 UDB 和 OpenResty XRay 的应用场景和强大之处。如果你也在为复杂的调试问题头疼，不妨试试这套组合拳。

立即申请 OpenResty XRay 试用

关于 OpenResty XRay

OpenResty XRay 是一个动态追踪产品，它可以自动分析运行中的应用，以解决性能问题、行为问题和安全漏洞，并提供可行的建议。在底层实现上，OpenResty XRay 由我们的 Y 语言驱动，可以在不同环境下支持多种不同的运行时，如 Stap+、eBPF+、GDB 和 ODB。

立即申请 OpenResty XRay 试用

关于作者

章亦春是开源 OpenResty® 项目创始人兼 OpenResty Inc. 公司 CEO 和创始人。

章亦春（Github ID: agentzh），生于中国江苏，现定居美国湾区。他是中国早期开源技术和文化的倡导者和领军人物，曾供职于多家国际知名的高科技企业，如 Cloudflare、雅虎、阿里巴巴，是 “边缘计算 “、” 动态追踪 “和 “机器编程 “的先驱，拥有超过 22 年的编程及 16 年的开源经验。作为拥有超过 4000 万全球域名用户的开源项目的领导者。他基于其 OpenResty® 开源项目打造的高科技企业 OpenResty Inc. 位于美国硅谷中心。其主打的两个产品 OpenResty XRay（利用 动态追踪 技术的非侵入式的故障剖析和排除工具）和 OpenResty Edge（最适合微服务和分布式流量的全能型网关软件），广受全球众多上市及大型企业青睐。在 OpenResty 以外，章亦春为多个开源项目贡献了累计超过百万行代码，其中包括，Linux 内核、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl 等，并编写过 60 多个开源软件库。

关注我们

如果您喜欢本文，欢迎关注我们 OpenResty Inc. 公司的 博客网站 。也欢迎扫码关注我们的微信公众号：

我们的微信公众号

翻译

我们提供了 英文版 原文和中译版（本文）。我们也欢迎读者提供其他语言的翻译版本，只要是全文翻译不带省略，我们都将会考虑采用，非常感谢！