使用文件和文件系统:在使用NIO之前，使用NIO，在未来使用NIO2

Question

在Java1.4之前，通过在不同的InputStreams/OutputStreams之间移动字节来处理文件是一种常见的做法。

由于Java1.4中添加了NIO，因此建议使用通道来做同样的事情。

在Java7中的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执行某些操作时，我看不到有任何用例可以让旧的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。它们通常更擅长处理符号链接之类的边角情况。它们也更有可能直接构建在操作系统原语之上，这将提供更好的硬件利用率。因此，对您的问题的简短回答是“是的，旧的几乎是无用的”。新apis的最大缺点是它们需要安装较新的JRE。

Answer 3

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

当然，新的NIO会比之前的版本更好。在旧的file io类中有很多限制。我从C++搬到了后台，发现尽管Apis更容易使用，但它们缺乏很多功能。现在，如果您查看类，如果您尝试查询远程目录，您可能会看到一些缓慢或您的JVM可能挂起。在7中修复了这个问题。还需要注意的是，一些文件系统支持符号链接，并提供了相应的处理方法。正在为目录列表添加迭代器，并且它还将支持POSIX和ACL控制模型。