0

1 つの JVM で FileLock を 2 回取得すると OverlappingFileLockException がスローされるのはなぜですか? 2 番目のロック取得をブロックして、解放時にロックを取得できなかったのはなぜですか?

4

4 に答える 4

2

ブロッキング lock() メソッドと非ブロッキング trylock() メソッドの両方が OverlappingFileLockException をスローします。FileChannel javadocに記載されているように、同じファイルの重複領域」。

その理由は、デッドロック防止です。このロックを取得しようとしているときに、別のスレッドがすでにブロックされていて、このロックを取得しようとしていた場合、次にこの別のスレッドが保持しているロックを取得しようとすると、JVM 内でデッドロックが発生する可能性があります。また、取得しようとしていたロックが既に保持されている場合は、このロックを既に保持している他のスレッドが取得しようとしている別のロックを既に保持している可能性があり、再びデッドロックが発生します-そのため、例外がスローされて認識されますあなたの潜在的なコーディングエラーの。tryLock() を呼び出すときにこれが発生した場合、ブロックされないため、デッドロックは発生しませんが、ロックを取得しようとする無限ループに陥る可能性があります。常に同じ順序でロックを取得する必要があり、デッドロックの可能性はなく、これに遭遇することもありません。

これは、同じロックに対して lock()、tryLock() を連続して実行してはならないことを意味します。すでにロックを取得している場合は、それを覚えておく必要があり、再度要求しないでください。

他のプログラムがすでにこのロックを保持している場合、例外はスローされず、tryLock() は単に null を返しますが、lock() はロックを取得できる (つまり、他のプログラムがファイル領域をロック解除する) までブロックすることに注意してください。

いいえ、これは tryLock() がスレッドセーフではないことを意味するものではありません。ただし、宣言された例外ではない場合でも、コード内で OverlappingFilelLockException をキャッチして処理する必要がある可能性があることを意味します。

于 2013-08-16T14:55:41.983 に答える
0

私は同じ問題に直面しています。これは、FileChannel.Lock/TryLock がスレッドセーフではないことを意味します。また、同じ JVM で FileChannel ロックを介して同期する必要があります。ReentranetLock または SingleThread の制限。

于 2012-03-29T09:28:00.170 に答える
0

おそらく、NON BLOCKING IO パッケージに含まれているためでしょうか? :-)

これは実行時例外であり、技術的には実稼働環境では発生してはならず、バグを検出している開発中にのみ発生する必要があります。

于 2011-03-16T05:01:03.993 に答える