C#/.NET でよくあるいくつかの間違い

1 リソースを速やかに解放する
CLR ホスティング環境はガベージ コレクションの役割を果たすため、作成されたオブジェクトによって占有されているメモリを明示的に解放する必要はありません。しかし、それはすべての使用済みオブジェクトを無視できるという意味ではありません。多くのオブジェクトは、他のタイプのシステム リソース (ディスク ファイル、データ接続、ネットワーク ポートなど) をカプセル化します。これらのリソースを使用し続けると、システム リソースが大幅に枯渇し、パフォーマンスが低下し、最終的にはプログラム エラーが発生する可能性があります。ファイル、ネットワーク ポート、またはデータ接続を開いたときは、使用しなくなったらすぐにリソースを明示的に解放する必要があります。
また、リソース操作の場合、通常、例外キャプチャ処理(Try..Catch)を追加する必要があります。このとき、リソースをキャッチしたときにリソースが正常に解放されることを確認するために、最後にリソースを解放することを忘れないでください。例外。
2 マルチスレッドを正しく停止します
FileStream fs = File.Open(…);
Try{…}Finally{ fs.Close;}
この時点で、上記のコードが作業スレッドにあり、Finally まで進んだとします。 、UI スレッドがこのスレッドの Abort() メソッドを呼び出すと、fs.Close が実行される前にワーカー スレッドがfinally コード ブロックから飛び出す可能性が非常に高くなります。こうすることで、FS が閉じられることはありません。
ほとんどの場合、finally は永久に実行されますが、Thread.Abort の呼び出しによってスローされる ThreadAbortException は含まれないため、Abort の使用はお勧めできません。
スレッドを正しく停止するには、呼び出し元がどのような動作をするかには依存しません (Thread.Abort() を直接使用しないでください)。むしろ、ワーカー スレッドが呼び出し元の停止リクエストに積極的に応答できるかどうかに依存します。一般的なメカニズムは、スレッドを停止する必要がある場合、スレッド自体が呼び出し元に対して Cancel インターフェイスを開く責任を負う必要があるということです。
3 型変換関連
データベースから値を読み取る場合、データがあれば int 型になります。データがなければ、値は null になります。型を強制すると、例外が発生します。したがって、強制転送が使用されることはほとんどありません。使用する場合は、プログラム例外を回避するために例外をキャッチする必要があります。
強制転送が良くない場合は、Parseメソッドの例外処理が実装されているTryParseメソッドの使用を推奨します。
Convert を使用することもできますが、これにも例外キャプチャが必要です。実際、型変換、シリアル化、その他の操作が関係する場合は、例外をキャプチャする必要があります。
文字列操作では、大量のスプライシングが発生する場合があります。 StringBuilder を使用することをお勧めします。 String を使用すると、明らかにパフォーマンスが低下します。その理由は、文字列オブジェクトは非常に特殊なオブジェクトであり、値が割り当てられると変更できないためです。実行時に String クラスで結合操作 (割り当て、「+」など) を呼び出すと、メモリ内に新しい文字列オブジェクトが作成されます。これは、新しいオブジェクトに新しいメモリ領域を割り当てる必要があることも意味します。
5 const 定数の変更によって引き起こされる問題
プログラムが他の DLL の const 定数を参照する場合は特に注意してください。
この DLL 内の const 定数を変更する場合は、この DLL 内のこの const 定数を参照するすべてのプログラムを再コンパイルする必要があります。再コンパイルしないと、プログラムで使用される定数値が DL 内の定数値と矛盾します。
さらに、const の代わりに readonly を使用すると、const はコンパイルされた定数であり、readonly は実行時定数であるため、再コンパイルせずにこの問題を解決できます。
6 C# コンパイル ターゲット プラットフォームの問題
プログラムが依存する DLL が X86 用にコンパイルされる場合、プログラム自体のコンパイル ターゲット プラットフォームも (デフォルト オプションの Any CPU ではなく) X86 である必要があります。そうしないと、64 ビット コンピューターが走れない。
7 クロススレッド アクセス制御
インターフェイス プログラムを開発する場合、時間のかかる操作が発生することがあります。プログラムの利便性を考慮して、通常は時間のかかる操作をタスク スレッドで実行し、実行情報をメイン UI スレッドに表示します。
タスクスレッドのメインUIスレッドでコントロールを直接操作する場合、例外を発生させて「コントロールを作成したスレッドの値は他のスレッドでは変更できない」と報告することが非常に簡単になります。コンパイラによるクロススレッド アクセスのチェックを禁止すると、エラーは報告されませんが、予期しない問題が発生する可能性があります。現時点では、委任または匿名委任を使用することをお勧めします。

以上がC#/.NET でよくあるいくつかの間違いの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。