使用文件和文件系统：在NIO之前，将来使用NIO和NIO2

Question

在Java 1.4之前，通常的做法是通过在不同的InputStreams / OutputStream之间移动字节来处理文件。

自Java 1.4起添加NIO以来，建议使用Channels来做同样的事情。

在Java 7中使用NIO2，java.nio.file中还有另一个API支持像

这样的操作

val source = Paths.get("fooDir/fooFile.txt")
val target = Paths.get("barDir/barFile.txt")
source moveTo target
source createLinkTo target

older ones more or less useless现在是否适用于文件系统操作，除非你想手动触摸字节？

Answer 1

对于大多数操作，NIO2会让你做得更多/更好。

使用旧版API（某些属性，ACL，文件更改通知，更好的错误处理......）无法进行某些操作。

最重要的是：这不一定更难。

回答你的问题：当你可以用两种不同的API做一些操作时，我没有看到任何旧的用例可以做得更好的用例。

有一些讨论：

Java NIO FileChannel versus FileOutputstream performance / usefulness http://mailinator.blogspot.com/2008/02/kill-myth-please-nio-is-not-faster-than.html

但我会说设计的最新API 更快。如果他们在某些情况下不这样做，那么如果你一直在使用更新的API，那么期望jvm更新可以恢复这种情况，而不必更改任何代码。

Answer 2

最佳做法是尽可能使用较新的API。他们通常更善于处理像符号链接这样的角落案例。它们也更有可能直接构建在OS原语上，这将提供更好的硬件利用率。因此，对你的问题的简短回答是“是的，旧问题几乎没用”。新api的一大缺点是它们需要安装更新的JRE。

Answer 3

我会在这里加2美分。 @Ymajoros和@Matt总结得很好。

当然，新款NIO将比前辈更好。旧文件io类有很多限制。我从C ++转移到了地面，发现即使Apis更容易使用，它们也缺乏很多功能。现在，如果您查看类，如果您尝试查询远程目录，您可能会看到一些缓慢或您的JVM可能会挂起。这一点在7中得到修复。另外需要注意的是，某些文件系统支持符号链接，并且有处理它的规定。正在为目录列表添加迭代器，它也将支持POSIX和ACL控制模型。