在Java File.canWrite（）返回true并调用所有close（）方法后，文件在Windows中保持锁定

我正在使用

WatchService

检查是否向目录中添加了文件。然后，侦听器以自定义类中包装的ByteBuffer的形式从文件中获取输入流（见下文）

问题是，尽管对每个相关对象（以及其他一些对象）调用了

close（）

，并检查文件是否未使用

file.canWrite（）

（返回true）锁定，Windows仍然抱怨当我尝试移动文件时，JVM锁定了该文件

我在代码中搜索了可能锁定文件的任何内容，但由于

canWrite（）

返回true，我不确定还能做什么。有人有什么想法吗

自定义类的框架如下所示。我意识到这可能不是最好的实现，但我也不知道这是否是问题的根源

private static class ByteBufferBackedInputStream extends InputStream {

    private final ByteBuffer  buf;
    private final FileChannel channel;

    public ByteBufferBackedInputStream(FileInputStream fs) throws IOException {

        this.channel = fs.getChannel();
        this.buf = channel.map(FileChannel.MapMode.READ_ONLY, 0, channel.size());

        fs.close();
    }

    //... all required methods implemented, including close() method

}

任何帮助都将不胜感激

编辑从第一条注释开始，我使用的是

buf.close（）

，这没有帮助。我也完成了整个过程，没有抛出任何异常-只是为了确保我使用的是

finally

块

我有一种感觉，这可能是我实现的

WatchService

，但它没有明确使用任何IO方法，只是生产者和消费者

LinkedBlockingQueue

编辑2正如Andreas在下面的评论中建议的那样，使用标准的read（）/write（）操作可以工作，并且文件没有被锁定。最终，缓冲区的使用是遗留代码（可能是为了在处理可能较大的文件时进行优化），因此现在可以安全地进行更改

---

尽管如此，这个问题在技术上仍然没有答案，所以我暂时不回答。谢谢您的帮助：）

不确定这是否有帮助。。。。但是，您可以尝试buf.clear（）来查看这是否解决了问题。如果您尝试过调试，则可能会出现异常并且文件未关闭的情况感谢您的响应

buf.clear（）

在

close（）

方法中，这没有帮助。我还调试并捕获了

finally

块中

close（）

方法的所有可能异常，这也没有解决问题。您是否尝试用流中的正常读取（）/写入（）操作替换内存映射？有些评论听起来很奇怪，关闭通道不会影响映射的有效性。但是，在Windows上，运行时需要在内存映射对象上调用closeHandle（）Windows API函数。。。顺便说一句：

File.canWrite（）

仅检查文件是否存在以及权限是否允许写入文件。它不检查锁。@Andreas请参见上面的编辑2。谢谢