static＆constメンバ、静的クラスとボトルネック

Question

static + constメンバーとstaticクラスに関する2つの質問があります。

1つの理由：すべての静的メンバーとconstメンバーを持ち、そのクラスを静的にしないクラスを宣言するのはなぜですか？

私は学習の練習としてリフレクターで.netコードを学習しています。私が勉強しているこのクラスのデザインは、FormsAuthenticationクラスです。すべてのメンバにstaticまたはconstとマークされていますが、それ自身のクラスが表示されていますpublic sealedクラス内の静的でない唯一のメンバは実装されていないデフォルトのコンストラクタです。なぜこのクラスにはpublic static sealedとマークされていませんか？

私の2番目の質問は、FormsAuthenticationクラスのメンバーがstaticと宣言されている理由です。私が理解しているように、多くのがアプリのAppDomainで実行され、これらのすべてがHttpApplicationsが同じFormsAuthenticationのクラスの静的メンバーを共有することがあります。

2つ：これはボトルネックの原因にはなりませんか？もしそうなら、それはなぜこのように設計されていますか？

Answer 1

なぜなら、FormsAuthenticationは静的クラス機能よりも前のクラスであるからです。静的なクラスの概念を持たない.NET 1.1で導入されました。クラスが動作していて、今それを変更することには何のメリットもないので、誰もそれを見直してプライベートなctorを削除し、それを密封する代わりに静的にする予定です。

authと同じように静的なものはシングルトンと考えることができます。アプリケーションに複数のFormsAuthenticationインスタンスが必要なわけではありません（技術的には静的クラスではインスタンスは存在しませんが、FormsAuthには潜在的に1つのインスタンスがありますので、逆コンパイルする必要があります）。複数のインスタンスを作成する必要がないため、静的メソッドで十分です。それは、それに依存する単体テストコードをより困難にしますが、当時、単体テストにはあまり配慮されていませんでした。静的クラスのインスタンスをメソッドに渡すことはできませんが、シングルトンで行うことはできます。

唯一のボトルネックは、静的メンバーに.NETの一般的なスレッドセーフティを提供するため、シーンの背後でロックされる可能性があることです。現実的には、これは問題を起こす可能性は低いですが。それはスレッドローカルストレージも持つかもしれないので、ロックをまったく行わないかもしれません。それを確かめるためには逆コンパイルが必要です。

スレッドの安全を確保するためにロックする必要がある静的データがあるかどうかによって異なります。存在する場合、スレッドはクリティカルセクションがロック解除されるのを待つので、ロックが1つのスレッドのみが許可され、他のスレッドはそのターンを待つので、ロックは共有リソースの競合を引き起こす可能性があります。しかし、パラメータやスレッドローカルストレージ変数の情報のみを使用する静的メソッドを使用することもできます。この場合、同期化の問題はなく、メソッドはボトルネックなしで独立して呼び出すことができます。