关于MappedByteBuffer资源释放问题

 关于MappedByteBuffer资源释放问题

JDK1.4中加入了一个新的包:NIO(java.nio.*)。这个库最大的功能(我认为)就是增加了对异步套接字的支持。其实在 其他语言中，包括在最原始的SOCKET实现(BSD SOCKET)，这是一个早有的功能:异步回调读/写事件，通过选择器动态选择感兴趣的事件，等等。

先谈谈操作系统的内存管理。一般操作系统的内存分两部分：物理内存；虚拟内存。虚拟内存一般使用的是页面映像文件，即硬盘中的某个(某些)特殊的文件.操作系统负责页面文件内容的读写，这个过程叫"页面中断/切换"。

MappedByteBuffer也是类似的,你可以把整个文件(不管文件有多大)看成是一个ByteBuffer。这是一个很好的设计，除了令人头疼的一点在后面会讲到。

java.lang.Object
    java.nio.Buffer
       java.nio.ByteBuffer
           java.nio.MappedByteBuffer

MappedByteBuffer是一个比较方便使用的类。其内容是文件的内存映射区域。映射的字节缓冲区是通过 FileChannel.map 方法创建的。映射的字节缓冲区和它所表示的文件映射关系在该缓冲区本身成为垃圾回收缓冲区之前一直保持有效。此类用特定于内存映射文件区域的操作扩展  ByteBuffer 类。 这个类本身的设计是不错的,比直接操作byte[]方便多了。

ByteBuffer有两种模式：直接/间接。间接模式最典型(也只有这么一种)的就是HeapByteBuffer，即操作堆内存(byte [])。但是内存毕竟有限，如果我要发送一个1G的文件怎么办？不可能真的去分配1G的内存.这时就必须使用"直接"模式，即 MappedByteBuffer，文件映射。

在JDK API文档中这样描述的：

全部或部分映射的字节缓冲区可能随时成为不可访问的，例如，如果我们截取映射的文件。试图访问映射的字节缓冲区的不可访问区域将不会更改缓冲区 的内容，并导致在访问时或访问后的某个时刻抛出未指定的异常。因此强烈推荐采取适当的预防措施，以避免此程序或另一个同时运行的程序对映射的文件执行操作 （读写文件内容除外）。

MappedByteBuffer只能通过调用FileChannel的map()取得,再没有其他方式.但是令人奇怪的是,SUN提供了map()却没有提供unmap().这样会导致什么后果呢?

这样，问题就出现了。通过MappedByteBuffer实现文件复制功能非常容易，可以用以下方法来实现。

   //文件复制
   public void copyFile(String filename,String srcpath,String destpath)throws IOException {
    File source = new File(srcpath+"/"+filename);
    File dest = new File(destpath+"/"+filename);
     FileChannel in = null, out = null;
     try { 
      in = new FileInputStream(source).getChannel();
      out = new FileOutputStream(dest).getChannel();

      long size = in.size();
      MappedByteBuffer buf = in.map(FileChannel.MapMode.READ_ONLY, 0, size);

      out.write(buf);

      in.close();

      out.close();
      source.delete();//文件复制完成后，删除源文件
     }catch(Exception e){
      e.printStackTrace();
     } finally {
      in.close();
      out.close();
     }
   }

但是如果要实现文件文件复制完成后，删除源文件，以上方法就有问题。因为在source.delete()时，会返回false，删除失败，主 要原因是变量buf仍然有源文件的句柄，文件处于不可删除状态。既然MappedByteBuffer是从FileChannel中map()出来的，为 什么它又不提供unmap()呢？SUN自己也没有讲清楚为什么。O'Reilly的<<Java NIO>>中说是因为"安全"的原因，但是到底unmap()会怎么不安全，作者也没有讲清楚。

在sun网站也有相应的BUG报告：bug id:4724038链接为 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4724038，但是sun自己不认为是BUG，而只是一个RFE(Request For Enhancement)，有待改进。

好在有个叫 bellomi的网友提出了一个解决方法，我也测试过，可以实现期望的功能。具体实现代码如下：

   public static void clean(final Object buffer) throws Exception {
         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(buffer,new Object[0]);
                cleaner.clean();
             } catch(Exception e) {
                e.printStackTrace();
             }
                return null;}});
         
}

不知道为什么SUN不提供ByteBuffer的派生。毕竟这是一个很实用的类，如果允许派生，那么我就可以操作的就不仅仅限于堆内存和文件了，我可以扩展到任何存储设备。