Java NIO与DotNet IO性能

Question

有人知道Java NIO和DotNet IO性能之间的性能差异吗？

阅读this问题，似乎标准的Java-IO和DotNet-IO有非常相似的IO性能。

我感兴趣的是，Java的家伙们说，由于可以访问Java-NIO中的文件通道等，基于文件服务器的operations...etc应该会更快。

有没有可能java.nio性能比DotNet System.IO更好。

谢谢。

Answer 1

就文件复制而言，无论您使用的是什么平台或api，都不应该有明显的差异。瓶颈是硬盘驱动器的磁盘旋转和磁头寻道。*

需要做的是将硬盘中的内容移动到某个内存中，然后将内存写入硬盘。对于传统的java io流，会有额外的内存拷贝。尽管如此，与磁盘速度相比，这并不是很大的浪费。

这很容易验证，FileChannel.transfer by /From不能大大超过输入-输出流复制的旧方法。

(*)当然，现在有更快的磁盘，但只要我们将磁盘定义为内存之后的下一个较慢的存储，这个论点就成立了。

(**)我们可以将虚拟磁盘称为磁盘，它实际上驻留在主内存中。那么内存复制就是瓶颈，这个论点就不再成立了。

Answer 2

我实际上不能回答这个问题，但我可以自由地思考…

。。Java- file -IO和.Net都应该使用底层操作系统操作进行文件访问，并且文件访问始终是IO绑定的，而不是CPU绑定的。这意味着磁盘比CPU和内存更慢。

这意味着Java-File-IO和.Net在性能方面应该是相同的。

当涉及到套接字通信时，Java做了一件可怕的工作，实际上只是忽略了Posix标准，并且没有使用操作系统调用'select‘。这在Java NIO中通过引入“通道”得到了修复，“通道”实际上只是支持底层架构。在你需要为你正在读的每个套接字分配一个线程之前，可怕的资源浪费。

由于.Net比Java更新，我相信他们从来没有落入这个陷阱，并从一开始就增加了对它的支持。但是我没有用过.Net，所以我能看出来，我猜不出来。

对于两种情况下的套接字通信，Java-NIO和.Net System.IO都应该是网络绑定的，然后才能成为CPU绑定的。所以我不认为其中一个会比另一个快。