关于 MappedByteBuffer文件句柄释放问题

今天在做大文件上传时遇到了一个bug 多次上传一个大点的文件会出现一个异常 异常表现为

核心代码 上传

    @Override
    public void uploadFileByMappedByteBuffer(MultipartFileParam param) throws IOException {
        //获取文件名称
        String fileName = param.getName();
        //获取文件上传路径与文件名
        String uploadDirPath = finalDirPath + param.getMd5();
        //临时文件名
        String tempFileName = fileName + "_tmp";
        //判断本地文件是否存在 不存在就创建
        File tmpDir = new File(uploadDirPath);
        File tmpFile = new File(uploadDirPath, tempFileName);
        if (!tmpDir.exists()) {
            tmpDir.mkdirs();
        }
        //创建一个随机的读写类（该类通过自带的读写流非常的快速 并且可以进行大文件文本定位 日志追加 断点续写）
        RandomAccessFile tempRaf = new RandomAccessFile(tmpFile, "rw");
        FileChannel fileChannel = tempRaf.getChannel();

        //写入该分片数据
        long offset = CHUNK_SIZE * param.getChunk();
        byte[] fileData =param.getFile().getBytes();
        MappedByteBuffer mappedByteBuffer = fileChannel.map(FileChannel.MapMode.READ_WRITE, offset, fileData.length);
        mappedByteBuffer.put(fileData);
        //检测有没有别的线程正在读取
        FileMD5Util.freedMappedByteBuffer(mappedByteBuffer);
        // 释放
        fileChannel.close();
        //清除
        tempRaf.close();
        //检查并修改文件上传进度
        boolean isOk = checkAndSetUploadProgress(param, uploadDirPath);
        if (isOk) {
            boolean flag = renameFile(tmpFile, fileName);
            System.out.println("upload complete !!" + flag + " name=" + fileName);
        }
    }

释放MapperBuffer 方法

 /**
     * 在MappedByteBuffer释放后再对它进行读操作的话就会引发jvm crash，在并发情况下很容易发生
     * 正在释放时另一个线程正开始读取，于是crash就发生了。所以为了系统稳定性释放前一般需要检 查是否还有线程在读或写
     *
     * @param mappedByteBuffer
     */
    public synchronized static void freedMappedByteBuffer(final MappedByteBuffer mappedByteBuffer) {
        try {
            if (mappedByteBuffer == null) {
                return;
            }


            AccessController.doPrivileged(new PrivilegedAction<Object>() {
                @Override
                public Object run() {
                    try {
                        Method getCleanerMethod = mappedByteBuffer.getClass().getMethod("cleaner", new Class[0]);
                        getCleanerMethod.setAccessible(true);
                        sun.misc.Cleaner cleaner = (sun.misc.Cleaner) getCleanerMethod.invoke(mappedByteBuffer,new Object[0]);
                        cleaner.clean();
                    } catch (Exception e) {
                        logger.error("clean MappedByteBuffer error!!!", e);
                    }
                    logger.info("clean MappedByteBuffer completed!!!");
                    return null;
                }
            });

        } catch (Exception e) {
            e.printStackTrace();
        }
    }

这个错误百度了一个下午也没解决后来发现 网上的很多帖子都在误人子弟  大多都是使用sun.misc.Cleaner 对MapperBuffer进行资源释放，后台发现这样并解决不了问题，当然前端分块上传没有并发应该是没问题的,但是我为了提高效率设置了前端并发为3 这时上传时走到了释放这里就有问题了，

因为 下面进程将它释放了 上面面一个进程可能还在使用这个进程导致释放不掉所以会出现 请求操作无法映射问题！

解决这个问题的办法就是将释放代码的方法封装mappedByteBuffer加个synchronized同步锁方可解决问题 

果然遇到问题还是要根据自己的经验冷静分析思考 而不是一味地去百度复制代码。

下面是百度其他人的博客分析方案 可以看到都没有说到锁这个问题

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的派生。毕竟这是一个很实用的类，如果允许派生，那么我就可以操作的就不仅仅限于堆内存和文件了，我可以扩展到任何存储设备。