WatchServiceディレクトリへのファイルの追加を確認するために を使用しています。次にリスナーは、カスタム クラスにラップされた ByteBuffer の形式でファイルから入力ストリームを取得します (以下を参照)。
close()問題は、関連するすべてのオブジェクト (およびその他のいくつか) を呼び出し、ファイルがロックされていないことを確認しFile.canWrite()(true を返す)、ファイルを移動しようとすると、ファイルが JVM によってロックされていると Windows が文句を言うことです。 .
ファイルをロックしている可能性のあるものがないかコードを精査しましたが、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() 操作を使用すると機能し、ファイルはロックされませんでした。最終的に、バッファーの使用はレガシー コード (おそらく、潜在的に大きなファイルを処理する際の最適化のため) であったため、現時点では安全に変更できます。
それにもかかわらず、質問はまだ技術的に未解決のままであるため、今のところ開いたままにします. 助けてくれてありがとう ：）