在Java对象上同步文件访问

Question

I have an object responsible for persisting JTable state to disk. It saves/loads visible columns, their size, position etc. A few interesting bits from its class definition are below.

class TableSaver {
    Timer timer = new Timer(true);

    TableSaver() {
        timer.schedule(new TableSaverTimerTask(), 15000, SAVE_STATE_PERIOD);
    }

    synchronized TableColumns load(PersistentTable table) {
        String xml = loadFile(table.getTableKey());
        // parse XML, return
    }

    synchronized void save(String key, TableColumns value) {
        try {
            // Some preparations
            writeFile(app.getTableConfigFileName(key), xml);
        } catch (Exception e) {
            // ... handle
        }
    }

    private class TableSaverTimerTask extends TimerTask {
        @Override
        public void run() {
            synchronized (TableSaver.this) {
                Iterator<PersistentTable> iterator = queue.iterator();
                while (iterator.hasNext()) {
                    PersistentTable table = iterator.next();
                    if (table.getTableKey() != null) {
                        save(table.getTableKey(), dumpState(table));
                    }
                    iterator.remove();
                }
            }
        }
    }
}

• There only exists one instance of TableSaver , ever.
• load() can be called from many threads. Timer clearly is another thread.
• loadFile() and writeFile() do not leave open file streams - they use a robust, well tested and broadly used library which always closes the streams with try ... finally .

Sometimes this fails with an exception like:

java.lang.RuntimeException: java.io.FileNotFoundException: C:\path\to\table-MyTable.xml (The requested operation cannot be performed on a file with a user-mapped section open)
    at package.FileUtil.writeFile(FileUtil.java:33)
    at package.TableSaver.save(TableSaver.java:175)
    at package.TableSaver.access$600(TableSaver.java:34)
    at package.TableSaver$TableSaverTimerTask.run(TableSaver.java:246)
    at java.util.TimerThread.mainLoop(Unknown Source)
    at java.util.TimerThread.run(Unknown Source)
Caused by: java.io.FileNotFoundException: C:\path\to\table-MyTable.xml (The requested operation cannot be performed on a file with a user-mapped section open)
    at java.io.FileOutputStream.open(Native Method)
    at java.io.FileOutputStream.<init>(Unknown Source)
    at java.io.FileOutputStream.<init>(Unknown Source)
    at package.FileUtilWorker.writeFile(FileUtilWorker.java:57)
    ... 6 more

So I have two questions:

1. How can this kind of synchronization fail? Note that I am sure there only is one instance of TableSaver .
2. What is this thing in the stacktrace: package.TableSaver.access$600(TableSaver.java:34) ? Line 34 is the line with class TableSaver { . Can this be the reason why the synchronization is not working?

Answer 1

Google learns me that this seems to be Windows specific. Here's an extract of Bug 6354433 :

This is Windows platform issue with memory-mapped file, ie MappedByteBuffer . The Java 5.0 doc for FileChannel state that "the buffer and the mapping that it represents will remain valid until the buffer itself is garbage-collected". The error occurs when we tried to re-open the filestore and the mapped byte buffer has not been GC. Since there is no unmap() method for mapped byte buffer (see bug 4724038), we're at the mercy of the underlying operating system on when the buffer get free up. Calling System.gc() might free up the buffer but it is not guarantee. The problem doesn't occurs on Solaris; may be due to the way shared memory is implemented on Solaris. So the work-around for Windows is not to use memory-mapped file for the transaction information tables.

What Java/Windows version are you using? Does it have the latest updates?

Here are two other related bugs with some useful insights:

• Bug 4715154 - Memory mapped file cannot be deleted.
• Bug 4469299 - Memory mapped files are not GC'ed.

---

As to your second question, that's just the autogenerated classname of an inner or anonymous class.

Answer 2

Assuming there are no issues with the code I have seen this occur when a virus scanner is running in the background which is cheerfully opening files to scan them behind the scenes. If you have a memory resident virus scanner that checks files in the background try disabling it, or at least disabling it for the directory you reading from/writing to.

Answer 3

Your code looks fine. Are you sure it's not related to file permission? Does the application has write privilege to this folder? To this file?

---

[EDIT] This seems to be Windows related, not Java The requested operation cannot be performed on a file with a user-mapped section open.

Answer 4

I had this issue with some tightly threaded Java code. I took a look at the referenced .NET conversation and the penny dropped. It is simply that I have contention for the same file, among different threads. Looking more closely the contention is ( also ) for some internals too. So my best course is to synchronize-d around the shared object when the update it.

This works and the error dissolves in the mist.

    private static   ShortLog   tasksLog     = new ShortLog( "filename" );
    private static   Boolean    tasksLogLock = false;

      ...

    synchronized( tasksLogLock ){
        tasksLog.saveLastDatum( this.toString() );
    }

see also :

• Synchronization of non-final field

Answer 5

Your synchronization only protects against access from your own process. If you want to protect against accesses from any process, you have to use file locking:

http://download.oracle.com/javase/1.4.2/docs/api/java/nio/channels/FileLock.html