java.nio.channels.FileChannelを使用すると、基礎となるファイル システムに固有のメソッドを使用して、ファイルのFileLockを取得できます(そのような機能がサポートされている場合)。
このロックは、Java 以外のプロセスであっても、マシン上のプロセス全体で機能します。(実際、ロックは特定の JVM インスタンスに代わって保持されるため、プロセス内の複数のスレッド間、または同じ JVM 内の複数のプロセス間の競合の管理には適していません)。
ここには多くの注意事項がありますが、Windows で作業している場合は調査する価値があります。
javadoc から:
このファイル ロック API は、基盤となるオペレーティング システムのネイティブ ロック機能に直接マップすることを目的としています。したがって、ファイルに保持されているロックは、プログラムが記述されている言語に関係なく、ファイルにアクセスできるすべてのプログラムから見える必要があります。
ロックによって別のプログラムがロックされた領域のコンテンツにアクセスするのを実際に防止するかどうかは、システムに依存するため未指定です。一部のシステムのネイティブ ファイル ロック機能は単なる助言にすぎません。つまり、プログラムは、データの整合性を保証するために、既知のロック プロトコルを協力して監視する必要があります。他のシステムでは、ネイティブ ファイル ロックが必須です。つまり、あるプログラムがファイルの領域をロックすると、他のプログラムはロックに違反するような方法でその領域にアクセスできなくなります。さらに他のシステムでは、ネイティブ ファイル ロックが推奨か強制かをファイルごとに設定できます。プラットフォーム間で一貫した正しい動作を確保するために、この API によって提供されるロックをアドバイザリ ロックのように使用することを強くお勧めします。
一部のシステムでは、ファイルの領域で強制ロックを取得すると、その領域がメモリにマップされなくなり、その逆も同様です。ロックとマッピングを組み合わせるプログラムは、この組み合わせが失敗しないように準備する必要があります。
一部のシステムでは、チャネルを閉じると、そのチャネルを介してロックが取得されたか、同じファイルで開かれている別のチャネルを介してロックが取得されたかに関係なく、Java 仮想マシンが保持している基になるファイルのすべてのロックが解放されます。プログラム内で、特定のファイルのすべてのロックを取得するために一意のチャネルを使用することを強くお勧めします。
一部のネットワーク ファイル システムでは、ロックされた領域がページで整列され、基盤となるハードウェアのページ サイズの整数倍である場合にのみ、メモリ マップト ファイルでファイル ロックを使用できます。一部のネットワーク ファイル システムは、特定の位置 (多くの場合 230 または 231) を超える領域にファイル ロックを実装していません。一般に、ネットワーク ファイルシステムに存在するファイルをロックするときは細心の注意を払う必要があります。