File lockFile = new File("file.lock");
    int retryCount = 30;  // timeout = 3sec
    while (! lockFile.createNewFile()) {
        if ((retryCount--) == 0) {
            throw new LockFailedException("give up!");
        }
        Thread.sleep(100);
    }
    try {
        // ファイルロックで保護された処理
        ...
    } finally {
        lockFile.delete();
    }

    File lockFile = new File("file.lock");
    lockFile.deleteOnExit();

    FileOutputStream fs = new FileOutputStream(lockFile);
    try {
        FileChannel ch = fs.getChannel();
        FileLock lock = null;

        final long TIMEOUT = 3000L;  // timeout = 3sec
        final long WAIT = 100L;

        for (int i = 0; i < (TIMEOUT / WAIT); i++) {
            if (null != (lock = ch.tryLock())) {
                break;
            }
            Thread.sleep(WAIT);
        }
        if (null == lock) {
            throw new LockFailedException("give up!");
        }

        try {
            // ファイルロックで保護された処理
            ...
        } finally {
            lock.release();
        }
    } finally {
        fs.close();
    }

冒頭のコードと比べると若干、複雑になってますが、基本構造は同じなので難しくはないと思います。 この方法ならば先に述べた問題点をクリアできますが、 一点、同一 VM のスレッド間排他には使えないことには気を付けてください。 冒頭のコードではファイル有無＝ロック有無でしたので、一応、スレッド間の排他も行えますが、 Java5 以前の FileLock 実装ではスレッド間（正確には異なるストリームから別々に取得した FileChannel による FileLock 間）の排他制御はプラットフォーム依存（Windows は排他 OK, Linux では排他 NG）となります。 （※ なお Java6 からはプラットフォーム依存性はなくなったようです。）

前段でも少し触れましたが FileLock の挙動は基本的にプラットフォーム依存です。 ということで、具体的にどのような実装になっているか OpenJDK のソースを見てみました。

【 UNIX(Linux) 実装】

    fcntl((tryLock ? F_SETLKW64 : F_SETLK64),
          (shared ? F_RDLCK : F_WRLCK))

【 WinNT(Windows) 実装】

    LockFileEx((tryLock ? LOCKFILE_FAIL_IMMEDIATELY : 0) |
               (shared ? 0 : LOCKFILE_EXCLUSIVE_LOCK))

※ それぞれの説明はこちら ⇒ fcntl(2), LockFileEx

Linux と Windows との違いで大きいのは、やはりアドバイザリロックか強制ロックの違いでしょうか。 これは排他制御をアプリケーションレベル（アドバイザリロック）で行うか OS レベル（強制ロック）で行うの違いなのですが、よく理解していない人もいるようです。 冒頭のコードにも「Linux では FileLock が動かないので createNewFile を使った云々」という趣旨のコメントがありました。

あと LockFileEx の説明に『共有アクセスの目的でファイルの特定の領域をロックすると（共有ロック）、ロック側プロセスも含め、どのプロセスもその領域に書き込めなくなります。』とあるので、 プラットフォーム依存を考えた場合、ロック用ファイルとプロセス間で共有するファイルは分けておくのが無難なようです。

そもそもファイル有無＝ロック有無にするなんてことを考えるのは CGI 世代なのかなー？と思っていましたが、 Java 1.4.0 以前の createNewFile() の Javadoc に、こんな記述がありました。

この記述は Java 1.4.1 からは改められて （参照） ファイルロックには使うな、となったようです。 まあ、そもそも createNewFile() はシステムコールの open(O_CREAT|O_EXCL,0666) を使うので NFS とかじゃ使えないのですが。 （native実装はOpenJDKで確認しただけですが仕様からして大体はこれを使ってるはず）