3

Java 1.5 では、java.nio.channels.FileLock は、すでにロックされているファイルを確認しませんでした。ここで参照

スニペットには次のように記載されています。

java.nio.channels.FileLock クラスは、他の FileChannel インスタンスによってすでにロックされているファイルをチェックします。

Java SE 6 は、別の FileChannel インスタンスを介してロックされた領域と重複する領域をアプリケーションがロックしようとすると、OverlappingFileLockException をスローします。以前のバージョンは、他の FileChannel インスタンスによって取得されたファイル ロックをチェックしませんでした。デフォルトでは、java.nio.channels.FileChannel.lock メソッドは、要求されたロックがこの Java 仮想マシンによって保持されている領域と重複しているかどうかをチェックします。

そのため、Java 6 より前のバージョンでは、複数のプログラムが同じファイルに書き込みを行っている場合 (各プログラムが排他的ロックを取得しようとしていた場合)、排他的ファイル ロックは機能しませんでした。Java 5 以前では、人々はどのようにこれを回避していたのでしょうか?

4

1 に答える 1

1

Java5 の動作は深刻な問題ではないと思います。

ファイル ロックをプロセスに関連付ける OS を考えてみましょう。プロセスがすでにファイル ロックを所有している場合、そのプロセスが再度ロックを要求すると、OS はエラーなしでそれを許可できます。ある意味で「再入可能」ロックです。2 つのプロセスが同じファイルを同時にロックするのを防ぎます。また、プロセスがロックしているときに、2 つのスレッドがファイルに対して重複する変更を行っていないことを確認するのは、プロセス次第です。

通常、JVM には多数の独立したパッケージがあり、2 つのパッケージが同じファイルをロックしようとするユースケースが必要です。それらすべてにロックが付与されている場合、問題が発生します。2 つの独立したパッケージに何らかの方法で協力を求めるのは難しいため、Java6 は所有権をプロセス全体からチャネルに縮小します。(2 つのパッケージが同じチャネルを共有しないことを願っています)

しかし、そのような使用例はおそらくあまり一般的ではありません。通常、ファイルは、特定のパッケージによってのみ処理される特別な種類のものです。データベース パッケージを想像してみてください。そのファイルは、同じ JVM 内の他のパッケージによって操作される可能性は低いですが、他の JVM 内の同じパッケージによって操作される可能性があります。したがって、この場合、Java5 の動作は問題なく、そのようなケースはおそらく大多数です。

于 2011-06-16T20:47:15.547 に答える