【排他処理】JavaのReetrantLockについて

Question

Aスレッドが処理中にBスレッドは処理待ちにせずに、
Aが処理中である旨のエラーを返してBはスレッドを抜けさせる処理を実装する場合です。

ReentrantLockのtryLock()でロックのチェックと取得を、
unlock()でロックの解除をさせてようと考えています。

private static final ReentrantLock lock=new ReentrantLock();

void main() {
 if(!lock.tryLock()) {
  return error;
 }

 try{
  doSomething();
 } catch {
 } finally {
   lock.unlock();
 }
}

これで問題はないと思いますが、デッドロックのような状態になったり、
ロックの動作が保証されるか不安です。

この方法でロックが保証されるか、もしくは他にいい方法があればご教授いただきたいです。

Answer 1

デッドロックのような状態

単一のロックの仕方が妥当かという意味でしたら妥当だと思います。ただご質問にあるコードの断片だけ見る限りではデッドロックの危険性を評価することはできないと思います。それは単一のリソースのロックについてしか書かれていないからです。

普通デッドロックはロック対象となるリソースが複数の場合に起きます。synchronizedですとロック順の不整合でデッドロックになりますね。一方tryLockの場合、ロックを取れなかったら現在保持しているオブジェクトのロックを全て開放して再度リトライという方法が取れるため、ロック順を決めることが困難であるような複数リソースを用いる協調動作でもデッドロックを回避できると思います。そういう設計があり得るかどうかは自分にはコメントできる知識がありませんが・・・

ロックが保証されるか

tryLockがfalseであることを見逃さない限り保証されます。それとも、ご質問の意味は「多数のスレッドが妥当な時間内にロックを取得できることが保証できるのか」といったことなのでしょうか？そうだとすると少なくとも定性的な分析が必要だと思います。

興味あるので極端な条件で素朴なシミュレートをしてみました。多重度100、資源数25、1回の処理で資源の中から任意の2つをランダム順にlockして1msecの処理を実行、TIMEOUT時間 1秒でやってみると2つのロック獲得までの平均時間は90msec程度、TIMEOUTは発生せずでした。デッドロックが起こらないような順序で同じことをするとロック獲得までの平均時間が十数msec程度になりました。ちなみにロック順をランダムにしたまま資源数を20個に減らすとTIMEOUTが出まくります。興味本位でやる分には面白いですがプロの方がこうした設計をしていることを考えるとちょっと恐ろしくなりました。