尧图网站建设 
每次面试问到 Java 文件操作我都能看到候选人脸上的犹豫java.io.File 的常用方法他能背得滚瓜烂熟可一旦把问题延伸到符号链接、跨平台路径分隔符、失败原因反馈这些细节十个里有七八个开始含糊。今天这篇我把 Java 里两套文件操作 API——java.io.File 和 java.nio.file——放到一张桌上逐项对比。内容来自我去年把一整套老项目从 java.io 迁移到 java.nio.file 的真实过程适合正在做 Java 文件处理、准备面试、或者准备接手老代码改造的人。看完你会清楚什么场景继续用 File 没毛病什么场景不换 NIO 迟早出事。1. 先谈定位两套 API 到底是不是替代关系1.1 时间线一个 1996 年的类和一个 2011 年的接口java.io.File 从 JDK 1.0 就有了也就是说这套 API 已经活了二十多年大量遗留系统、开源库里到处都是它的身影。而 java.nio.file 是 JDK 7 引入的 NIO.2 的一部分核心是 Path 接口和 Files 工具类从出生那天起就带着取代 File的任务。但你要真追问一句那 File 是不是废了我的回答是没废但适用面在肉眼可见地缩小。JDK 官方文档对 File 的定位其实写得很委婉大意是这个类有很多方法但使用上会有不少平台相关的坑推荐用 NIO.2 替代。这句话翻译成大白话就是能用新的就别用旧的。1.2 设计思路的根本差异一个把路径和操作揉在一起一个彻底拆开java.io.File 最大的问题不是功能少而是职责混乱。一个 File 对象既表示一个路径位置又直接在这个对象上挂了一堆操作方法exists()、mkdirs()、delete()、renameTo()……你拿着这个对象分不清自己是站在路径层还是文件系统层。更要命的是它内部把路径字符串和文件系统操作耦合在一起导致很多行为在不同操作系统上表现不一致。java.nio.file 的思路是彻底拆分Path 只负责描述路径它不关心这个路径在磁盘上是否存在也不负责创建、删除任何东西。Files 是一个纯静态工具类把对路径的所有操作都收拢到这里比如 Files.createDirectories()、Files.delete()、Files.move()。FileSystem 负责抽象底层的文件系统实现默认是操作系统自带的也可以通过厂商扩展。这套设计的好处很明显Path 可以作为一个轻量的位置引用在不同方法间传递操作什么时候做、由谁做调用方心里一清二楚。而且因为路径和操作解耦JDK 还能基于同一套接口去支持 zip 文件系统、自定义虚拟文件系统这是 File 完全做不到的。如果你在面试中被问两套 API 什么区别最稳妥的答法就是先说职责分离再补一句异常设计这两点说完基本就能把考官带走。2. java.io.File 的能力清单以及它洗不掉的四笔旧账2.1 先看它能干什么一段最常用的代码客观说java.io.File 覆盖日常七八成需求是没问题的。下面这段代码是典型的老式文件操作合集建目录、建文件、重命名、列目录、拿大小。import java.io.File; import java.io.IOException; public class FileDemo { public static void main(String[] args) throws IOException { File dir new File(/tmp/data/archive); if (!dir.exists()) { boolean ok dir.mkdirs(); System.out.println(创建目录结果: ok); } File log new File(dir, run.log); if (!log.exists()) { boolean ok log.createNewFile(); System.out.println(创建文件结果: ok); } File bak new File(dir, run.log.bak); if (log.renameTo(bak)) { System.out.println(重命名成功); } File[] children dir.listFiles(); if (children ! null) { for (File child : children) { System.out.println(child.getName() - child.length() bytes); } } } }这段代码在单机上跑起来确实没什么毛病。可一旦进入生产环境、多系统部署、大目录、权限受限的场景File 那套返回布尔值的设计就处处掣肘。下面四个旧账是我在实际项目中真实踩过的。2.2 旧账一失败只有 false没有原因File 的方法几乎清一色返回 boolean这看起来简单但恰恰是最坑的地方。dir.mkdirs() 返回 false你是该猜父目录不存在、权限不够、还是路径上已经有一个同名文件file.renameTo() 返回 false你是该猜目标文件已存在、源文件被占用、还是跨文件系统不支持你没有任何线索。我印象最深的一次是 Windows 上一个 renameTo() 间歇性失败排查了半天才发现是杀毒软件正在扫描源文件。File 返回的 false 连个错误码都没有日志里只能记录重命名失败根本没法写准确的告警信息。换成 NIO 之后Files.move() 会明确抛 NoSuchFileException、FileAlreadyExistsException、AccessDeniedException异常栈一打出来就知道是哪一层出的问题。所以我的建议是凡是需要失败原因、需要给用户反馈、需要做重试逻辑的场景一律不要用 File 的 boolean 返回值。2.3 旧账二跨平台路径处理全靠自觉路径分隔符是 File 最经典的坑。Windows 用反斜杠 \Linux/macOS 用正斜杠 /。File 在设计上提供了 File.separator 和 File.separatorChar但问题是——你不调用它就等于没有。代码里随手写一个 new File(data \ archive)在 Linux 上跑就是一个带反斜杠的怪文件名。更隐蔽的是 getAbsolutePath() 和 getCanonicalPath() 的区别。getAbsolutePath() 只是把当前工作目录拼在前面路径里的 . 和 .. 原封不动getCanonicalPath() 会做规范化解析把 . 和 .. 消掉还会在 Unix 上解析符号链接。很多老代码里拿 getAbsolutePath() 去比路径、做去重结果因为带 .. 或者符号链接两个逻辑上相同的文件被当成两个路径问题极难复现。这个坑的解法其实简单别手动拼分隔符直接 new File(parent, child) 或者用 Paths.get(data, archive)让底层文件系统自己去处理分隔符。2.4 旧账三元数据和符号链接基本是瞎子File 对文件属性的支持停留在粗略感知级别length() 拿大小、lastModified() 拿时间戳、isFile()/isDirectory() 判断类型、canRead()/canWrite() 判断权限。但这个感知很浅比如 isDirectory() 在符号链接指向目录时也会返回 true你根本判断不了这个路径本身是不是一个符号链接。NIO 里一个 Files.isSymbolicLink(path) 就把这个问题说清楚了还能通过 Files.readSymbolicLink(path) 把链接目标取出来。如果老代码要判断路径是不是快捷方式/软链File 只能靠 getCanonicalPath() 和 getAbsolutePath() 是否一致来猜非常别扭。2.5 旧账四递归遍历只能手写还得提心吊胆File 没有内置的目录树遍历能力。要遍历一个目录下所有文件你得自己写递归public void walk(File dir) { File[] children dir.listFiles(); if (children null) { return; } for (File child : children) { if (child.isDirectory()) { walk(child); } else { System.out.println(child.getAbsolutePath()); } } }这段代码看着没毛病但生产环境里目录层级深、目录数量多时问题全来了listFiles() 一次性把子项全部加载成数组大目录内存开销高递归调用层数深了有栈溢出风险遇到符号链接环更是直接无限递归。而 NIO 的 Files.walk() 和 Files.walkFileTree() 把遍历包装得又稳又省心默认不跟随符号链接从根上绕开了循环递归问题。3. java.nio.file 三件套的设计与分工Path、Files、FileSystem3.1 Path 只是路径不是文件Path 是一个接口最简单的获取方式是 Paths.get() 或者 FileSystems.getDefault().getPath()。它只干一件事描述路径。Path base Paths.get(/tmp/data); Path log base.resolve(app.log); // /tmp/data/app.log Path sibling base.resolveSibling(backup); // /tmp/backup Path messy Paths.get(/tmp/data/../data/app.log); System.out.println(messy.normalize()); // /tmp/data/app.log Path abs log.toAbsolutePath(); // 转为绝对路径resolve 方法是 File 没有的便捷能力它相当于 new File(base, child)但语义更清晰。resolveSibling 在很多迁移场景里特别好用你要把 /tmp/data/app.log 旁边生成一个 .bak直接 base.resolveSibling(app.log.bak) 就完事了不用先 getParent() 再拼字符串。注意一个关键认知Path 不会触碰磁盘。你 new 一个 Path磁盘上有没有这个文件都无所谓它仅仅是一个位置。这跟 File 对象经常让人误以为new 出来就代表真实文件相比设计上干净得多。3.2 Files 是那个真正干活的工具类Files 是纯静态方法工具类风格跟 Collections 很像。常用的方法大概分几组判断类Files.exists()、Files.isDirectory()、Files.isRegularFile()、Files.isSymbolicLink()、Files.isReadable()创建类Files.createFile()、Files.createDirectory()、Files.createDirectories()、Files.createTempFile()删除移动类Files.delete()、Files.deleteIfExists()、Files.move()、Files.copy()读取类Files.size()、Files.getLastModifiedTime()、Files.readAttributes()、Files.readAllLines()、Files.lines()遍历类Files.list()、Files.walk()、Files.walkFileTree()、Files.newDirectoryStream()因为操作和路径分离方法可以做得非常专注。比如 Files.copy() 可以通过 StandardCopyOption.REPLACE_EXISTING、StandardCopyOption.COPY_ATTRIBUTES、StandardCopyOption.NOFOLLOW_LINKS 来控制覆盖、属性复制、是否跟随符号链接File 压根没有这种粒度控制。3.3 FileSystem 与 FileStore底层抽象带来的甜头FileSystem 是文件系统的抽象默认实现对应操作系统本身。日常开发里你用得最多的其实是 FileSystem.getPath() 和 FileSystem.getSeparator()。但 FileSystem 的存在意味着你可以有非默认的文件系统。最典型的例子就是 zip 文件系统try (FileSystem zipFs FileSystems.newFileSystem( Paths.get(/tmp/archive.zip), (ClassLoader) null)) { Path inside zipFs.getPath(/entry.txt); System.out.println(Files.exists(inside)); }这一段代码用 java.io.File 是无论如何写不出来的。你相当于把 zip 包当成一个文件系统去访问Files 的工具方法全部照用。对于处理压缩包、做资源打包格式解析的场景这个能力是降维打击。FileStore 则是描述存储卷的抽象能拿磁盘总空间、可用空间FileStore store Files.getFileStore(Paths.get(/tmp)); System.out.println(总空间: store.getTotalSpace()); System.out.println(可用空间: store.getUsableSpace());File 里没有任何对应的功能以前要做磁盘空间监控只能靠 Runtime 或系统命令。3.4 异常设计让调用者知道哪一步为什么失败NIO 把操作失败从返回 false改成了抛异常这个设计一开始会让人觉得麻烦写久了会真香。Files 的方法声明抛 IOException在其下有这些明确的子类NoSuchFileException目标不存在FileAlreadyExistsException目标已存在AccessDeniedException权限不足DirectoryNotEmptyException目录非空AtomicMoveNotSupportedException底层文件系统不支持原子移动你可以精确捕获做差异化处理。比如清理临时目录时某个文件被占用抛 AccessDeniedException你可以单独记一条 WARN 日志继续处理下一个文件而不用像 File 时代那样面对一个 false 干瞪眼。try { Files.deleteIfExists(Paths.get(/tmp/lock.txt)); } catch (NoSuchFileException e) { // 已经不存在当作成功 } catch (AccessDeniedException e) { System.err.println(没权限删除: e.getFile()); } catch (IOException e) { System.err.println(其他删除错误: e.getMessage()); }这种分层异常在日常运维里价值极高日志里出现 AccessDeniedException一搜就知道是权限问题不需要再人工排查。4. 同一个操作两套写法的逐项对照4.1 总览对照表先放一张总表把最常见的场景列清楚后面再逐个展开。操作java.io.File 写法java.nio.file 写法备注判断存在file.exists()Files.exists(path)NIO 默认跟随符号链接创建单层目录file.mkdir()Files.createDirectory(path)父目录不存在会抛异常创建多层目录file.mkdirs()Files.createDirectories(path)File 返回 falseNIO 抛异常创建文件file.createNewFile()Files.createFile(path)已存在时 NIO 抛 FileAlreadyExistsException删除file.delete() 返回 booleanFiles.delete / deleteIfExistsNIO 失败带具体异常重命名/移动file.renameTo(target)Files.move(...)跨文件系统、覆盖策略差异巨大列出子项file.listFiles() 返回数组Files.newDirectoryStream 返回流NIO 是惰性迭代文件大小file.length()Files.size(path)最后修改时间file.lastModified()Files.getLastModifiedTime返回 FileTime符号链接不支持Files.isSymbolicLink / readSymbolicLink目录树遍历手写递归Files.walk / walkFileTree监听目录变化不支持WatchService磁盘空间不支持FileStore4.2 存在性判断与创建目录// java.io.File 写法 File dir new File(/tmp/a/b/c); boolean exists dir.exists(); boolean ok dir.mkdirs(); // java.nio.file 写法 Path dirPath Paths.get(/tmp/a/b/c); boolean exists Files.exists(dirPath); Files.createDirectories(dirPath); // 失败抛 IOException这里有个细节值得注意Files.createDirectories() 在目标已经存在且是目录时会直接静默返回不会抛异常但如果路径上某个中间节点是个普通文件就会抛 FileAlreadyExistsException。而 File.mkdirs() 在这个情况下只会返回 false你还要自己排查是哪个节点出了问题。所以凡是涉及多级目录创建的生产代码我都推荐 createDirectories()。4.3 删除与移动// java.io.File 写法 File f new File(/tmp/a.txt); boolean deleted f.delete(); // java.nio.file 写法 Path p Paths.get(/tmp/a.txt); Files.deleteIfExists(p); // 不存在不报错 Files.delete(p); // 不存在抛 NoSuchFileException移动文件的差异更典型。File.renameTo() 在 Windows 上目标已存在时大概率返回 false跨磁盘分区移动也经常失败NIO 的 Files.move() 可以通过 StandardCopyOption 明确控制行为Path src Paths.get(/tmp/a.txt); Path dst Paths.get(/tmp/b.txt); Files.move(src, dst, StandardCopyOption.REPLACE_EXISTING); // 需要原子移动时 Files.move(src, dst, StandardCopyOption.REPLACE_EXISTING, StandardCopyOption.ATOMIC_MOVE);ATOMIC_MOVE 的意思是让底层操作系统保证移动操作的原子性要么移动成功要么什么都不变不会出现移动到一半文件损坏的情况。这个选项在分布式缓存、日志轮转、配置发布这类场景里非常有用。File.renameTo() 提供不了这种保证。4.4 列目录与大目录性能差异File 的 listFiles() 是一次性把目录下的所有子项读进数组。目录里有十万个文件你的内存里就多十万个 File 对象。NIO 的 DirectoryStream 是惰性迭代// java.io.File 写法 File[] children dir.listFiles(); // java.nio.file 写法 try (DirectoryStreamPath stream Files.newDirectoryStream(dirPath)) { for (Path child : stream) { System.out.println(child.getFileName()); } }DirectoryStream 实现了 Closeable放在 try-with-resources 里用遍历完自动关闭底层句柄。DirectoryStream 还支持过滤器比如只拿 *.log 文件DirectoryStream.FilterPath logFilter entry - entry.getFileName().toString().endsWith(.log); try (DirectoryStreamPath stream Files.newDirectoryStream(dirPath, logFilter)) { for (Path child : stream) { System.out.println(child); } }这样筛选逻辑在读取阶段就完成不会先建一堆 Path 对象再手动过滤。4.5 读取属性与修改时间// java.io.File 写法 File f new File(/tmp/a.log); long size f.length(); long last f.lastModified(); boolean flag f.isDirectory(); // java.nio.file 写法 Path p Paths.get(/tmp/a.log); long size Files.size(p); FileTime last Files.getLastModifiedTime(p); boolean flag Files.isDirectory(p); BasicFileAttributes attrs Files.readAttributes(p, BasicFileAttributes.class); System.out.println(attrs.lastModifiedTime().toMillis()); System.out.println(attrs.size()); System.out.println(attrs.isSymbolicLink());File.lastModified() 返回的是 long 毫秒值NIO 返回 FileTime可以直接跟 Instant 互转语义上更现代。readAttributes() 则一次把基本属性读进来比一个个方法调用的性能要好而且在判断目录拿大小拿时间这种复合场景不用多次系统调用。5. 一段真实迁移老代码清理临时文件从 File 改成 NIO5.1 原始代码的问题我在一个遗留项目里见过这样的清理任务把某个临时目录下超过 7 天没动过的文件删掉。代码用的是纯 Filepublic void cleanTempDir(String dirPath) { File dir new File(dirPath); if (!dir.exists() || !dir.isDirectory()) { return; } File[] files dir.listFiles(); if (files null) { return; } long deadline System.currentTimeMillis() - 7L * 24 * 3600 * 1000; for (File file : files) { if (file.isFile() file.lastModified() deadline) { boolean ok file.delete(); if (!ok) { System.err.println(删除失败: file.getAbsolutePath()); } } } }这段代码的问题我已经在前面提到了删除失败只能打印路径不知道原因listFiles() 一次加载全部子项大目录内存吃紧如果目录恰好有个子目录这个逻辑还会漏掉因为没写递归。5.2 改写成 java.nio.file 的思路改写的时候我不打算把每个方法机械替换而是按 NIO 的哲学重新组织用 Path 表示目录用 DirectoryStream 做惰性遍历用异常捕获区分失败原因用 try-with-resources 确保句柄释放。public void cleanTempDir(String dirPath) { Path dir Paths.get(dirPath); if (!Files.isDirectory(dir)) { return; } long deadline System.currentTimeMillis() - 7L * 24 * 3600 * 1000; try (DirectoryStreamPath stream Files.newDirectoryStream(dir)) { for (Path entry : stream) { if (!Files.isRegularFile(entry)) { continue; } try { FileTime lastModified Files.getLastModifiedTime(entry); if (lastModified.toMillis() deadline) { Files.delete(entry); System.out.println(已清理: entry); } } catch (IOException e) { System.err.println(清理失败: entry 原因: e.getMessage()); } } } catch (IOException e) { System.err.println(无法打开目录: dir 原因: e.getMessage()); } }改动不大但收益明显目录打不开、单个文件删除失败都有了可读的原因文件句柄通过 try-with-resources 自动释放遍历过程中不产生完整的中间对象集合。5.3 迁移中最容易忽视的几个差异这段迁移看起来平滑但有几个坑我是在生产环境踩过之后才记住的。第一Files.deleteIfExists() 在文件不存在时返回 true 而不是抛异常而 Files.delete() 会抛 NoSuchFileException。两个方法名称相近语义完全不同写代码时容易混。清理类任务用 deleteIfExists 更省心。第二Files.getLastModifiedTime() 默认会跟随符号链接。如果你在清理符号链接本身得加 LinkOption.NOFOLLOW_LINKSFileTime last Files.getLastModifiedTime(entry, LinkOption.NOFOLLOW_LINKS);第三Files.move() 不带 REPLACE_EXISTING 时目标存在会抛 FileAlreadyExistsException带了 REPLACE_EXISTING 也不是万能目标是非空目录时仍然会失败。老代码里 renameTo 失败只是 false你根本不知道是哪种情况NIO 的异常信息能帮你省掉半天排查时间。第四路径表示在 Windows 上的 toString() 结果不同。File 的 toString() 会输出反斜杠Path 的 toString() 会保留传入时的格式但实现上底层都处理了分隔符。写日志、拼 shell 命令时不要依赖某个固定的分隔符样式。6. 什么场景必须用 NIOFile 死活做不到的事6.1 目录监听WatchService这是 File 完全缺失的能力。你想监控某个目录下有没有新文件进来、文件有没有被修改用 File 只能写一个轮询线程每隔几秒 listFiles() 一次对比差异又笨又慢。NIO 的 WatchService 是操作系统级别的文件事件通知WatchService watcher FileSystems.getDefault().newWatchService(); Path dir Paths.get(/tmp/data); dir.register(watcher, StandardWatchEventKinds.ENTRY_CREATE, StandardWatchEventKinds.ENTRY_DELETE, StandardWatchEventKinds.ENTRY_MODIFY); while (true) { WatchKey key watcher.take(); // 阻塞等待事件 for (WatchEvent? event : key.pollEvents()) { System.out.println(event.kind() : event.context()); } if (!key.reset()) { break; } }在文件上传服务、配置文件热加载、日志文件滚动这类需求上WatchService 是标配。用 File 轮询能达到同样的业务效果但延迟、CPU 开销、代码复杂度都没法比。6.2 符号链接处理与真实路径解析NIO 对符号链接的支持是完整的。Files.isSymbolicLink() 判断某个路径是不是链接Files.readSymbolicLink() 读取链接目标Files.toRealPath() 解析出最终的物理路径Path link Paths.get(/tmp/link-to-app); if (Files.isSymbolicLink(link)) { Path target Files.readSymbolicLink(link); System.out.println(链接指向: target); } Path real link.toRealPath(); System.out.println(真实路径: real);File 时代判断符号链接基本靠 getCanonicalPath() 和 getAbsolutePath() 是否相同来间接推断代码既不直观又有误判风险。需要处理软链、快捷方式、或者要做路径去重安全的场景NIO 是唯一正道。6.3 原子移动与复制策略控制配置发布、日志轮转、临时文件转正这类场景要求要么不动要么一步到位。Files.move() 带 ATOMIC_MOVE 就能做到File 的 renameTo() 没有这个选项。复制也一样Files.copy() 支持Files.copy(source, target, StandardCopyOption.REPLACE_EXISTING, StandardCopyOption.COPY_ATTRIBUTES);COPY_ATTRIBUTES 会把修改时间、权限等属性一并复制过去File 时代你想同步一个文件的修改时间得先复制内容再手动 setLastModified复制完后时间戳还不一定对得上。6.4 目录树遍历和流式读取大文件统计一个项目目录下所有 .java 文件的代码行数NIO 写法紧凑得多try (var paths Files.walk(Paths.get(/tmp/project))) { long lines paths .filter(Files::isRegularFile) .filter(p - p.toString().endsWith(.java)) .mapToLong(p - { try { try (var lineStream Files.lines(p, StandardCharsets.UTF_8)) { return lineStream.count(); } } catch (IOException e) { return 0L; } }) .sum(); System.out.println(总行数: lines); }Files.walk() 返回 Stream走的是深度优先遍历默认不跟随符号链接天然避免递归环。Files.lines() 则是惰性读取处理几百 MB 的日志文件时内存占用很小。这里特别强调一下Files.walk() 和 Files.lines() 返回的 Stream 都必须关闭否则底层文件句柄会泄露所以代码里一定要用 try-with-resources 包住。File 要复刻这段逻辑得自己写递归加 BufferedReader 循环代码量翻倍还得时刻提防递归深度问题。7. 一点点个人体会做完了这一轮对比我自己现在的编码习惯是所有新代码默认走 java.nio.fileFile 只出现在极少数场景比如只需要调一次 exists() 判断、跟老接口参数兼容的过渡代码。真遇到存量代码也不用一步到位地重写最平滑的方式是先给 File 对象调 toPath()把路径层切到 Path再逐方法替换操作这样每一步都是可测试的增量改动。如果你是在准备面试抓住职责分离 异常反馈 高级能力这条主线再配合两三个对比代码例子已经足够把这个问题讲透。这篇是功能层面对比的第一部分主要把 API 设计和常用操作讲清楚了。下一篇我准备专门聊性能大文件复制的两种写法的效率差异、ByteBuffer 与 Stream 的组合玩法、还有 FileChannel 的文件锁这些才是生产环境里真正分高下的地方。 Java文件操作新旧API对比：从java.io到NIO实战
每次面试问到 Java 文件操作我都能看到候选人脸上的犹豫java.io.File 的常用方法他能背得滚瓜烂熟可一旦把问题延伸到符号链接、跨平台路径分隔符、失败原因反馈这些细节十个里有七八个开始含糊。今天这篇我把 Java 里两套文件操作 API——java.io.File 和 java.nio.file——放到一张桌上逐项对比。内容来自我去年把一整套老项目从 java.io 迁移到 java.nio.file 的真实过程适合正在做 Java 文件处理、准备面试、或者准备接手老代码改造的人。看完你会清楚什么场景继续用 File 没毛病什么场景不换 NIO 迟早出事。1. 先谈定位两套 API 到底是不是替代关系1.1 时间线一个 1996 年的类和一个 2011 年的接口java.io.File 从 JDK 1.0 就有了也就是说这套 API 已经活了二十多年大量遗留系统、开源库里到处都是它的身影。而 java.nio.file 是 JDK 7 引入的 NIO.2 的一部分核心是 Path 接口和 Files 工具类从出生那天起就带着取代 File的任务。但你要真追问一句那 File 是不是废了我的回答是没废但适用面在肉眼可见地缩小。JDK 官方文档对 File 的定位其实写得很委婉大意是这个类有很多方法但使用上会有不少平台相关的坑推荐用 NIO.2 替代。这句话翻译成大白话就是能用新的就别用旧的。1.2 设计思路的根本差异一个把路径和操作揉在一起一个彻底拆开java.io.File 最大的问题不是功能少而是职责混乱。一个 File 对象既表示一个路径位置又直接在这个对象上挂了一堆操作方法exists()、mkdirs()、delete()、renameTo()……你拿着这个对象分不清自己是站在路径层还是文件系统层。更要命的是它内部把路径字符串和文件系统操作耦合在一起导致很多行为在不同操作系统上表现不一致。java.nio.file 的思路是彻底拆分Path 只负责描述路径它不关心这个路径在磁盘上是否存在也不负责创建、删除任何东西。Files 是一个纯静态工具类把对路径的所有操作都收拢到这里比如 Files.createDirectories()、Files.delete()、Files.move()。FileSystem 负责抽象底层的文件系统实现默认是操作系统自带的也可以通过厂商扩展。这套设计的好处很明显Path 可以作为一个轻量的位置引用在不同方法间传递操作什么时候做、由谁做调用方心里一清二楚。而且因为路径和操作解耦JDK 还能基于同一套接口去支持 zip 文件系统、自定义虚拟文件系统这是 File 完全做不到的。如果你在面试中被问两套 API 什么区别最稳妥的答法就是先说职责分离再补一句异常设计这两点说完基本就能把考官带走。2. java.io.File 的能力清单以及它洗不掉的四笔旧账2.1 先看它能干什么一段最常用的代码客观说java.io.File 覆盖日常七八成需求是没问题的。下面这段代码是典型的老式文件操作合集建目录、建文件、重命名、列目录、拿大小。import java.io.File; import java.io.IOException; public class FileDemo { public static void main(String[] args) throws IOException { File dir new File(/tmp/data/archive); if (!dir.exists()) { boolean ok dir.mkdirs(); System.out.println(创建目录结果: ok); } File log new File(dir, run.log); if (!log.exists()) { boolean ok log.createNewFile(); System.out.println(创建文件结果: ok); } File bak new File(dir, run.log.bak); if (log.renameTo(bak)) { System.out.println(重命名成功); } File[] children dir.listFiles(); if (children ! null) { for (File child : children) { System.out.println(child.getName() - child.length() bytes); } } } }这段代码在单机上跑起来确实没什么毛病。可一旦进入生产环境、多系统部署、大目录、权限受限的场景File 那套返回布尔值的设计就处处掣肘。下面四个旧账是我在实际项目中真实踩过的。2.2 旧账一失败只有 false没有原因File 的方法几乎清一色返回 boolean这看起来简单但恰恰是最坑的地方。dir.mkdirs() 返回 false你是该猜父目录不存在、权限不够、还是路径上已经有一个同名文件file.renameTo() 返回 false你是该猜目标文件已存在、源文件被占用、还是跨文件系统不支持你没有任何线索。我印象最深的一次是 Windows 上一个 renameTo() 间歇性失败排查了半天才发现是杀毒软件正在扫描源文件。File 返回的 false 连个错误码都没有日志里只能记录重命名失败根本没法写准确的告警信息。换成 NIO 之后Files.move() 会明确抛 NoSuchFileException、FileAlreadyExistsException、AccessDeniedException异常栈一打出来就知道是哪一层出的问题。所以我的建议是凡是需要失败原因、需要给用户反馈、需要做重试逻辑的场景一律不要用 File 的 boolean 返回值。2.3 旧账二跨平台路径处理全靠自觉路径分隔符是 File 最经典的坑。Windows 用反斜杠 \Linux/macOS 用正斜杠 /。File 在设计上提供了 File.separator 和 File.separatorChar但问题是——你不调用它就等于没有。代码里随手写一个 new File(data \ archive)在 Linux 上跑就是一个带反斜杠的怪文件名。更隐蔽的是 getAbsolutePath() 和 getCanonicalPath() 的区别。getAbsolutePath() 只是把当前工作目录拼在前面路径里的 . 和 .. 原封不动getCanonicalPath() 会做规范化解析把 . 和 .. 消掉还会在 Unix 上解析符号链接。很多老代码里拿 getAbsolutePath() 去比路径、做去重结果因为带 .. 或者符号链接两个逻辑上相同的文件被当成两个路径问题极难复现。这个坑的解法其实简单别手动拼分隔符直接 new File(parent, child) 或者用 Paths.get(data, archive)让底层文件系统自己去处理分隔符。2.4 旧账三元数据和符号链接基本是瞎子File 对文件属性的支持停留在粗略感知级别length() 拿大小、lastModified() 拿时间戳、isFile()/isDirectory() 判断类型、canRead()/canWrite() 判断权限。但这个感知很浅比如 isDirectory() 在符号链接指向目录时也会返回 true你根本判断不了这个路径本身是不是一个符号链接。NIO 里一个 Files.isSymbolicLink(path) 就把这个问题说清楚了还能通过 Files.readSymbolicLink(path) 把链接目标取出来。如果老代码要判断路径是不是快捷方式/软链File 只能靠 getCanonicalPath() 和 getAbsolutePath() 是否一致来猜非常别扭。2.5 旧账四递归遍历只能手写还得提心吊胆File 没有内置的目录树遍历能力。要遍历一个目录下所有文件你得自己写递归public void walk(File dir) { File[] children dir.listFiles(); if (children null) { return; } for (File child : children) { if (child.isDirectory()) { walk(child); } else { System.out.println(child.getAbsolutePath()); } } }这段代码看着没毛病但生产环境里目录层级深、目录数量多时问题全来了listFiles() 一次性把子项全部加载成数组大目录内存开销高递归调用层数深了有栈溢出风险遇到符号链接环更是直接无限递归。而 NIO 的 Files.walk() 和 Files.walkFileTree() 把遍历包装得又稳又省心默认不跟随符号链接从根上绕开了循环递归问题。3. java.nio.file 三件套的设计与分工Path、Files、FileSystem3.1 Path 只是路径不是文件Path 是一个接口最简单的获取方式是 Paths.get() 或者 FileSystems.getDefault().getPath()。它只干一件事描述路径。Path base Paths.get(/tmp/data); Path log base.resolve(app.log); // /tmp/data/app.log Path sibling base.resolveSibling(backup); // /tmp/backup Path messy Paths.get(/tmp/data/../data/app.log); System.out.println(messy.normalize()); // /tmp/data/app.log Path abs log.toAbsolutePath(); // 转为绝对路径resolve 方法是 File 没有的便捷能力它相当于 new File(base, child)但语义更清晰。resolveSibling 在很多迁移场景里特别好用你要把 /tmp/data/app.log 旁边生成一个 .bak直接 base.resolveSibling(app.log.bak) 就完事了不用先 getParent() 再拼字符串。注意一个关键认知Path 不会触碰磁盘。你 new 一个 Path磁盘上有没有这个文件都无所谓它仅仅是一个位置。这跟 File 对象经常让人误以为new 出来就代表真实文件相比设计上干净得多。3.2 Files 是那个真正干活的工具类Files 是纯静态方法工具类风格跟 Collections 很像。常用的方法大概分几组判断类Files.exists()、Files.isDirectory()、Files.isRegularFile()、Files.isSymbolicLink()、Files.isReadable()创建类Files.createFile()、Files.createDirectory()、Files.createDirectories()、Files.createTempFile()删除移动类Files.delete()、Files.deleteIfExists()、Files.move()、Files.copy()读取类Files.size()、Files.getLastModifiedTime()、Files.readAttributes()、Files.readAllLines()、Files.lines()遍历类Files.list()、Files.walk()、Files.walkFileTree()、Files.newDirectoryStream()因为操作和路径分离方法可以做得非常专注。比如 Files.copy() 可以通过 StandardCopyOption.REPLACE_EXISTING、StandardCopyOption.COPY_ATTRIBUTES、StandardCopyOption.NOFOLLOW_LINKS 来控制覆盖、属性复制、是否跟随符号链接File 压根没有这种粒度控制。3.3 FileSystem 与 FileStore底层抽象带来的甜头FileSystem 是文件系统的抽象默认实现对应操作系统本身。日常开发里你用得最多的其实是 FileSystem.getPath() 和 FileSystem.getSeparator()。但 FileSystem 的存在意味着你可以有非默认的文件系统。最典型的例子就是 zip 文件系统try (FileSystem zipFs FileSystems.newFileSystem( Paths.get(/tmp/archive.zip), (ClassLoader) null)) { Path inside zipFs.getPath(/entry.txt); System.out.println(Files.exists(inside)); }这一段代码用 java.io.File 是无论如何写不出来的。你相当于把 zip 包当成一个文件系统去访问Files 的工具方法全部照用。对于处理压缩包、做资源打包格式解析的场景这个能力是降维打击。FileStore 则是描述存储卷的抽象能拿磁盘总空间、可用空间FileStore store Files.getFileStore(Paths.get(/tmp)); System.out.println(总空间: store.getTotalSpace()); System.out.println(可用空间: store.getUsableSpace());File 里没有任何对应的功能以前要做磁盘空间监控只能靠 Runtime 或系统命令。3.4 异常设计让调用者知道哪一步为什么失败NIO 把操作失败从返回 false改成了抛异常这个设计一开始会让人觉得麻烦写久了会真香。Files 的方法声明抛 IOException在其下有这些明确的子类NoSuchFileException目标不存在FileAlreadyExistsException目标已存在AccessDeniedException权限不足DirectoryNotEmptyException目录非空AtomicMoveNotSupportedException底层文件系统不支持原子移动你可以精确捕获做差异化处理。比如清理临时目录时某个文件被占用抛 AccessDeniedException你可以单独记一条 WARN 日志继续处理下一个文件而不用像 File 时代那样面对一个 false 干瞪眼。try { Files.deleteIfExists(Paths.get(/tmp/lock.txt)); } catch (NoSuchFileException e) { // 已经不存在当作成功 } catch (AccessDeniedException e) { System.err.println(没权限删除: e.getFile()); } catch (IOException e) { System.err.println(其他删除错误: e.getMessage()); }这种分层异常在日常运维里价值极高日志里出现 AccessDeniedException一搜就知道是权限问题不需要再人工排查。4. 同一个操作两套写法的逐项对照4.1 总览对照表先放一张总表把最常见的场景列清楚后面再逐个展开。操作java.io.File 写法java.nio.file 写法备注判断存在file.exists()Files.exists(path)NIO 默认跟随符号链接创建单层目录file.mkdir()Files.createDirectory(path)父目录不存在会抛异常创建多层目录file.mkdirs()Files.createDirectories(path)File 返回 falseNIO 抛异常创建文件file.createNewFile()Files.createFile(path)已存在时 NIO 抛 FileAlreadyExistsException删除file.delete() 返回 booleanFiles.delete / deleteIfExistsNIO 失败带具体异常重命名/移动file.renameTo(target)Files.move(...)跨文件系统、覆盖策略差异巨大列出子项file.listFiles() 返回数组Files.newDirectoryStream 返回流NIO 是惰性迭代文件大小file.length()Files.size(path)最后修改时间file.lastModified()Files.getLastModifiedTime返回 FileTime符号链接不支持Files.isSymbolicLink / readSymbolicLink目录树遍历手写递归Files.walk / walkFileTree监听目录变化不支持WatchService磁盘空间不支持FileStore4.2 存在性判断与创建目录// java.io.File 写法 File dir new File(/tmp/a/b/c); boolean exists dir.exists(); boolean ok dir.mkdirs(); // java.nio.file 写法 Path dirPath Paths.get(/tmp/a/b/c); boolean exists Files.exists(dirPath); Files.createDirectories(dirPath); // 失败抛 IOException这里有个细节值得注意Files.createDirectories() 在目标已经存在且是目录时会直接静默返回不会抛异常但如果路径上某个中间节点是个普通文件就会抛 FileAlreadyExistsException。而 File.mkdirs() 在这个情况下只会返回 false你还要自己排查是哪个节点出了问题。所以凡是涉及多级目录创建的生产代码我都推荐 createDirectories()。4.3 删除与移动// java.io.File 写法 File f new File(/tmp/a.txt); boolean deleted f.delete(); // java.nio.file 写法 Path p Paths.get(/tmp/a.txt); Files.deleteIfExists(p); // 不存在不报错 Files.delete(p); // 不存在抛 NoSuchFileException移动文件的差异更典型。File.renameTo() 在 Windows 上目标已存在时大概率返回 false跨磁盘分区移动也经常失败NIO 的 Files.move() 可以通过 StandardCopyOption 明确控制行为Path src Paths.get(/tmp/a.txt); Path dst Paths.get(/tmp/b.txt); Files.move(src, dst, StandardCopyOption.REPLACE_EXISTING); // 需要原子移动时 Files.move(src, dst, StandardCopyOption.REPLACE_EXISTING, StandardCopyOption.ATOMIC_MOVE);ATOMIC_MOVE 的意思是让底层操作系统保证移动操作的原子性要么移动成功要么什么都不变不会出现移动到一半文件损坏的情况。这个选项在分布式缓存、日志轮转、配置发布这类场景里非常有用。File.renameTo() 提供不了这种保证。4.4 列目录与大目录性能差异File 的 listFiles() 是一次性把目录下的所有子项读进数组。目录里有十万个文件你的内存里就多十万个 File 对象。NIO 的 DirectoryStream 是惰性迭代// java.io.File 写法 File[] children dir.listFiles(); // java.nio.file 写法 try (DirectoryStreamPath stream Files.newDirectoryStream(dirPath)) { for (Path child : stream) { System.out.println(child.getFileName()); } }DirectoryStream 实现了 Closeable放在 try-with-resources 里用遍历完自动关闭底层句柄。DirectoryStream 还支持过滤器比如只拿 *.log 文件DirectoryStream.FilterPath logFilter entry - entry.getFileName().toString().endsWith(.log); try (DirectoryStreamPath stream Files.newDirectoryStream(dirPath, logFilter)) { for (Path child : stream) { System.out.println(child); } }这样筛选逻辑在读取阶段就完成不会先建一堆 Path 对象再手动过滤。4.5 读取属性与修改时间// java.io.File 写法 File f new File(/tmp/a.log); long size f.length(); long last f.lastModified(); boolean flag f.isDirectory(); // java.nio.file 写法 Path p Paths.get(/tmp/a.log); long size Files.size(p); FileTime last Files.getLastModifiedTime(p); boolean flag Files.isDirectory(p); BasicFileAttributes attrs Files.readAttributes(p, BasicFileAttributes.class); System.out.println(attrs.lastModifiedTime().toMillis()); System.out.println(attrs.size()); System.out.println(attrs.isSymbolicLink());File.lastModified() 返回的是 long 毫秒值NIO 返回 FileTime可以直接跟 Instant 互转语义上更现代。readAttributes() 则一次把基本属性读进来比一个个方法调用的性能要好而且在判断目录拿大小拿时间这种复合场景不用多次系统调用。5. 一段真实迁移老代码清理临时文件从 File 改成 NIO5.1 原始代码的问题我在一个遗留项目里见过这样的清理任务把某个临时目录下超过 7 天没动过的文件删掉。代码用的是纯 Filepublic void cleanTempDir(String dirPath) { File dir new File(dirPath); if (!dir.exists() || !dir.isDirectory()) { return; } File[] files dir.listFiles(); if (files null) { return; } long deadline System.currentTimeMillis() - 7L * 24 * 3600 * 1000; for (File file : files) { if (file.isFile() file.lastModified() deadline) { boolean ok file.delete(); if (!ok) { System.err.println(删除失败: file.getAbsolutePath()); } } } }这段代码的问题我已经在前面提到了删除失败只能打印路径不知道原因listFiles() 一次加载全部子项大目录内存吃紧如果目录恰好有个子目录这个逻辑还会漏掉因为没写递归。5.2 改写成 java.nio.file 的思路改写的时候我不打算把每个方法机械替换而是按 NIO 的哲学重新组织用 Path 表示目录用 DirectoryStream 做惰性遍历用异常捕获区分失败原因用 try-with-resources 确保句柄释放。public void cleanTempDir(String dirPath) { Path dir Paths.get(dirPath); if (!Files.isDirectory(dir)) { return; } long deadline System.currentTimeMillis() - 7L * 24 * 3600 * 1000; try (DirectoryStreamPath stream Files.newDirectoryStream(dir)) { for (Path entry : stream) { if (!Files.isRegularFile(entry)) { continue; } try { FileTime lastModified Files.getLastModifiedTime(entry); if (lastModified.toMillis() deadline) { Files.delete(entry); System.out.println(已清理: entry); } } catch (IOException e) { System.err.println(清理失败: entry 原因: e.getMessage()); } } } catch (IOException e) { System.err.println(无法打开目录: dir 原因: e.getMessage()); } }改动不大但收益明显目录打不开、单个文件删除失败都有了可读的原因文件句柄通过 try-with-resources 自动释放遍历过程中不产生完整的中间对象集合。5.3 迁移中最容易忽视的几个差异这段迁移看起来平滑但有几个坑我是在生产环境踩过之后才记住的。第一Files.deleteIfExists() 在文件不存在时返回 true 而不是抛异常而 Files.delete() 会抛 NoSuchFileException。两个方法名称相近语义完全不同写代码时容易混。清理类任务用 deleteIfExists 更省心。第二Files.getLastModifiedTime() 默认会跟随符号链接。如果你在清理符号链接本身得加 LinkOption.NOFOLLOW_LINKSFileTime last Files.getLastModifiedTime(entry, LinkOption.NOFOLLOW_LINKS);第三Files.move() 不带 REPLACE_EXISTING 时目标存在会抛 FileAlreadyExistsException带了 REPLACE_EXISTING 也不是万能目标是非空目录时仍然会失败。老代码里 renameTo 失败只是 false你根本不知道是哪种情况NIO 的异常信息能帮你省掉半天排查时间。第四路径表示在 Windows 上的 toString() 结果不同。File 的 toString() 会输出反斜杠Path 的 toString() 会保留传入时的格式但实现上底层都处理了分隔符。写日志、拼 shell 命令时不要依赖某个固定的分隔符样式。6. 什么场景必须用 NIOFile 死活做不到的事6.1 目录监听WatchService这是 File 完全缺失的能力。你想监控某个目录下有没有新文件进来、文件有没有被修改用 File 只能写一个轮询线程每隔几秒 listFiles() 一次对比差异又笨又慢。NIO 的 WatchService 是操作系统级别的文件事件通知WatchService watcher FileSystems.getDefault().newWatchService(); Path dir Paths.get(/tmp/data); dir.register(watcher, StandardWatchEventKinds.ENTRY_CREATE, StandardWatchEventKinds.ENTRY_DELETE, StandardWatchEventKinds.ENTRY_MODIFY); while (true) { WatchKey key watcher.take(); // 阻塞等待事件 for (WatchEvent? event : key.pollEvents()) { System.out.println(event.kind() : event.context()); } if (!key.reset()) { break; } }在文件上传服务、配置文件热加载、日志文件滚动这类需求上WatchService 是标配。用 File 轮询能达到同样的业务效果但延迟、CPU 开销、代码复杂度都没法比。6.2 符号链接处理与真实路径解析NIO 对符号链接的支持是完整的。Files.isSymbolicLink() 判断某个路径是不是链接Files.readSymbolicLink() 读取链接目标Files.toRealPath() 解析出最终的物理路径Path link Paths.get(/tmp/link-to-app); if (Files.isSymbolicLink(link)) { Path target Files.readSymbolicLink(link); System.out.println(链接指向: target); } Path real link.toRealPath(); System.out.println(真实路径: real);File 时代判断符号链接基本靠 getCanonicalPath() 和 getAbsolutePath() 是否相同来间接推断代码既不直观又有误判风险。需要处理软链、快捷方式、或者要做路径去重安全的场景NIO 是唯一正道。6.3 原子移动与复制策略控制配置发布、日志轮转、临时文件转正这类场景要求要么不动要么一步到位。Files.move() 带 ATOMIC_MOVE 就能做到File 的 renameTo() 没有这个选项。复制也一样Files.copy() 支持Files.copy(source, target, StandardCopyOption.REPLACE_EXISTING, StandardCopyOption.COPY_ATTRIBUTES);COPY_ATTRIBUTES 会把修改时间、权限等属性一并复制过去File 时代你想同步一个文件的修改时间得先复制内容再手动 setLastModified复制完后时间戳还不一定对得上。6.4 目录树遍历和流式读取大文件统计一个项目目录下所有 .java 文件的代码行数NIO 写法紧凑得多try (var paths Files.walk(Paths.get(/tmp/project))) { long lines paths .filter(Files::isRegularFile) .filter(p - p.toString().endsWith(.java)) .mapToLong(p - { try { try (var lineStream Files.lines(p, StandardCharsets.UTF_8)) { return lineStream.count(); } } catch (IOException e) { return 0L; } }) .sum(); System.out.println(总行数: lines); }Files.walk() 返回 Stream走的是深度优先遍历默认不跟随符号链接天然避免递归环。Files.lines() 则是惰性读取处理几百 MB 的日志文件时内存占用很小。这里特别强调一下Files.walk() 和 Files.lines() 返回的 Stream 都必须关闭否则底层文件句柄会泄露所以代码里一定要用 try-with-resources 包住。File 要复刻这段逻辑得自己写递归加 BufferedReader 循环代码量翻倍还得时刻提防递归深度问题。7. 一点点个人体会做完了这一轮对比我自己现在的编码习惯是所有新代码默认走 java.nio.fileFile 只出现在极少数场景比如只需要调一次 exists() 判断、跟老接口参数兼容的过渡代码。真遇到存量代码也不用一步到位地重写最平滑的方式是先给 File 对象调 toPath()把路径层切到 Path再逐方法替换操作这样每一步都是可测试的增量改动。如果你是在准备面试抓住职责分离 异常反馈 高级能力这条主线再配合两三个对比代码例子已经足够把这个问题讲透。这篇是功能层面对比的第一部分主要把 API 设计和常用操作讲清楚了。下一篇我准备专门聊性能大文件复制的两种写法的效率差异、ByteBuffer 与 Stream 的组合玩法、还有 FileChannel 的文件锁这些才是生产环境里真正分高下的地方。