OpenJDK 虚拟线程与 JFR 观测如何协同

OpenJDK 虚拟线程和 JFR 并不是两个孤立的特性：虚拟线程把大量等待型任务从少量平台线程上解耦，JFR 则负责告诉你这些任务究竟在等待什么、是否长时间占住 carrier，以及提交失败是否来自资源边界。实际排查时，先录制一个有限窗口，再把虚拟线程事件和数据库连接、HTTP 调用、请求延迟放在同一时间线上，结论会比单看线程数可靠得多。

OpenJDK 官方说明：https://openjdk.org/jeps/444

JFR 官方文档：https://docs.oracle.com/en/java/javase/25/troubleshoot/troubleshoot-performance-issues-using-jfr.html

先把虚拟线程、carrier 和资源分成三层

虚拟线程由 JDK 调度到平台线程上执行。运行 Java 代码时，它会挂载到 carrier；遇到可卸载的阻塞 I/O，虚拟线程可以暂停并释放 carrier，稍后再恢复。因此“虚拟线程很多”不等于“平台线程很多”，也不等于数据库连接、下游 QPS 可以无限增加。

JEP 444 还特别强调，虚拟线程不是更快的线程。CPU 密集任务仍受处理器核心数约束；虚拟线程最适合大量并发、单个任务经常等待的服务。JFR 的价值就在于把这种等待从猜测变成事件和时间段。

用有限窗口录下同一批请求

排查不要一上来长期录制。先在问题出现前后抓取 60 秒左右的 profile 配置，文件名带上实例和时间窗口，便于和应用日志对齐。下面的命令是示例，PID 要替换成目标 Java 进程号。

# 用有限时长捕获问题窗口，避免把持续录制当成容量结论。
jcmd PID JFR.start name=virtual-thread-window settings=profile duration=60s filename=vt-window.jfr

# 只筛出最先值得看的虚拟线程事件，减少人工翻阅成本。
jfr print --events jdk.VirtualThreadPinned,jdk.VirtualThreadSubmitFailed vt-window.jfr

JFR 能把应用代码产生的分配、I/O 等事件关联到正确的虚拟线程，这一点适合追踪“一个请求为什么长时间没有完成”。但录制文件不是业务指标本身，仍要把事件发生时间与请求 ID、下游调用和资源池日志对齐。

先看 pinning，再看提交失败

jdk.VirtualThreadPinned 表示虚拟线程在被固定到 carrier 时发生了阻塞。典型边界是长时间执行 synchronized 代码，或者进入 native/foreign function；短小的内存临界区不必为了迁移而全部改写。频繁且持续的 pinning 才可能抓住 carrier，造成吞吐下降。

jdk.VirtualThreadSubmitFailed 则说明虚拟线程启动或解除停放时提交失败，通常应沿着资源耗尽方向调查。它不能单独证明是堆内存、调度器还是业务侧连接池出了问题，必须结合同窗口的 GC、线程、连接池和错误日志。

把 JFR 结果变成可复查的改造动作

第一步是把录制窗口切成“请求进入、等待、恢复、完成”四段，确认事件是否集中在同一类接口。第二步是比较事件与外部资源：如果 pinning 和连接池耗尽同时出现，优先拆开锁内 I/O；如果只有下游延迟升高，就先在资源入口做并发边界，而不是盲目增加虚拟线程。

第三步是做一次小范围复查。改动后用相同流量和相近窗口再次录制，比较 pinning 持续时间、请求尾延迟、CPU 利用率和连接池等待。没有对照窗口的“事件变少”，不能直接等同于服务变好。

常见问题

虚拟线程数量增加后，JFR 里事件一定更多吗？

不一定。事件数量还受事件启用状态、阈值、任务类型和实际阻塞行为影响，不能用线程总数替代事件分析。

看到 VirtualThreadPinned 就必须删除 synchronized 吗？

不必。先确认是否频繁、持续且包含阻塞操作；只保护短小内存操作的同步块通常不需要为了指标本身改动。

JFR 能直接告诉我应该把连接池调多大吗？

不能。JFR 能提供等待和线程关联证据，连接池大小仍要结合下游容量、请求并发、超时和压测结果决定。