Java应用文件创建数毫秒后exists()检查失败问题咨询

盲目加固定超时等待无法根治问题，仅能降低偶发触发概率，这类跨进程文件可见性问题是后端开发非常常见的踩坑场景，几乎所有做过文件处理、日志采集的开发者都碰到过。

你观测到的文件mtime早于检查时间，不代表执行检查的时刻路径已经对JVM进程可见，常见诱因如下：

• 时间统计存在维度差：你通过ls拿到的是文件inode的修改时间，而File.exists()校验的是父目录下的目录项是否关联到该inode。写入进程更新完inode内容、写入mtime的时刻，并不代表已经完成目录项挂载操作，此时按路径查询自然返回不存在。另外你记录的检查时间来自日志输出，日志异步刷盘本身存在几毫秒到十几毫秒的延迟，实际执行exists()的时间点大概率早于日志记录的10:00:29.538，真实间隔远小于你计算的45ms。
• 文件系统本身的元数据延迟：如果/dir是NFS/SMB等网络文件系统、容器环境常用的OverlayFS联合文件系统、或者FUSE实现的用户态文件系统，内核VFS层的目录项缓存、元数据同步本身就存在不确定的延迟，几毫秒到上百毫秒的可见性延迟都属于正常现象。
• 旧API的实现缺陷：你用的java.io.File.exists()是JDK1.0时代遗留的IO API，实现上没有处理部分文件系统的元数据同步语义，在目录项暂未同步的场景下会直接返回false，不会触发缓存刷新。
• 其他易忽略的诱因：如果目标路径是符号链接，exists()默认会跟进链接目标，若链接目标暂未创建、或JVM进程用户对目标路径无权限，哪怕链接本身已经存在也会返回false；如果JVM运行用户对文件的父目录没有执行（x）权限，同样会出现文件存在但校验返回false的情况。

不要写固定sleep时长的等待逻辑，带轮询的短重试机制可以覆盖绝大多数文件系统元数据延迟导致的误判：可以设置最大等待时长200ms，每10ms执行一次存在性校验，查到文件存在就立刻终止等待继续后续逻辑，不需要等满超时时间。
但要注意：如果问题根因是权限配置错误、路径拼写错误、写入侧创建文件后立刻删除、写入逻辑非原子，加再多等待也无法解决问题。

• 第一步先替换校验API：把java.io.File.exists()替换为JDK7+提供的java.nio.file.Files.exists(path, LinkOption.NOFOLLOW_LINKS)，NIO.2的文件API对各类文件系统的语义兼容更好，还可以通过LinkOption参数控制是否跟进符号链接，排查时可以分别测试带/不带该参数的返回结果，快速定位是否是符号链接导致的问题。
• 确认文件系统类型：执行df -T /dir/file查看目标路径所在的文件系统类型，如果是网络文件系统、联合文件系统、用户态文件系统，必须在文件校验逻辑中加入重试机制，这是这类文件系统的固有特性，无法通过配置完全消除延迟。
• 校验写入侧逻辑：确认生成文件的进程是否采用原子写入流程——标准原子写逻辑为先写入同目录下的临时文件，写完执行fsync刷盘后，再通过rename操作原子替换目标文件。如果写入侧直接创建目标文件边写边刷，不仅会出现存在性误判，就算校验通过也可能读到不完整的文件内容。
• 校验权限配置：切换到启动Java进程的系统用户身份，手动执行ls /dir/file校验访问权限，不要用root或个人登录账号测试权限，避免用户权限不匹配导致的误判。
• 校验事件触发逻辑：如果你的路径来自文件系统事件监听（比如inotify、WatchService），注意这类事件是异步触发的，收到文件创建事件不代表文件已经完成写入、对其他进程可见，所有事件触发的文件处理逻辑都必须带存在性重试。

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