ガベージ コレクションの基礎Fundamentals of garbage collection

共通言語ランタイム (CLR) では、自動メモリ マネージャーとしてガベージ コレクターを使用できます。In the common language runtime (CLR), the garbage collector serves as an automatic memory manager. 次のような利点があります。It provides the following benefits:

  • アプリケーションを開発するときにメモリを解放する必要がありません。Enables you to develop your application without having to free memory.

  • オブジェクトが効率的にマネージド ヒープに割り当てられます。Allocates objects on the managed heap efficiently.

  • 使用されなくなったオブジェクトが解放され、メモリがクリアされてその後の割り当てに使用できるようになります。Reclaims objects that are no longer being used, clears their memory, and keeps the memory available for future allocations. マネージド オブジェクトは自動的にクリーンな内容で開始されるため、コンストラクターでデータ フィールドごとに初期化する必要はありません。Managed objects automatically get clean content to start with, so their constructors do not have to initialize every data field.

  • オブジェクトで別のオブジェクトの内容を使用できなくすることで、メモリの安全が確保されます。Provides memory safety by making sure that an object cannot use the content of another object.

このトピックでは、ガベージ コレクションの主要な概念について説明します。This topic describes the core concepts of garbage collection.

メモリの基礎Fundamentals of memory

CLR のメモリに関する重要な概念の概要を以下に示します。The following list summarizes important CLR memory concepts.

  • 各プロセスは、分離された独自の仮想アドレス空間を持ちます。Each process has its own, separate virtual address space. 同じコンピューターのすべてのプロセスが同じ物理メモリとページ ファイル (存在する場合) を共有します。All processes on the same computer share the same physical memory, and share the page file if there is one.

  • 32 ビット コンピューターでは、各プロセスが既定で 2 GB のユーザー モード仮想アドレス空間を持ちます。By default, on 32-bit computers, each process has a 2-GB user-mode virtual address space.

  • アプリケーション開発者が操作するのは仮想アドレス空間だけで、直接物理メモリを操作することはありません。As an application developer, you work only with virtual address space and never manipulate physical memory directly. マネージド ヒープの仮想メモリの割り当てと解放はガベージ コレクターによって行われます。The garbage collector allocates and frees virtual memory for you on the managed heap.

    ネイティブ コードを記述する場合は、Win32 関数を使用して仮想アドレス空間を操作します。If you are writing native code, you use Win32 functions to work with the virtual address space. ネイティブ ヒープの仮想メモリの割り当てと解放はこれらの関数によって行われます。These functions allocate and free virtual memory for you on native heaps.

  • 仮想メモリには次の 3 つの状態があります。Virtual memory can be in three states:

    • 空き。Free. 参照されていない、割り当てに使用できるメモリ ブロックです。The block of memory has no references to it and is available for allocation.

    • 予約済み。Reserved. 使用できるように確保された、他の割り当て要求には使用できないメモリ ブロックです。The block of memory is available for your use and cannot be used for any other allocation request. ただし、このメモリ ブロックがコミットされるまではデータを格納できません。However, you cannot store data to this memory block until it is committed.

    • コミット済み。Committed. 物理ストレージに割り当てられたメモリ ブロックです。The block of memory is assigned to physical storage.

  • 仮想アドレス空間は、断片化することがあります。Virtual address space can get fragmented. 断片化とは、アドレス空間に複数の空きブロック (ホールとも呼ばれます) がある状態です。This means that there are free blocks, also known as holes, in the address space. 仮想メモリの割り当てが要求された場合、仮想メモリ マネージャーは、その割り当て要求を満たすのに十分な大きさの単一の空きブロックを見つけなければなりません。When a virtual memory allocation is requested, the virtual memory manager has to find a single free block that is large enough to satisfy that allocation request. 2 GB の空き領域があっても、そのすべての空き領域が 1 つのアドレス ブロックの中にない場合、2 GB の領域を必要とする割り当ては失敗します。Even if you have 2 GB of free space, the allocation that requires 2 GB will be unsuccessful unless all of that free space is in a single address block.

  • メモリが足りなくなるのは、予約する仮想アドレス空間が足りなくなった場合か、コミットする物理領域が足りなくなった場合です。You can run out of memory if you run out of virtual address space to reserve or physical space to commit.

ページ ファイルは、物理メモリの圧迫度 (物理メモリに対する需要) が低い場合にも使用されます。Your page file is used even if physical memory pressure (that is, demand for physical memory) is low. 最初に物理メモリの圧迫度が高まると、データを格納するための領域を確保するために物理メモリのデータの一部がページ ファイルにバックアップされますが、The first time your physical memory pressure is high, the operating system must make room in physical memory to store data, and it backs up some of the data that is in physical memory to the page file. そのデータは必要になるまでページングされないため、物理メモリの圧迫度が非常に低い状況でページングが発生する可能性もあります。That data is not paged until it is needed, so it is possible to encounter paging in situations where the physical memory pressure is very low.

ページのトップへBack to top

ガベージ コレクションの条件Conditions for a garbage collection

ガベージ コレクションは、次のいずれかの条件に当てはまる場合に発生します。Garbage collection occurs when one of the following conditions is true:

  • システムの物理メモリが少ない場合。The system has low physical memory. OS からのメモリ不足通知またはホストによって示されたメモリ不足のいずれかによって検出されます。This is detected by either the low memory notification from the OS or low memory indicated by the host.

  • マネージド ヒープで割り当てられたオブジェクトによって使用されているメモリが、許容されるしきい値を超える場合。The memory that is used by allocated objects on the managed heap surpasses an acceptable threshold. このしきい値は、プロセスの進行に合わせて絶えず調整されます。This threshold is continuously adjusted as the process runs.

  • GC.Collect メソッドが呼び出された場合。The GC.Collect method is called. ほとんどの場合、ガベージ コレクターは継続して実行されるため、このメソッドを呼び出す必要はありません。In almost all cases, you do not have to call this method, because the garbage collector runs continuously. このメソッドは、主に特別な状況やテストで使用されます。This method is primarily used for unique situations and testing.

ページのトップへBack to top

マネージド ヒープThe managed heap

ガベージ コレクターは、CLR によって初期化された後、オブジェクトを格納および管理するためのメモリのセグメントを割り当てます。After the garbage collector is initialized by the CLR, it allocates a segment of memory to store and manage objects. オペレーティング システムのネイティブ ヒープに対し、このメモリのことをマネージド ヒープと呼びます。This memory is called the managed heap, as opposed to a native heap in the operating system.

マネージド ヒープはマネージド プロセスごとに割り当てられます。There is a managed heap for each managed process. プロセス内のすべてのスレッドは、同じヒープにオブジェクト用のメモリを割り当てます。All threads in the process allocate memory for objects on the same heap.

メモリを予約するために、ガベージ コレクターは Win32 VirtualAlloc 関数を呼び出し、マネージド アプリケーション用のメモリのセグメントを一度に 1 つずつ予約します。To reserve memory, the garbage collector calls the Win32 VirtualAlloc function, and reserves one segment of memory at a time for managed applications. また、ガベージ コレクターは、必要に応じてセグメントを予約したり、Win32 VirtualFree 関数を呼び出すことで (オブジェクトのセグメントをクリアしてから) セグメントを解放してオペレーティング システムに戻したりします。The garbage collector also reserves segments as needed, and releases segments back to the operating system (after clearing them of any objects) by calling the Win32 VirtualFree function.


ガベージ コレクターによって割り当てらるセグメントのサイズは実装に固有であり、定期的な更新プログラムによる場合を含め、いつでも変更されることがあります。The size of segments allocated by the garbage collector is implementation-specific and is subject to change at any time, including in periodic updates. アプリでは、セグメント サイズを推測することや、特定のセグメント サイズに依存することを絶対に避けてください。また、セグメントの割り当てに使用可能なメモリの量を構成しようとしてもなりません。Your app should never make assumptions about or depend on a particular segment size, nor should it attempt to configure the amount of memory available for segment allocations.

ヒープに割り当てられたオブジェクトが少ないほど、ガベージ コレクターの処理も少なくなります。The fewer objects allocated on the heap, the less work the garbage collector has to do. そのため、オブジェクトを割り当てるときに、必要な量より多く割り当てないようにしてください。たとえば、15 バイトしか必要がないときに 32 バイトの配列を割り当てないようにしてください。When you allocate objects, do not use rounded-up values that exceed your needs, such as allocating an array of 32 bytes when you need only 15 bytes.

ガベージ コレクションがトリガーされると、ガベージ コレクターは、使用されなくなったオブジェクトに占有されているメモリを解放します。When a garbage collection is triggered, the garbage collector reclaims the memory that is occupied by dead objects. この解放プロセスでは、まとめて移動できるように有効なオブジェクトを圧縮し、使用されなくなったスペースを削除することで、ヒープを小さくします。The reclaiming process compacts live objects so that they are moved together, and the dead space is removed, thereby making the heap smaller. これにより、一緒に割り当てられたオブジェクトが同じマネージド ヒープにまとめられ、局所性が保持されます。This ensures that objects that are allocated together stay together on the managed heap, to preserve their locality.

ガベージ コレクションの割り込みの動作 (頻度と期間) は、割り当てのボリュームとマネージド ヒープ上の残ったメモリの量によって決まります。The intrusiveness (frequency and duration) of garbage collections is the result of the volume of allocations and the amount of survived memory on the managed heap.

ヒープは、大きなオブジェクト ヒープと小さなオブジェクト ヒープの 2 つを累積したものと見なすことができます。The heap can be considered as the accumulation of two heaps: the large object heap and the small object heap.

大きなオブジェクト ヒープには、85,000 バイトを超える非常に大きなオブジェクトが格納されます。The large object heap contains very large objects that are 85,000 bytes and larger. 大きなオブジェクト ヒープの中のオブジェクトは、通常は配列になります。The objects on the large object heap are usually arrays. インスタンス オブジェクトが極端に大きくなることはほとんどありません。It is rare for an instance object to be extremely large.

ページのトップへBack to top


ヒープは、有効期間が長いオブジェクトと有効期間が短いオブジェクトに対処できるようにジェネレーションにまとめられます。The heap is organized into generations so it can handle long-lived and short-lived objects. ガベージ コレクションは主に、通常はヒープのごく一部だけを占有する有効期間が短いオブジェクトを解放する場合に発生します。Garbage collection primarily occurs with the reclamation of short-lived objects that typically occupy only a small part of the heap. ヒープのオブジェクトのジェネレーションには次の 3 つがあります。There are three generations of objects on the heap:

  • ジェネレーション 0Generation 0. これは一番最初のジェネレーションで、有効期間が短いオブジェクトが格納されます。This is the youngest generation and contains short-lived objects. 有効期間が短いオブジェクトには、たとえば、テンポラリ変数などがあります。An example of a short-lived object is a temporary variable. ガベージ コレクションは、このジェネレーションで最も頻繁に発生します。Garbage collection occurs most frequently in this generation.

    オブジェクトが新しく割り当てられると、大きなオブジェクトの場合以外は、オブジェクトの新しいジェネレーションが形成されて暗黙的にジェネレーション 0 のコレクションになります。大きなオブジェクトの場合は、ジェネレーション 2 のコレクションの大きなオブジェクトのヒープに割り当てられます。Newly allocated objects form a new generation of objects and are implicitly generation 0 collections, unless they are large objects, in which case they go on the large object heap in a generation 2 collection.

    ジェネレーション 0 では、ほとんどのオブジェクトがガベージ コレクションで解放され、次のジェネレーションには残りません。Most objects are reclaimed for garbage collection in generation 0 and do not survive to the next generation.

  • ジェネレーション 1Generation 1. このジェネレーションには有効期間が短いオブジェクトが格納されます。有効期間が短いオブジェクトと有効期間が長いオブジェクトの間のバッファーとして機能します。This generation contains short-lived objects and serves as a buffer between short-lived objects and long-lived objects.

  • ジェネレーション 2Generation 2. このジェネレーションには、有効期間が長いオブジェクトが格納されます。This generation contains long-lived objects. 有効期間が長いオブジェクトには、たとえば、プロセスの存続期間を通じて有効な静的データを含むサーバー アプリケーションのオブジェクトなどがあります。An example of a long-lived object is an object in a server application that contains static data that is live for the duration of the process.

ガベージ コレクションは、条件に応じて特定のジェネレーションで発生します。Garbage collections occur on specific generations as conditions warrant. ジェネレーションのコレクションでは、そのジェネレーションとそれよりも前のすべてのジェネレーションのオブジェクトがコレクションの対象になります。Collecting a generation means collecting objects in that generation and all its younger generations. ジェネレーション 2 のガベージ コレクションは、すべてのジェネレーションのすべてのオブジェクト (つまり、マネージド ヒープのすべてのオブジェクト) を解放することから、フル ガベージ コレクションとも呼ばれます。A generation 2 garbage collection is also known as a full garbage collection, because it reclaims all objects in all generations (that is, all objects in the managed heap).

存続と昇格Survival and promotions

ガベージ コレクションで解放されなかったオブジェクトは残存オブジェクトと呼ばれ、次のジェネレーションに昇格されます。Objects that are not reclaimed in a garbage collection are known as survivors, and are promoted to the next generation. ジェネレーション 0 のガベージ コレクションでごみではないと判断されたオブジェクトは、ジェネレーション 1 に昇格されます。ジェネレーション 1 のガベージ コレクションでごみではないと判断されたオブジェクトは、ジェネレーション 2 に昇格されます。ジェネレーション 2 のガベージ コレクションでごみではないと判断されたオブジェクトは、ジェネレーション 2 に残ります。Objects that survive a generation 0 garbage collection are promoted to generation 1; objects that survive a generation 1 garbage collection are promoted to generation 2; and objects that survive a generation 2 garbage collection remain in generation 2.

ガベージ コレクターは、ジェネレーションでごみではないと判断される割合が高いことを検出すると、そのジェネレーションに対する割り当てのしきい値を高くして、次のジェネレーションで十分なサイズの解放されたメモリを受け取ることができるようにします。When the garbage collector detects that the survival rate is high in a generation, it increases the threshold of allocations for that generation, so the next collection gets a substantial size of reclaimed memory. CLR は、アプリケーションのワーキング セットが大きくなりすぎないようにすることと、ガベージ コレクションに時間がかかりすぎないようにすることに注意して、それらの 2 つの優先事項のバランスを絶えず調整します。The CLR continually balances two priorities: not letting an application's working set get too big and not letting the garbage collection take too much time.

短期のジェネレーションとセグメントEphemeral generations and segments

ジェネレーション 0 および 1 のオブジェクトは有効期間が短いことから、それらのジェネレーションのことを短期ジェネレーションと呼びます。Because objects in generations 0 and 1 are short-lived, these generations are known as the ephemeral generations.

短期ジェネレーションは、短期セグメントと呼ばれるメモリ セグメントに割り当てる必要があります。Ephemeral generations must be allocated in the memory segment that is known as the ephemeral segment. ガベージ コレクターによって新しいセグメントが取得されると、いずれも新しい短期セグメントになり、ジェネレーション 0 のガベージ コレクションで残ったオブジェクトが格納されます。Each new segment acquired by the garbage collector becomes the new ephemeral segment and contains the objects that survived a generation 0 garbage collection. 古い短期セグメントは新しいジェネレーション 2 のセグメントになります。The old ephemeral segment becomes the new generation 2 segment.

短期セグメントのサイズは、システムが 32 ビット 64 ビットのどちらであるか、および実行されているガベージ コレクターの種類に応じて異なります。The size of the ephemeral segment varies depending on whether a system is 32- or 64-bit, and on the type of garbage collector it is running. 既定の値を次の表に示します。Default values are shown in the following table.

32 ビット32-bit 64 ビット64-bit
ワークステーションの GCWorkstation GC 16 MB16 MB 256 MB256 MB
サーバーの GCServer GC 64 MB64 MB 4 GB4 GB
サーバーの GC (論理 CPU が 4 個以上の場合)Server GC with > 4 logical CPUs 32 MB32 MB 2 GB2 GB
サーバーの GC (論理 CPU が 8 個以上の場合)Server GC with > 8 logical CPUs 16 MB16 MB 1 GB1 GB

短期セグメントには、ジェネレーション 2 のオブジェクトも含めることができます。The ephemeral segment can include generation 2 objects. ジェネレーション 2 のオブジェクトでは複数のセグメントを使用できます (プロセスでの必要に応じてメモリが許容できる限りいくつでも使用できます)。Generation 2 objects can use multiple segments (as many as your process requires and memory allows for).

短期ガベージ コレクションによって解放されるメモリの量は、短期セグメントのサイズまでに限られます。The amount of freed memory from an ephemeral garbage collection is limited to the size of the ephemeral segment. 解放されるメモリの量は、使用されなくなったオブジェクトに占有されていた領域に比例します。The amount of memory that is freed is proportional to the space that was occupied by the dead objects.

ページのトップへBack to top

ガベージ コレクションの実行時の動作What happens during a garbage collection

ガベージ コレクションには次のフェーズがあります。A garbage collection has the following phases:

  • マーキング フェーズ。有効なすべてのオブジェクトを探し、そのリストを作成します。A marking phase that finds and creates a list of all live objects.

  • 再配置フェーズ。圧縮するオブジェクトへの参照を更新します。A relocating phase that updates the references to the objects that will be compacted.

  • 圧縮フェーズ。使用されなくなったオブジェクトに占有されている領域を解放し、残ったオブジェクトを圧縮します。A compacting phase that reclaims the space occupied by the dead objects and compacts the surviving objects. 圧縮フェーズでは、ガベージ コレクションで残ったオブジェクトをセグメントの後ろに移動します。The compacting phase moves objects that have survived a garbage collection toward the older end of the segment.

    ジェネレーション 2 のコレクションでは複数のセグメントを占有できるため、ジェネレーション 2 に昇格されたオブジェクトはより古いセグメントに移動できます。Because generation 2 collections can occupy multiple segments, objects that are promoted into generation 2 can be moved into an older segment. ジェネレーション 1 とジェネレーション 2 の残存オブジェクトは、どちらもジェネレーション 2 に昇格されるため、別のセグメントに移動できます。Both generation 1 and generation 2 survivors can be moved to a different segment, because they are promoted to generation 2.

    通常、大きなオブジェクト ヒープは圧縮されません。これは、大きなオブジェクトをコピーするとパフォーマンスが低下するためです。Ordinarily, the large object heap is not compacted, because copying large objects imposes a performance penalty. ただし .NET Framework 4.5.1 以降では、GCSettings.LargeObjectHeapCompactionMode プロパティを使用して、大きなオブジェクト ヒープを必要に応じて圧縮できます。However, starting with the .NET Framework 4.5.1, you can use the GCSettings.LargeObjectHeapCompactionMode property to compact the large object heap on demand.

ガベージ コレクターは、次の情報に基づいてオブジェクトが有効かどうかを判断します。The garbage collector uses the following information to determine whether objects are live:

  • スタック ルートStack roots. Just-In-Time (JIT) コンパイラとスタック ウォーカーによって提供されるスタック変数。Stack variables provided by the just-in-time (JIT) compiler and stack walker. JIT の最適化では、スタック変数がガベージ コレクターに報告されるコードの領域が延長または短縮される可能性があることに注意してください。Note that JIT optimizations can lengthen or shorten regions of code within which stack variables are reported to the garbage collector.

  • ガベージ コレクション ハンドルGarbage collection handles. マネージド オブジェクトを参照するハンドル。これらのハンドルは、ユーザー コードまたは共通言語ランタイムで割り当てることができます。Handles that point to managed objects and that can be allocated by user code or by the common language runtime.

  • 静的データStatic data. 他のオブジェクトを参照している可能性があるアプリケーション ドメインの静的オブジェクト。Static objects in application domains that could be referencing other objects. 静的オブジェクトはそれぞれのアプリケーション ドメインで追跡されます。Each application domain keeps track of its static objects.

ガベージ コレクションが開始される前に、そのガベージ コレクションをトリガーしたスレッドを除くすべてのマネージド スレッドが中断されます。Before a garbage collection starts, all managed threads are suspended except for the thread that triggered the garbage collection.

次の図は、ガベージ コレクションを発生させて他のスレッドの中断を引き起こすスレッドを示しています。The following illustration shows a thread that triggers a garbage collection and causes the other threads to be suspended.

スレッドがガベージ コレクションを発生させる場合 ガベージ コレクションを発生させるスレッドWhen a thread triggers a Garbage Collection Thread that triggers a garbage collection

ページのトップへBack to top

アンマネージ リソースの操作Manipulating unmanaged resources

ガベージ コレクターではマネージド ヒープのメモリのみを追跡するため、マネージド オブジェクトでネイティブのファイル ハンドルを使用してアンマネージド オブジェクトを参照している場合は、そのアンマネージド オブジェクトを明示的に解放する必要があります。If your managed objects reference unmanaged objects by using their native file handles, you have to explicitly free the unmanaged objects, because the garbage collector tracks memory only on the managed heap.

マネージド オブジェクトのユーザーは、オブジェクトで使用されているネイティブ リソースを破棄できません。Users of your managed object may not dispose the native resources used by the object. そのため、クリーンアップを行うには、マネージド オブジェクトをファイナライズ可能にします。To perform the cleanup, you can make your managed object finalizable. ファイナライズは、オブジェクトが使用されなくなったときに実行するクリーンアップ アクションで構成されます。Finalization consists of cleanup actions that you execute when the object is no longer in use. マネージド オブジェクトが使用されなくなると、ファイナライザー メソッドで指定されたクリーンアップ アクションが実行されます。When your managed object dies, it performs cleanup actions that are specified in its finalizer method.

ファイナライズ可能なオブジェクトが使用されなくなったことが検出されると、クリーンアップ アクションを実行するためにファイナライザーによってキューに入れられますが、オブジェクト自体は次のジェネレーションに昇格されます。When a finalizable object is discovered to be dead, its finalizer is put in a queue so that its cleanup actions are executed, but the object itself is promoted to the next generation. そのため、そのジェネレーションで次のガベージ コレクション (次回のガベージ コレクションではない場合もあります) が発生するまで、オブジェクトが解放されたかどうかは確認できません。Therefore, you have to wait until the next garbage collection that occurs on that generation (which is not necessarily the next garbage collection) to determine whether the object has been reclaimed.

ページのトップへBack to top

ワークステーションとサーバーのガベージ コレクションWorkstation and server garbage collection

ガベージ コレクターは、さまざまなシナリオに対応できるように自動的に調整されます。The garbage collector is self-tuning and can work in a wide variety of scenarios. 構成ファイルの設定を使って、作業負荷の特性に基づいてガベージ コレクションの種類を設定できます。You can use a configuration file setting to set the type of garbage collection based on the characteristics of the workload. CLR には、次の種類のガベージ コレクションが用意されています。The CLR provides the following types of garbage collection:

  • ワークステーションのガベージ コレクション。すべてのクライアント ワークステーションとスタンドアロンの PC を対象としたオプションです。Workstation garbage collection, which is for all client workstations and stand-alone PCs. これは、ランタイム構成スキーマの <gcServer> 要素の既定の設定です。This is the default setting for the <gcServer> element in the runtime configuration schema.

    ワークステーションのガベージ コレクションは、同時実行または非同時実行のどちらかで実行できます。Workstation garbage collection can be concurrent or non-concurrent. 同時実行ガベージ コレクションでは、ガベージ コレクションの実行中にマネージド スレッドの操作を続けることができます。Concurrent garbage collection enables managed threads to continue operations during a garbage collection.

    .NET Framework 4 以降では、同時実行ガベージ コレクションは、バックグラウンド ガベージ コレクションに置き換えられています。Starting with the .NET Framework 4, background garbage collection replaces concurrent garbage collection.

  • サーバーのガベージ コレクション。高いスループットとスケーラビリティが必要なサーバー アプリケーションを対象としたオプションです。Server garbage collection, which is intended for server applications that need high throughput and scalability. サーバーのガベージ コレクションは、非同時実行ガベージ コレクションまたはバックグラウンド ガベージ コレクションである場合があります。Server garbage collection can be non-concurrent or background.

次の図は、サーバー上でガベージ コレクションを実行する専用のスレッドを示しています。The following illustration shows the dedicated threads that perform the garbage collection on a server.

サーバー ガベージ コレクション スレッド サーバー ガベージ コレクションServer Garbage Collection Threads Server garbage collection

ガベージ コレクションの構成Configuring garbage collection

ランタイム構成スキーマの <gcServer> 要素を使用して、CLR で実行するガベージ コレクションの種類を指定できます。You can use the <gcServer> element of the runtime configuration schema to specify the type of garbage collection you want the CLR to perform. この要素の enabled 属性が false (既定値) に設定されている場合、ワークステーションのガベージ コレクションが実行されます。When this element's enabled attribute is set to false (the default), the CLR performs workstation garbage collection. enabled 属性を trueに設定すると、サーバーのガベージ コレクションが実行されます。When you set the enabled attribute to true, the CLR performs server garbage collection.

同時実行ガベージ コレクションは、ランタイム構成スキーマの <gcConcurrent> 要素を使用して指定します。Concurrent garbage collection is specified with the <gcConcurrent> element of the runtime configuration schema. 既定値は enabledです。The default setting is enabled. この設定は、同時実行ガベージ コレクションとバックグラウンド ガベージ コレクションの両方を制御します。This setting controls both concurrent and background garbage collection.

サーバーのガベージ コレクションは、アンマネージ ホスト インターフェイスを使用して指定することもできます。You can also specify server garbage collection with unmanaged hosting interfaces. ASP.NET および SQL Server では、アプリケーションがそのいずれかの環境内でホストされている場合、自動的にサーバーのガベージ コレクションが有効になることに注意してください。Note that ASP.NET and SQL Server enable server garbage collection automatically if your application is hosted inside one of these environments.

ワークステーションとサーバーのガベージ コレクションの比較Comparing workstation and server garbage collection

ワークステーションのガベージ コレクションにおける、スレッド処理とパフォーマンスについての注意点を次に示します。The following are threading and performance considerations for workstation garbage collection:

  • コレクションは、ガベージ コレクションをトリガーしたユーザー スレッドで、それと同じ優先順位で実行されます。The collection occurs on the user thread that triggered the garbage collection and remains at the same priority. ユーザー スレッドは一般に通常の優先順位で実行されるため、その場合 (通常の優先順位のスレッドで実行された場合)、ガベージ コレクターの CPU 時間が他のスレッドと競合します。Because user threads typically run at normal priority, the garbage collector (which runs on a normal priority thread) must compete with other threads for CPU time.

    ネイティブ コードを実行しているスレッドは中断されません。Threads that are running native code are not suspended.

  • プロセッサが 1 つしかないコンピューターでは、<gcServer> の設定に関係なく、常にワークステーションのガベージ コレクションが使用されます。Workstation garbage collection is always used on a computer that has only one processor, regardless of the <gcServer> setting. サーバーのガベージ コレクションを指定した場合、CLR は、コンカレンシーを無効にしてワークステーションのガベージ コレクションを使用します。If you specify server garbage collection, the CLR uses workstation garbage collection with concurrency disabled.

サーバーのガベージ コレクションにおける、スレッド処理とパフォーマンスについての注意点を次に示します。The following are threading and performance considerations for server garbage collection:

  • コレクションは、 THREAD_PRIORITY_HIGHEST の優先順位で実行される複数の専用スレッドで実行されます。The collection occurs on multiple dedicated threads that are running at THREAD_PRIORITY_HIGHEST priority level.

  • ヒープおよびガベージ コレクションを実行するための専用スレッドは CPU ごとに 1 つずつ用意され、複数のヒープのコレクションが同時に行われます。A heap and a dedicated thread to perform garbage collection are provided for each CPU, and the heaps are collected at the same time. 各ヒープには小さなオブジェクト ヒープと大きなオブジェクト ヒープがあり、どのヒープもユーザー コードからアクセスできます。Each heap contains a small object heap and a large object heap, and all heaps can be accessed by user code. 異なるヒープのオブジェクトを相互に参照できます。Objects on different heaps can refer to each other.

  • 複数のガベージ コレクション スレッドが連携して処理を行うため、同じサイズのヒープを処理した場合、サーバーのガベージ コレクションの方がワークステーションのガベージ コレクションよりも高速です。Because multiple garbage collection threads work together, server garbage collection is faster than workstation garbage collection on the same size heap.

  • 一般に、サーバーのガベージ コレクションの方が、格納されるセグメントのサイズは大きくなります。Server garbage collection often has larger size segments. ただし、これは一般論に過ぎません。セグメントのサイズは実装に固有であり、変更されることがあります。Note, however, that this is only a generalization: segment size is implementation-specific and is subject to change. アプリをチューニングする時に、ガベージ コレクターによって割り当てられるセグメントのサイズに関して何らかの仮定をすることは避けてください。You should make no assumptions about the size of segments allocated by the garbage collector when tuning your app.

  • サーバーのガベージ コレクションでは、リソースが大量に消費されることがあります。Server garbage collection can be resource-intensive. たとえば、4 つのプロセッサを搭載したコンピューターで 12 のプロセスを実行する場合、そのすべてでサーバーのガベージ コレクションを使用するには、48 の専用のガベージ コレクション スレッドが必要です。For example, if you have 12 processes running on a computer that has 4 processors, there will be 48 dedicated garbage collection threads if they are all using server garbage collection. メモリの負荷が高い状況で、すべてのプロセスがガベージ コレクションの処理を開始した場合、ガベージ コレクターは 48 のスレッドをスケジュールすることになります。In a high memory load situation, if all the processes start doing garbage collection, the garbage collector will have 48 threads to schedule.

実行するアプリケーションのインスタンスが数百に及ぶ場合は、同時実行ガベージ コレクションを無効にしてワークステーションのガベージ コレクションを使用することを検討してください。If you are running hundreds of instances of an application, consider using workstation garbage collection with concurrent garbage collection disabled. これによって、コンテキストの切り替えが少なくなり、パフォーマンスが向上します。This will result in less context switching, which can improve performance.

ページのトップへBack to top

同時実行ガベージ コレクションConcurrent garbage collection

ワークステーションまたはサーバーのガベージ コレクションでは、同時実行ガベージ コレクションを有効にすることで、複数のスレッドを同時に実行できます。同時実行ガベージ コレクションでは、コレクションの実行中は、ほとんどの場合、ガベージ コレクションの処理を行う専用のスレッドが使用されます。In workstation or server garbage collection, you can enable concurrent garbage collection, which enables threads to run concurrently with a dedicated thread that performs the garbage collection for most of the duration of the collection. このオプションは、ジェネレーション 2 のガベージ コレクションにのみ影響します。ジェネレーション 0 と 1 の処理はすぐに終了するため、常に非同時実行で行われます。This option affects only garbage collections in generation 2; generations 0 and 1 are always non-concurrent because they finish very fast.

同時実行ガベージ コレクションでは、コレクションの一時停止を最小限にすることで、インタラクティブ アプリケーションの応答性を高めることができます。Concurrent garbage collection enables interactive applications to be more responsive by minimizing pauses for a collection. マネージド スレッドは、同時実行ガベージ コレクションのスレッドが実行されている間も、ほぼ常に処理を続けることができます。Managed threads can continue to run most of the time while the concurrent garbage collection thread is running. そのため、ガベージ コレクションの実行中の一時停止が短くなります。This results in shorter pauses while a garbage collection is occurring.

複数のプロセスを実行している場合にパフォーマンスを向上させるには、同時実行ガベージ コレクションを無効にします。To improve performance when several processes are running, disable concurrent garbage collection. <gcConcurrent> 要素をアプリの構成ファイルに追加し、enabled 属性の値を "false" に設定することで、これを行うことができます。You can do this by adding a <gcConcurrent> element to the app's configuration file and setting the value of its enabled attribute to "false".

同時実行ガベージ コレクションは、専用のスレッドで実行されます。Concurrent garbage collection is performed on a dedicated thread. 既定では、CLR は、同時実行ガベージ コレクションを有効にしてワークステーションのガベージ コレクションを実行します。By default, the CLR runs workstation garbage collection with concurrent garbage collection enabled. これは、シングルプロセッサのコンピューターでもマルチプロセッサのコンピューターでも同じです。This is true for single-processor and multi-processor computers.

同時実行ガベージ コレクションの実行中にヒープに小さなオブジェクトを割り当てる機能は、同時実行ガベージ コレクションの開始時に短期セグメントに残っていたオブジェクトによって制限されます。Your ability to allocate small objects on the heap during a concurrent garbage collection is limited by the objects left on the ephemeral segment when a concurrent garbage collection starts. セグメントの最後に達した後は、同時実行ガベージ コレクションが終了するまで、小さなオブジェクトを割り当てる必要があるマネージド スレッドは中断されたままになります。As soon as you reach the end of the segment, you will have to wait for the concurrent garbage collection to finish while managed threads that have to make small object allocations are suspended.

同時実行ガベージ コレクションのワーキング セットは、同時実行コレクションの実行中にオブジェクトを割り当てることができるように (非同時実行ガベージ コレクションに比べて) 若干大きくなっています。Concurrent garbage collection has a slightly bigger working set (compared with non-concurrent garbage collection), because you can allocate objects during concurrent collection. ただし、オブジェクトを割り当てるとそれもワーキング セットの一部になるため、パフォーマンスに影響することがあります。However, this can affect performance, because the objects that you allocate become part of your working set. 基本的に、同時実行ガベージ コレクションでは、ある程度の CPU およびメモリと引き換えに一時停止が短くなります。Essentially, concurrent garbage collection trades some CPU and memory for shorter pauses.

次の図は、別々の専用のスレッドで実行される同時実行ガベージ コレクションを示しています。The following illustration shows concurrent garbage collection performed on a separate dedicated thread.

同時実行ガベージ コレクションのスレッド 同時実行ガベージ コレクションのスレッドConcurrent Garbage Collection Threads Concurrent garbage collection

ページのトップへBack to top

バックグラウンド ワークステーション ガベージ コレクションBackground workstation garbage collection

バックグラウンド ガベージ コレクションでは、ジェネレーション 2 のコレクションの実行中に、必要に応じて短期ジェネレーション (0 および 1) のコレクションが行われます。In background garbage collection, ephemeral generations (0 and 1) are collected as needed while the collection of generation 2 is in progress. バックグラウンド ガベージ コレクションの設定はありません。同時実行ガベージ コレクションを有効にすると自動的に有効になります。There is no setting for background garbage collection; it is automatically enabled with concurrent garbage collection. バックグラウンド ガベージ コレクションは同時実行ガベージ コレクションに代わるものです。Background garbage collection is a replacement for concurrent garbage collection. 同時実行ガベージ コレクションと同様に、バックグラウンド ガベージ コレクションは専用のスレッドで実行され、ジェネレーション 2 のコレクションにのみ適用されます。As with concurrent garbage collection, background garbage collection is performed on a dedicated thread and is applicable only to generation 2 collections.


バックグラウンド ガベージ コレクションは、.NET Framework 4 以降のバージョンでのみ使用できます。Background garbage collection is available only in the .NET Framework 4 and later versions. .NET Framework 4 では、ワークステーション ガベージ コレクションのみでサポートされます。In the .NET Framework 4, it is supported only for workstation garbage collection. .NET Framework 4.5 以降では、バックグラウンド ガベージ コレクションは、ワークステーションとサーバーのガベージ コレクションの両方で使用できます。Starting with the .NET Framework 4.5, background garbage collection is available for both workstation and server garbage collection.

バックグラウンド ガベージ コレクションの実行中に行われる短期ジェネレーションに対するコレクションのことを、フォアグラウンド ガベージ コレクションと呼びます。A collection on ephemeral generations during background garbage collection is known as foreground garbage collection. フォアグラウンド ガベージ コレクションが発生すると、マネージド スレッドはすべて中断されます。When foreground garbage collections occur, all managed threads are suspended.

バックグラウンド ガベージ コレクションの実行中にジェネレーション 0 に十分なオブジェクトが割り当てられていれば、CLR はジェネレーション 0 またはジェネレーション 1 のフォアグラウンド ガベージ コレクションを実行します。When background garbage collection is in progress and you have allocated enough objects in generation 0, the CLR performs a generation 0 or generation 1 foreground garbage collection. バックグラウンド ガベージ コレクションの専用スレッドは、フォアグラウンド ガベージ コレクションの要求がないかどうかをセーフ ポイントで頻繁に確認します。The dedicated background garbage collection thread checks at frequent safe points to determine whether there is a request for foreground garbage collection. 要求があると、バックグラウンド コレクションを中断して、フォアグラウンド ガベージ コレクションを実行します。If there is, the background collection suspends itself so that foreground garbage collection can occur. フォアグラウンド ガベージ コレクションが完了すると、バックグラウンド ガベージ コレクションの専用スレッドとユーザー スレッドが再開されます。After the foreground garbage collection is completed, the dedicated background garbage collection thread and user threads resume.

バックグラウンド ガベージ コレクションでは、バックグラウンド ガベージ コレクションの実行中に短期ガベージ コレクションが発生する可能性があるため、同時実行ガベージ コレクションによる割り当ての制限が解除されます。Background garbage collection removes allocation restrictions imposed by concurrent garbage collection, because ephemeral garbage collections can occur during background garbage collection. つまり、バックグラウンド ガベージ コレクションで短期ジェネレーションの使用されなくなったオブジェクトを削除でき、また、ジェネレーション 1 のガベージ コレクションの実行中に必要に応じてヒープを拡張することもできます。This means that background garbage collection can remove dead objects in ephemeral generations and can also expand the heap if needed during a generation 1 garbage collection.

次の図は、ワークステーション上の別々の専用スレッドで実行されるバックグラウンド ガベージ コレクションを示しています。The following illustration shows background garbage collection performed on a separate dedicated thread on a workstation:

バックグラウンド ワークステーション ガベージ コレクションを示す図。

ページのトップへBack to top

バックグラウンド サーバー ガベージ コレクションBackground server garbage collection

.NET Framework 4.5 以降では、サーバーのバックグラウンド ガベージ コレクションは、サーバーのガベージ コレクションの既定のモードです。Starting with the .NET Framework 4.5, background server garbage collection is the default mode for server garbage collection. このモードを選択するには、ランタイム構成スキーマで <gcServer> 要素enabled 属性を true に設定します。To choose this mode, set the enabled attribute of the <gcServer> element to true in the runtime configuration schema. このモードは、前のセクションで説明したワークステーションのバックグラウンド ガベージ コレクションと同様に機能しますが、いくつかの違いがあります。This mode functions similarly to background workstation garbage collection, described in the previous section, but there are a few differences. ワークステーションのバックグラウンド ガベージ コレクションでは専用のバックグラウンド ガベージ コレクション スレッドを 1 つ使用します。これに対して、サーバーのバックグラウンド ガベージ コレクションでは複数のスレッドを使用し、通常、論理プロセッサごとに専用のスレッドが使用されます。Background workstation garbage collection uses one dedicated background garbage collection thread, whereas background server garbage collection uses multiple threads, typically a dedicated thread for each logical processor. ワークステーションのバックグラウンド ガベージ コレクション スレッドとは異なり、これらのスレッドはタイムアウトになりません。Unlike the workstation background garbage collection thread, these threads do not time out.

次の図は、サーバー上の別々の専用スレッドで実行されるバックグラウンド ガベージ コレクションを示しています。The following illustration shows background garbage collection performed on a separate dedicated thread on a server:

バックグラウンド サーバー ガベージ コレクションを示す図。

関連項目See also