我有一个对象负责将 JTable 状态保存到磁盘。它保存/加载可见列、它们的大小、位置等。下面是其类定义中一些有趣的部分。

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();
                }
            }
        }
    }
}

• TableSaver 永远只存在一个实例。
• load() 可以从多个线程调用。计时器显然是另一个线程。
• loadFile() 和 writeFile() 不会留下打开的文件流——它们使用了一个健壮的、经过良好测试和广泛使用的库，它总是用 关闭流>尝试...最后。

有时这会失败并出现如下异常:

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

所以我有两个问题:

1. 这种同步怎么会失败呢？请注意，我确定只有一个 TableSaver 实例。
2. 堆栈跟踪中的这个东西是什么:package.TableSaver.access$600(TableSaver.java:34)？第 34 行是带有 class TableSaver { 的行。这可能是同步不起作用的原因吗？

最佳答案

Google我了解到这似乎是特定于 Windows 的。这是 Bug 6354433 的摘录:

This is Windows platform issue with memory-mapped file, i.e. 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.

您使用的是哪个 Java/Windows 版本？它有最新的更新吗？

以下是另外两个相关的错误，其中包含一些有用的见解:

• Bug 4715154 - 无法删除内存映射文件。
• Bug 4469299 - 内存映射文件未经过 GC。

关于你的第二个问题，那只是内部类或匿名类的自动生成的类名。

关于java - 在 Java 对象上同步文件访问，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3602783/