この 3 種類のロックは明らかに悪いものです。他のどのタイプのロックが悪いですか? これをキャッチする Stylecop / FxCop ルールはありますか? そうでない場合は、カスタム ルールの実装を手伝っていただけますか? それらすべてのコードは似ているに違いありませんよね?
ありがとうございました。
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)
基本的に、これが特にロック オブジェクトでない限り、外部オブジェクトをロックしないでください (SyncRoot
非ジェネリックのプロパティICollection
が設計された場合など)。これを行うと、参照の他の「ユーザー」もそれをロックするリスクがあり、不要なロックやデッドロックが発生する可能性があります。
明らかに、this
定義typeof()
上は外部オブジェクトです。文字列は不変であり、文字列リテラルはすべてインターンされているため、オブジェクトに直接割り当てた場合でも、同じ参照を別の場所で unse にすることができます。
私はそれらの StyleCop ルールを知りませんが、StyleCop または FxCop で利用できるものの概要をよく把握していません。文字列ではなく、プロパティやメソッドで直接返されないプライベートメンバーでのみ同期をチェックします。