相关疑难解决方法(0)

我试图弄清楚当我们使用nio FileChannel与普通FileInputStream/FileOuputStream文件读取和写入文件系统时,性能(或优势)是否有任何差异.我观察到,在我的机器上,两者都在同一级别执行,也很多次FileChannel都是慢一些.我可以了解比较这两种方法的更多细节.这是我使用的代码,我正在测试的文件是350MB.如果我不是在查看随机访问或其他此类高级功能,那么对文件I/O使用基于NIO的类是一个不错的选择吗？

package trialjavaprograms;

import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.InputStream;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;

public class JavaNIOTest {
    public static void main(String[] args) throws Exception {
        useNormalIO();
        useFileChannel();
    }

    private static void useNormalIO() throws Exception {
        File file = new File("/home/developer/test.iso");
        File oFile = new File("/home/developer/test2");

        long time1 = System.currentTimeMillis();
        InputStream is = new FileInputStream(file);
        FileOutputStream fos = new FileOutputStream(oFile);
        byte[] buf = new byte[64 * 1024];
        int len = 0; …

考虑应用程序,它创建5-6个线程,循环中的每个线程为5mb页面大小分配MappedByteBuffer.

MappedByteBuffer b = ch.map(FileChannel.MapMode.READ_ONLY, r, 1024*1024*5);

迟早,当应用程序使用大文件时,会抛出oom

java.io.IOException: Map failed  at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:758)
Caused by: java.lang.OutOfMemoryError: Map failed
        at sun.nio.ch.FileChannelImpl.map0(Native Method)
        at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:755)

根据规范,MappedBuffer应该在GC本身时立即配置直接内存.看起来问题是,MappedBuffer-s的GC编辑太晚了,后来直接内存完成了.

如何避免这种情况？可能会说MappedBuffer隐式处理或使用某种MappedBuffer池