JFR方法采样未包含java.nio包方法？文件遍历性能排查疑问

为什么FileUtils.listFiles未被JFR统计？ #

主要有以下几个核心原因：

• 采样栈追踪限制：JFR默认方法采样针对Java方法，当线程处于sun.nio.fs.WindowsNativeDispatcher.CreateFile0这类native方法执行阶段时，采样捕获的栈顶为native方法，上层的FileUtils.listFiles因仅负责触发底层调用、自身执行时间极短，容易被采样机制忽略。
• 采样频率阈值：JFR默认20ms的方法采样间隔，可能不足以覆盖FileUtils.listFiles的调用周期，尤其是当该方法被拆分为大量细碎的native调用时，采样点可能刚好跳过上层Java方法的执行时段。
• JMC方法分析聚合逻辑：JMC的“方法分析”板块默认只展示占比达阈值的方法，而FileUtils.listFiles的耗时实际由底层native IO操作贡献，JMC会将耗时聚合到底层nio方法上，未单独展示上层工具类方法。

如何通过JFR/JMC排查此类IO性能瓶颈？ #

1. 调整JFR采样配置，增强追踪能力 #

录制时开启native方法采样并提高采样频率，确保捕获完整调用链：

java -XX:StartFlightRecording=settings=profile,methodsampling=true,methodsampling.frequency=10ms,stackdepth=256 -jar your-app.jar

其中methodsampling.frequency=10ms缩短采样间隔，stackdepth=256保证捕获足够长的调用栈，settings=profile启用全面采样规则。也可在JMC中选择自定义模板，勾选“Method Profiling”下的“Include Native Stack Traces”并调整采样参数。

2. 分析JFR核心事件 #

• Thread Dump事件：在JMC的“Threads”面板筛选目标线程的所有栈轨迹，找到FileUtils.listFiles与native IO方法的完整调用链，确认耗时集中环节。
• File IO事件：查看JFR记录的FileOpen/FileRead等事件，统计每个文件操作的耗时，定位是否存在单个特殊文件或目录导致的延迟。
• 火焰图分析：在JMC中生成火焰图（或导出数据用第三方工具生成），直观展示整个调用栈的耗时占比，包括native方法，清晰看到FileUtils.listFiles在链路中的位置。

3. 补充自定义JFR事件精准统计 #

若需直接追踪FileUtils.listFiles的耗时，可在代码中添加自定义事件：

import jdk.jfr.Event;
import jdk.jfr.Label;

@Label("FileUtilsListFilesDuration")
public class ListFilesEvent extends Event {
    @Label("Directory Path")
    public String dirPath;
    @Label("File Count")
    public int fileCount;
}

// 调用前后触发事件
ListFilesEvent event = new ListFilesEvent();
event.dirPath = directory.getAbsolutePath();
event.begin();
Collection<File> files = FileUtils.listFiles(directory, null, true);
event.fileCount = files.size();
event.commit();

录制后在JMC中可直接查看该事件的耗时分布，精准定位方法执行时间。

4. 结合系统层面排查 #

由于问题出在Windows平台的nio调用，可配合系统工具辅助排查：

• 打开资源监视器，查看磁盘IO使用率、响应时间，确认是否为磁盘硬件性能瓶颈。
• 检查目录结构：若目录嵌套过深或包含大量小文件，Windows文件系统本身遍历效率较低，这可能是核心原因而非代码问题。

内容的提问来源于stack exchange，提问作者Olivier Masseau