1

Please refer to the following code snippet(stripped off the redundant part to highlight the problematic case):

FindBugs is complaining that "Method does not release lock on all paths" . Is this a false positive? If not, how to fix this?

  try{
      someLock.lock();
     //do something
    } finally{
      if (someLock.isLocked())
        someLock.unlock();
    }
4

3 に答える 3

5

何かisLocked()を投げると、ロックが解除されません。

例外がスローされる可能性は低いと思いますisLockedが、ロックするとロックを解除する必要があり、テストしても意味がありません。javadocで説明されている標準パターンを使用してみませんか:

someLock.lock();
try{
    //do something
} finally{
    someLock.unlock();
}

だから私は言った

  • コードのロック解除に失敗できないという意味で、これは誤検知です。
  • 推奨事項に従ってコードを修正する必要があるという意味で、これは真のポジティブです。
于 2013-03-21T12:31:22.037 に答える
3

ロックされています

このロックがいずれかのスレッドによって保持されているかどうかを照会します。このメソッドは、同期制御用ではなく、システム状態の監視用に設計されています。

「同期制御用」ではないということは、isLockedの実装が競合状態にならないことが保証されておらず、ロックを取得した場合でも false を返す可能性があることを意味します。

someLock.lock();
try{      
 //do something
} finally{
  someLock.unlock();
}

また

boolean locked=false;
try{      
 someLock.lock();
 locked=true;
 //do something
} finally{
  if (locked) someLock.unlock();
}
于 2013-03-21T12:31:06.613 に答える
1

これは偽陽性のように見えますが、なぜそうなるかは理解できると思います。

unlockFindBugs ルールは、(ロックの状態の観点から) 呼び出しが実際に必要かどうかに関係なく、すべてのパスが ... を呼び出すことを確認するようにコード化されている可能性が最も高いです。isLocked ロックの状態を追跡しようとはしない可能性が高く、その意味を認識していない可能性が最も高いです。unlockif isLockedreturnsを呼び出す必要がないことは明らかですがfalse、この推論を行うための FindBugs ルールは実装されていません。

(実際、幅広いユースケースで確実に推論を行うことは、FindBugs の実装者にとって難しい問題です。私たちは「自動定理証明者」の領域にいます ...)

于 2013-03-21T13:06:00.560 に答える