慎用 MappedByteBuffer！

<script type="text/javascript"><!----></script>

最近使用MD5进行大文件验证，固使用NIO这种高效率的模式来进行文件映射：

FileInputStream in = new FileInputStream(file);
FileChannel ch = in.getChannel();
MappedByteBuffer byteBuffer = ch.map(FileChannel.MapMode.READ_ONLY, 0, file.length());
messageDigest.update(byteBuffer);
String md5 = bufferToHex(messageDigest.digest());
ch.close();
in.close();

本来想如果文件md5与数据库存储的值不同就删掉该文件的，结果出现了文件无法删除的情况。

抛出的违例

java.io.FileNotFoundException: E:\hello.jar (请求的操作无法在使用用户映射区域打开的文件上执行。)

后来经查，原来是当使用 FileChannel.map 方法时，MappedByteBuffer 已经在系统内占用了一个句柄，而使用 FileChannel.close 方法是无法释放这个句柄的，且FileChannel有没有提供类似 unmap 的方法，因此会出现无法删除文件的情况。

 

此问题一直让我很郁闷，后来到网上查询到两种方法...

 

第一种：

AccessController.doPrivileged(new PrivilegedAction() {
  public Object run() {
    try {
      Method getCleanerMethod = buffer.getClass().getMethod("cleaner", new Class[0]);
      getCleanerMethod.setAccessible(true);
      sun.misc.Cleaner cleaner = (sun.misc.Cleaner) 
      getCleanerMethod.invoke(byteBuffer, new Object[0]);
      cleaner.clean();
    } catch (Exception e) {
      e.printStackTrace();
    }
    return null;
  }
});

此种方法需要JDK支持，我用的是JRE 1.6，提示没有 sun.misc.Cleaner 类，JDK包太大，项目又不让用。

 

第二种方法是显性设置byteBuffer为null，并调用GC，没什么实际意义。

 

实在没招了，又回来使用InputStream了...

FileInputStream in = new FileInputStream(file);
ByteArrayOutputStream out = new ByteArrayOutputStream((int)file.length());
byte[] cache = new byte[1048576];
for(int i = in.read(cache);i != -1;i = in.read(cache)){
  out.write(cache, 0, i);
}
in.close();
out.close();
messageDigest.update(out.toByteArray());
md5 = bufferToHex(messageDigest.digest());

不知道SUN为啥要搞这种半截子工程，大家有什么其他解决方法么？

评论

19 楼 dsjt 2013-05-29  

map是映射到直接内存，回收比较复杂。
用堆内存缓存：

ByteBuffer buffer= ByteBuffer.allocate(1024*1024);
FileChannel.read(buffer);

18 楼 sonic39 2009-02-21  

小弟过来学习中

17 楼 d2lorder 2008-12-23  

哈哈  我也遇到过
但是使用 第一种方法就可以搞定了
第二种方法 也用过,也可以实现

16 楼 AreYouOK? 2008-12-23  

引用

我觉得mappedbytebuffer更适用于文件较小,但是有些字节需要反复读取得情况

大约是这样的，对于计算一个大文件的MD5来说，每个字节都只读取一次，映射到内存应该是不会快的。

对于特别小的文件，javadoc是这么说的：

引用

For most operating systems, mapping a file into memory is more expensive than reading or writing a few tens of kilobytes of data via the usual read and write methods. From the standpoint of performance it is generally only worth mapping relatively large files into memory.

也就是说，它建议把“大”文件做映射（实际上它说的也就是要读写几十K），但是我想也许这个映射的开销是一次性的，对于小文件以后反复读写就快了吧。

这个映射的特点是可以将超过（物理内存＋虚拟内存）、超过JVM最大内存大小的文件部分装入内存。因此，所谓装入内存实际上是虚拟的，我们看到的就是一个大数组，读的时候，如果在内存里面，就从内存里面读，否则就要读文件。

由于映射是操作系统负责的，所以其很多行为都是不确定的，在javadoc里面就有很多这方面的描述。主要是写操作后，数据对其它程序的可见性。

另外还有一个问题，就是map的文件部分的大小也是有限制的。如下：

WinXP 32位 2G内存，2G虚拟内存，Map一个2G的文件，XmX＝64M
map 0~500M  OK
map 0~1G      内存溢出错误
循环，每次map1M，返回的buffer不释放，到达将近2G时内存溢出，也就是说，map的文件部分的总和也是有限制的

Linux 32位 2G内存，1G虚拟内存，Map一个3G多的文件，XmX＝64M
map 0~3G  IllegalArgumentException，map的长度不能超过Integer.MAX_VALUE，也就是不能超过2G
map 0~Integer.MAX_VALUE ok
循环，每次map1M，返回的buffer不释放，到达2G后（2G或者2G多一点？）时内存溢出

Linux 64位 2G内存，2G虚拟内存，Map一个5G的文件，XmX＝64M
map 0~5G  IllegalArgumentException，map的长度不能超过Integer.MAX_VALUE，也就是不能超过2G
map 0~Integer.MAX_VALUE ok
循环，每次map1M，返回的buffer不释放，没有发现限制


有意思的是，第三个参数的类型是long，但是却不允许超过Interger.MAX_VALUE，不知是在其它操作系统下可以，还是给将来留一点余地？
反正现在在Linux64下，是基本够用了。

15 楼 bloodrate 2008-12-23  

猜想这样,FileInputStream 的 read 方法是通过与本地文件的通道中从文件读取数据,由于只能知道当前读取的内容,未读取的内容在硬盘中处于未知状态,所以FileInputStream没有length方法(刚学io的时候觉得很蹩脚),想读第2个字节必选先读第1个字节.而用内存地址映射将整个文件存储到内存中,一切都变成可控可操作的,但是内容中对象确实要交由jvm处理,这点java机制所致没办法,至于为什么占着本地文件引用不释放就不理解了,按说文件被加载道内存里后就与本地文件划清界限了..

我觉得mappedbytebuffer更适用于文件较小,但是有些字节需要反复读取得情况

14 楼 seen 2008-12-23  

期待yywill出来解释。。。

13 楼 kusix 2008-12-22  

一年前就碰到过这个问题，当时也是被恶心到了，SUN的一个BUG。

我是用的第一种方法解决的。

12 楼 AreYouOK? 2008-12-22  

我也遇到这个问题，它还有其他一些很不确定的行为，例如：

引用

On some systems, acquiring a mandatory lock on a region of a file prevents that region from being mapped into memory, and vice versa. Programs that combine locking and mapping should be prepared for this combination to fail.

引用

MappedByteBuffer是java平台共享内存的实现，把硬盘虚拟为内存，主要用于进程间共享数据，所以在进程没有退出前文件是不允许删除的。

不是这样的，看javadoc，不知道为什么有这么恶心的设计：

引用

A mapped byte buffer and the file mapping that it represents remain valid until the buffer itself is garbage-collected.

11 楼 gqf2008 2008-12-22  

MappedByteBuffer是java平台共享内存的实现，把硬盘虚拟为内存，主要用于进程间共享数据，所以在进程没有退出前文件是不允许删除的。

10 楼 yipsilon 2008-12-22  

通过 codeutil 的代码修正了问题，感谢！！！！

除非SUN把这个给解决，不然再也不想用ByteBuffer这东西了，哎哎。

9 楼 gembler 2008-12-21  

这个东西，我狂抓了大半年了··为了删除文件，用后台线程去gc``（幸好该操作不频）
这种情况下看gc log的时候··会出冷汗

8 楼 sdh5724 2008-12-21  

看错了啊， 确实不应该这么写的。LZ要分段做。

7 楼 codeutil 2008-12-21  

不说MappedByteBuffer的问题，楼主你如此hash有点不妥，如果是22G的文件你的写法都得全读到内存才计算hash。

    public static String getHash(String fileName, String hashType) throws  
            Exception {  
        InputStream fis;  
        fis = new FileInputStream(fileName);  
        byte[] buffer = new byte[1024];  
        MessageDigest md5 = MessageDigest.getInstance(hashType);  
        int numRead = 0;  
        while ((numRead = fis.read(buffer)) > 0) {  
            md5.update(buffer, 0, numRead);  
        }  
        fis.close();  
        return toHexString(md5.digest());  
    } 

对比：

FileInputStream in = new FileInputStream(file);
ByteArrayOutputStream out = new ByteArrayOutputStream((int)file.length());
byte[] cache = new byte[1048576];
for(int i = in.read(cache);i != -1;i = in.read(cache)){
  out.write(cache, 0, i);
}
in.close();
out.close();
messageDigest.update(out.toByteArray());
md5 = bufferToHex(messageDigest.digest());

6 楼 sdh5724 2008-12-21  

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4724038

大家看看吵上天了， 老外也抓狂呢。

5 楼 sdh5724 2008-12-21  

楼住， 你发现的问题是真的。 你是发现了SUN的一个很严重的设计问题。 我也不知道SUN什么时候会解决， 在mmap中， SUN这个老顽固， 认为Java的内存管理就应该是jvm干的事情， 因此， 在mmap使用上， Sun依然认为mmap是jvm应该管理的内存资源。 在很多设计者的眼里， mmap资源应该属于一种特殊的内存资源， 而且他还是属于一种特殊的文件资源， 他根本不能使用jvm的内存管理办法来管理这个资源。当前mmap对象被JVM创建（ch.map(FileChannel.MapMode.READ_ONLY, 0, file.length());）后， 如果想释放， 就要等到GC干活的时候。 这个是非常恶心的设计。

另外有人把io/nio就是看作阻塞, 非阻塞的关系， 或者是同步与异步处理是不对的。nio的原理更应该理解为操作系统对资源一个处理方式，通过内核事件来通知资源就绪的情况， 这个处理模式极大的提高了系统的高并发处理能力和CPU利用效率， 仅此而已。

到目前为止， 没有好的解决办法（除了HACKING）

4 楼 yywill 2008-12-21  

把sun的包复制出来
rt.jar
然后自己精简一下

3 楼 yipsilon 2008-12-21  

MappedByteBuffer的cleaner方法不是公开的，必须使用上述的那种手段进行调用，这样有个问题就是，我们无法控制客户使用的JVM，因为很多Application Server的JVM都不是SUN的，例如IBM或BEA，使用SUN所独有的内部类和方法会导致兼容性问题。

begin 和 end 这两个方法我在AbstractInterruptibleChannel类中看到都是protected的，无法在程序中调用。兄弟能详细解释一下么？

2 楼 yywill 2008-12-21  

请用begin和end标记你的map操作，告诉jvm你的map什么时候结束

boolean completed = false;
try {
     begin();
     completed = ...;    // Perform blocking I/O operation
return ...;         // Return result
} finally {
     end(completed);
}

1 楼 yywill 2008-12-21  

1.MappedByteBuffer 也有clean方法啊。不行么。
2.NIO出现这种错误是正常的，因为NIO的含义是non-blocking IO。所以关闭的方法和IO中的操作不一样。你始终要处理异步或者是多线程的问题。
请自己查看：
java.nio.channels.spi.AbstractInterruptibleChannel

J2SE没有半截子工程。不要用IO的方法来操作NIO的类，当你用到NIO就要始终处理多线程，处理异步。