メモリ管理に関する開発知識
更新 : 2007 年 11 月
メモリ管理に関する経験は、プログラマの開発歴によって異なります。状況によっては、共通言語ランタイムで提供される自動メモリ管理に合わせて、これまでのプログラミング技法を変更する必要が生じます。
COM 開発者の場合
COM 開発者は、参照カウントをコードによるメモリ管理方法として実装してきました。オブジェクトが参照されるたびに、カウンタの値は増加します。オブジェクトに対する参照がスコープ外に出ると、カウンタの値は減算されます。オブジェクトの参照カウントが 0 になると、オブジェクトは破棄され、そのオブジェクトに割り当てられていたメモリは解放されます。
参照カウント スキームは、さまざまなバグの原因となります。参照カウントのルールが正確に守られないと、オブジェクトが不要になる前に破棄されたり、参照されないオブジェクトがメモリに蓄積したりする可能性があります。循環参照も、バグの原因としてよく知られています。循環参照は、子オブジェクトが親オブジェクトへの参照を持ち、親オブジェクトがその子オブジェクトへの参照を持つ場合に発生します。循環参照が発生すると、どちらのオブジェクトも解放または破棄できなくなります。唯一の解決策は、親オブジェクトが子オブジェクトを常に先に削除するなど、一定の参照と破棄のパターンで親オブジェクトと子オブジェクトを使用することです。
共通言語ランタイムを対象とする言語でアプリケーションを開発する場合は、実行時のガベージ コレクタには参照カウントが不要となるため、このコードによるメモリ管理スキームから生じるバグが除去されます。
C++ 開発者の場合
C++ 開発者は、コードによるメモリ管理に慣れています。C++ では、new 演算子を使ってオブジェクトにメモリを割り当てた場合、delete 演算子を使ってそのオブジェクトのメモリを解放する必要があります。これは、オブジェクトを解放し忘れたためにメモリ リークが発生したり、既に解放されているオブジェクトのメモリにアクセスしたりするなどのエラーの原因となる可能性があります。
Visual C++ または共通言語ランタイムを対象とするその他の言語を使用してアプリケーションを開発する場合は、delete 演算子を使ってオブジェクトを解放する必要がありません。オブジェクトがアプリケーションで使用されなくなると、ガベージ コレクタが自動的にこのオブジェクトを解放します。
C++ 開発者の中には、コードによるメモリ管理のコストを考えて有効期間の短いオブジェクトを使用しないようにしてきた人もいるでしょう。コレクションの実行後に作成され、次のコレクションまでにスコープ外になる有効期間の短いマネージ オブジェクトの場合は、メモリの割り当てと解放のコストがたいへん小さく済みます。.NET Framework では実際に、ガベージ コレクタは有効期間の短いオブジェクトを管理するために最適化されています。マネージ アプリケーションを開発するとき、有効期間の短いオブジェクトを使用することでコードが単純化できる場合には、それらのオブジェクトの使用をお勧めします。
Visual Basic 開発者の場合
Visual Basic 開発者の多くは、自動メモリ管理に慣れています。これまで行ってきたプログラミングの方法は、.NET Framework で作成するマネージ オブジェクトの大部分にも、そのまま当てはまります。ただし、アンマネージ リソースをカプセル化するオブジェクトを作成または使用する場合は、Dispose メソッドの使用に関して提案されたデザイン モデルについて、特に注意する必要があります。
.NET Framework では、ここで取り上げた言語の他にも、共通言語ランタイムを対象とする多数の言語をサポートしています。使用するマネージ言語の種類にかかわらず、.NET Framework のガベージ コレクタは、自動メモリ管理機能を提供します。ガベージ コレクタは、マネージ オブジェクトに対するメモリの割り当てと解放を行い、必要な場合には、アンマネージ リソースを正しくクリーンアップするために Finalize メソッドおよびデストラクタを使用します。自動メモリ管理は、コードによるメモリ管理方式から生じる一般的なバグを除去することで、開発を簡単にします。