MappedByteBuffer檔案控制代碼釋放問題

標籤：null   測試   void   log   access   重新命名檔案   bug   jdk   失敗   

問題描述

現在很多java代碼中都會用到記憶體映射的概念。檔案對應的方法比輸入輸出資料流的方式快很多。但是在使用的過程中，正常地調用了FileChannel的force和close方法後，重新命名檔案或刪除檔案還會失敗。主要原因還是檔案的控制代碼沒有釋放。導致的

問題分析及解決

檔案控制代碼如果被持有，就相當於jvm虛擬機器中有一個指向檔案的指標，所以重新命名檔案和刪除檔案都會導致失敗。而MappedByteBuffer沒有提供unmap方法，且JDK中關於這個unmap方法的bug一直處於開放狀態。在網上尋找說的最多的就是利用反射調用FileChannelImpl的unmap方法釋放記憶體：

    private static void unmap(MappedByteBuffer var0) {        Cleaner var1 = ((DirectBuffer)var0).cleaner();        if (var1 != null) {            var1.clean();        }    }

反射調用的代碼不在寫了。而且親自測試了的確可以保證檔案的刪除。
利用反射調用的原因是這個方法時私人靜態。但是換一個思路，既然已經知道了內部代碼的實現，不如自己寫一個unmap方法將內部的代碼copy出來不是更好嗎？所以

private void unmap(MappedByteBuffer var0) {        Cleaner var1 = ((DirectBuffer)var0).cleaner();        if (var1 != null) {            var1.clean();        }    }

在調用buffer的force方法後，在調用該unmap方法，就可以重新命名檔案了。

File file = new File(rootPath + fileNum + ".txt");RandomAccessFile raf = new RandomAccessFile(file,"rw");FileChannel channel = raf.getChannel();MappedByteBuffer buffer = channel.map(FileChannel.MapMode.READ_WRITE,0L,numCount * 4);buffer.force();channel.force(true);channel.close();raf.close();unmap(buffer)

可以使用rename()方法測試，檔案是否被佔用

file.rename(file)

返回true重新命名成功，返回false檔案重新命名失敗。

特殊情況

如果buffer的容量不夠用時，需要用channel.map()重建一個MappedByteBuffer對象，在映射新buffer之前應該先調用buffer.force()方法和unmap(buffer) 兩個方法。否則檔案還是不能進行重新命名和刪除操作。原因應該是原來存在堆中的對象沒有被buffer回收，而且還在持有檔案的控制代碼。

MappedByteBuffer檔案控制代碼釋放問題