Java NIO 文件系统 API 使用委托和抽象工厂模式。在最低级别有以下实现java.nio.file.spi.FileSystemProvider：
文件系统的服务提供者类。类定义的方法
Files通常会委托给此类的实例。 [强调]
AFileSystemProvider提供了以下实例java.nio.file.FileSystem：
提供文件系统的接口，是对象访问文件系统中的文件和其他对象的工厂。
调用该方法获取的默认文件系统
FileSystems.getDefault提供对Java虚拟机可访问的文件系统的访问。该类FileSystems定义了创建文件系统的方法，该文件系统提供对其他类型（自定义）文件系统的访问。文件系统是多种类型对象的工厂： [强调]
该
getPath方法转换系统相关路径字符串，返回Path可用于定位和访问文件的对象。该
getPathMatcher方法用于创建PathMatcher对路径执行匹配操作的 。该
getFileStores方法返回底层文件存储上的迭代器。该
getUserPrincipalLookupService方法返回按UserPrincipalLookupService名称查找用户或组。该
newWatchService方法创建WatchService可用于监视对象的更改和事件的 。
然后是Path界面：
可用于在文件系统中定位文件的对象。它通常代表系统相关的文件路径。
请注意，aPath只是一条路径。它不一定代表实际的文件，仅代表文件的路径（无论存在与否）。在这方面与此类似java.io.File。
当您调用Files类中的方法时，它使用Path#getFileSystem()和FileSystem#provider()方法委托给FileSystemProvider. 这种 API 设计允许开发人员以透明的方式使用具有任何实现的Files类。对于开发人员来说，如何创建它并不重要，只要以符合 API 契约的方式创建即可。PathInputStreamInputStream
该方法Paths#get(String,String...)并Path#of(String,String...)委托给默认文件系统来创建Path. 当您将这些Path实例与中的方法一起使用时Files，您最终将访问主机平台的底层文件系统。
如果您想创建一个虚拟文件系统，那么您需要实现FileSystemProvider以及所有相关的抽象类和接口，例如FileSystem和Path。但请注意，某些 API 是“可选的”。如果您的实现不提供可选的 API，那么您可以抛出一个UnsupportedOperationException. 各种类/方法的 Javadoc 提供了更多信息。
也就是说，已经有一个内存文件系统实现： https: //github.com/google/jimfs
“但我不清楚如何在不实例化 File(InputStream) 的情况下完成此操作”。NIO 文件 API 与java.io.File. 如果你想了解它是如何做的，你可以查看源代码。您的 JDK 应该附带一个src.zip包含 Java 源文件的文件；但是，它仅包含主机操作系统的实现，而不会包含任何本机代码（默认文件系统最终使用本机代码与底层操作系统的文件系统进行通信）。