I am mapping a file("sample.txt") to memory using FileChannel.map()
and then closing the channel using fc.close()
. After this when I write to the file using FileOutputStream, I am getting the following error:
java.io.FileNotFoundException: sample.txt (The requested operation cannot be per formed on a file with a user-mapped section open)
File f = new File("sample.txt");
RandomAccessFile raf = new RandomAccessFile(f,"rw");
FileChannel fc = raf.getChannel();
MappedByteBuffer mbf = fc.map(FileChannel.MapMode.READ_ONLY, 0, fc.size());
fc.close();
raf.close();
FileOutputStream fos = new FileOutputStream(f);
fos.write(str.getBytes());
fos.close();
I presume this may be due to file being still mapped to the memory even after I close the FileChannel
. Am I right?. If so, how can I "unmap" the file from memory?(I can't find any methods for this in the API).
Thanks.
Edit: Looks like it(adding an unmap method) was submitted as RFE to sun some time back: http://bugs.sun.com/view_bug.do?bug_id=4724038
I would try JNI:
Include files: windows.h for Windows, sys/mmap.h for BSD, Linux, OSX.
[WinXP,SunJDK1.6] I had a mapped ByteBuffer taken from filechannel. After reading SO posts finally managed to call a cleaner through reflection without any sun.* package imports. No longer file lock is lingering.
Ideas were taken from these posts.
* How to unmap a file from memory mapped using FileChannel in java?
* Examples of forcing freeing of native memory direct ByteBuffer has allocated, using sun.misc.Unsafe?
* https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/apache/lucene/store/bytebuffer/ByteBufferAllocator.java#L40
If the mapped file buffer object can be guaranteed to be eligible for garbage collection, you don't need to GC the whole VM to get the buffer's mapped memory to be released. You can call System.runFinalization() . This will call the finalize() method on the mapped file buffer object (if it there are no references to it in your app threads) which will release the mapped memory.
The correct solution here is to use try-with-resources.
This allows the creation of the Channel & the other resources to be scoped to a block. Once the block exits, the Channel & other resources are gone & subsequently cannot be used (as nothing has a reference to them).
The memory-mapping still won't be undone until the next GC run, but at least there aren't any dangling references to it.
It is funny to see so many recommendations to do what Item 7 in 'Effective Java' specifically says not to do. A termination method like what @Whome did and no references to the buffer is what is needed. GC cannot be forced. But that doesn't stop developers from trying. Another workaround I found was to use WeakReferences from http://jan.baresovi.cz/dr/en/java#memoryMap