FileSystemNotFoundException是Java NIO.2中因文件系统未注册、未挂载或URI不匹配而抛出的异常，常见于误用FileSystems.getFileSystem()访问分布式URI等场景，而非分布式文件系统原生异常。
FileSystemNotFoundException 通常不是分布式文件系统本身的异常，而是 Java NIO.2 中针对本地 java.nio.file.FileSystem 实例未注册或已关闭时抛出的运行时异常。 它在 HDFS、Ceph、JuiceFS、Alluxio 等典型分布式文件系统客户端中**不会直接出现**——这些系统一般通过自定义 URI scheme（如 hdfs://、ceph://）+ 自定义 FileSystem 实现来工作，其异常体系独立于标准 NIO FileSystemProvider 机制。
为什么你在分布式场景看到 FileSystemNotFoundException？
常见于以下几种误用情况：
- 代码中错误调用了
FileSystems.getFileSystem(URI)去获取一个未通过FileSystems.newFileSystem(...)显式挂载、且无对应 Provider 注册的分布式 URI（例如直接传入hdfs://nn:8020/path） - 使用了基于 NIO 的通用工具类（如某些配置解析器、路径校验器），它们默认依赖标准
FileSystemProvider，但未适配分布式 URI scheme - 手动注册了自定义 Provider，但未正确绑定 scheme（如注册了
"myfs"却尝试访问myfs:///path，而实际配置写成了myfs://或漏掉冒号） - 挂载的内存文件系统（如 JimFS）或测试用 FileSystem 被提前 close()，后续再 getFileSystem 就触发该异常
如何准确定位“挂载点丢失”的真实问题？
不要只盯着异常名，重点检查上下文中的 URI 和 FileSystem 生命周期：
-
打印完整 URI：捕获异常时记录
uri.toString()，确认是否拼写错误（如多斜杠hdfs:////、缺端口、主机名不可达） -
检查 FileSystem 是否被复用或泄漏：若用
newFileSystem(uri, env)创建过实例，确保没有重复创建又未 close；多个线程共用单例 FileSystem 时，避免某处意外 close -
验证 Provider 是否加载：调试时调用
FileSystemProvider.installedProviders()，看输出中是否包含你期望的 provider（如HdfsFileSystemProvider）及其支持的 scheme -
区分“未挂载”和“不可达”：该异常表示 JVM 根本找不到对应文件系统实现，而非连接超时或权限拒绝——后者会抛出
IOException或子类（如ConnectException、AccessDeniedException）
分布式文件系统中更典型的挂载/连接异常处理方式
真正对接分布式存储时，应关注其原生客户端的异常：
-
HDFS：捕获
IOException，检查是否为org.apache.hadoop.ipc.RemoteException（含具体错误码）、java.net.ConnectException（NameNode 不可达）或org.apache.hadoop.security.AccessControlException -
JuiceFS / Alluxio：查看其 SDK 文档中定义的 client 异常类（如
JuiceFSException），通常封装了 mount point 不存在、meta service 不通、token 过期等场景 -
统一抽象层（如 Apache Commons VFS）：使用
FileSystemManager.resolveFile("jfs://bucket/key")，异常多为FileSystemException，需 inspect cause 获取底层原因
预防性建议
避免把 NIO FileSystem 机制当作分布式文件系统的通用入口：
- 对 HDFS/Ceph 等，优先使用其官方 Java Client（
org.apache.hadoop.fs.FileSystem）并管理好 Configuration 和 UGI - 若必须走 NIO 接口（如 Spring Batch 需要
Path），选用已适配的桥接库（如hadoop-nio、alluxio-nio），并确保其 Provider 在 classpath 且自动注册 - 在应用启动时做一次最小化探测（如
fs.listStatus(new Path("/"))），早暴露配置或网络问题 - 日志中明确标注“使用的是 HDFS Client”还是“使用的是 NIO FileSystem”，便于归因
不复杂但容易忽略：FileSystemNotFoundException 是 JVM 文件系统注册表层面的缺失信号，它提醒你——当前代码试图用标准 NIO 方式打开一个根本没被 JVM “认识” 的文件系统类型。先确认你用的到底是不是标准 NIO 路径操作，再决定该查 Provider、URI 还是换回原生客户端。
