5

この 3 種類のロックは明らかに悪いものです。他のどのタイプのロックが悪いですか? これをキャッチする Stylecop / FxCop ルールはありますか? そうでない場合は、カスタム ルールの実装を手伝っていただけますか? それらすべてのコードは似ているに違いありませんよね?

ありがとうございました。

4

2 に答える 2

3

John Robbins のDebugging Microsoft .NET Applications bookのサンプル(ブラウザでポップアップを許可する必要がある場合があります) には、そのような FxCop ルール (DoNotLockOnPublicFields、DoNotLockOnThisOrMe、DoNotLockOnTypes など) のソースが含まれています。それらはもともと FxCop 1.35 用に作成されたようですが、VS 2008 のバージョンと最新のスタンドアロン バージョンは 1.36 です (VS2010 は言うまでもありません)。そのため、YMMV の微調整が必​​要になる場合があります。

ルールCA2002 (ID が弱いオブジェクトをロックしない) もあります。これは のようなものをチェックしますlock(typeof(...))が、lock(this)

于 2010-06-01T04:43:18.123 に答える
1

基本的に、これが特にロック オブジェクトでない限り、外部オブジェクトをロックしないでください (SyncRoot非ジェネリックのプロパティICollectionが設計された場合など)。これを行うと、参照の他の「ユーザー」もそれをロックするリスクがあり、不要なロックやデッドロックが発生する可能性があります。

明らかに、this定義typeof()上は外部オブジェクトです。文字列は不変であり、文字列リテラルはすべてインターンされているため、オブジェクトに直接割り当てた場合でも、同じ参照を別の場所で unse にすることができます。

私はそれらの StyleCop ルールを知りませんが、StyleCop または FxCop で利用できるものの概要をよく把握していません。文字列ではなく、プロパティやメソッドで直接返されないプライベートメンバーでのみ同期をチェックします。

于 2010-05-31T20:19:01.617 に答える