NIO.1的目标应该是非阻塞,以实现事件驱动机制。不过原来的io已经用新io重新实现过。这样的话,通常不需要使用new io。

解决方案 »

  1.   

    我暂时没有空实验,不过看上去NIO用的是随机读写,旧IO用的是顺序读写,两者本来就不能比较。你用FileChannel试试看,速度应该差不多的
      

  2.   

    FileChannel我用了,比原io慢一点,慢不了很多,构不成数量级。
    NIO用的是随机读写,这个随机读写,我不清楚。
      

  3.   

    请弄个2G的文件去实验另外还要注意一下JVM内存NIO使用的JVM内存很有意思
      

  4.   

    文件读写体现不了nio的优势。在使用socket高并发网络通信的时候,你就会知道nio比io的性能高很多。
      

  5.   

    文件的io和nio读写速度没有太大区别。
      

  6.   

    我的这个测试,是针对这样一个情况,对于通常的需求,文本文件和图片等的读写。有的帖子(不一定是csdn的)动不动就让用nio(代替io)。因此,对于处理大文件,我没有做测试。不过在理论上,使用io如果程序写的得当,速度对比类似小文件的可能性不能排除。当然这需要测试才能下结论。另外,这里只是研究性能,在功能上,对于大文件,nio的内存映射比io的RandomAccessFile的功能要多一点。我的测试的目的就是说明应该把普通读写与需要非阻塞以及异步的场景分开。本地文件的读写,非阻塞和异步没有什么好处。
      

  7.   

    nio主要还是在网络io这一块对性能的提升比较明显,是来自于线程模型的进步,这一点是毋庸置疑的另外文件io的话,我记得nio里好像有一个方法可以把小文件map到内存来操作,这个api旧io里好像是没有的,这个api对性能的帮助也比较大
      

  8.   

    需要多个点读写的场景,推荐nio。只需顺序读写的话就回到这个话题了。
      

  9.   

    我的这个测试,是针对这样一个情况,对于通常的需求,文本文件和图片等的读写。有的帖子(不一定是csdn的)动不动就让用nio(代替io)。因此,对于处理大文件,我没有做测试。不过在理论上,使用io如果程序写的得当,速度对比类似小文件的可能性不能排除。当然这需要测试才能下结论。另外,这里只是研究性能,在功能上,对于大文件,nio的内存映射比io的RandomAccessFile的功能要多一点。我的测试的目的就是说明应该把普通读写与需要非阻塞以及异步的场景分开。本地文件的读写,非阻塞和异步没有什么好处。
    额,,,我说的内存不是指内存映射,,,,我是说NIO使用的内存很有意思的,,你可以研究一下,,这也是为什么用NIO处理大文件的一个点
      

  10.   

    NIO不是为了快,特别是单线程环境中测试根本没有意义。