.Netガベージコレクションの仕組み原理(2)-C#.Net チュートリアル-php.cn

英語原文: Jeffrey Richter

編集者: Zhao Yukai

リンク http://www.php.cn/

前回の記事では、.Net ガベージコレクションの基本原理と、.Net ガベージコレクションの実装について紹介しました。ガベージコレクションの最終的な方法内部メカニズム。この記事では、弱参照オブジェクト、世代、マルチスレッドガベージコレクション、ラージオブジェクト処理、およびガベージコレクションに関連するパフォーマンスカウンターについて説明します。
弱参照オブジェクトから始めましょう。弱参照オブジェクトは、大きなオブジェクトによって引き起こされるメモリ負荷を軽減できます。
弱参照
プログラムのルートオブジェクトがオブジェクトを指している場合、そのオブジェクトは到達可能ですが、ガベージコレクターはそれをリサイクルできません。これは、オブジェクトへの強参照と呼ばれます。強参照の反対は弱参照です。オブジェクトに弱参照がある場合、ガベージコレクターはオブジェクトを再利用できますが、プログラムがオブジェクトにアクセスすることもできます。どうしたの？以下をお読みください。

オブジェクトに弱い参照しかなく、ガベージコレクターが実行されている場合、そのオブジェクトがプログラムの後半でアクセスされると、アクセスは失敗します。一方、弱参照オブジェクトを使用するには、ガベージコレクターがオブジェクトを収集する前にプログラムがオブジェクトへの強参照を作成する必要があります (強参照を取得した後)。ガベージコレクターは、このオブジェクトをリサイクルできません。これは少し複雑なので、コードで説明しましょう:

void Method() {
//创建对象的强引用
Object o = new Object(); 
// 用一个短弱引用对象弱引用o.
WeakReference wr = new WeakReference(o);

o = null; // 移除对象的强引用

o = wr.Target; //尝试从弱引用对象中获得对象的强引用
if (o == null) {
// 如果对象为空说明对象已经被垃圾回收器回收掉了
} else {
// 如果垃圾回收器还没有回收此对象就可以继续使用对象了
}
}

ログイン後にコピー

なぜ弱いオブジェクトが必要なのでしょうか?一部のデータは作成が簡単ですが、大量のメモリを必要とするためです。たとえば、ユーザーのハードディスク上のすべてのフォルダーとファイル名にアクセスする必要があるプログラムがある場合、プログラムが初めてこのデータを必要とするときに、ユーザーのディスクにアクセスしてデータを生成できます。毎回ディスクを読み取ってデータを取得するのではなく、データを使用してメモリ内のデータにアクセスできるため、プログラムのパフォーマンスが向上します。

问题是这个数据可能相当大，需要相当大的内存。如果用户去操作程序的另外一部分功能了，这块相当大的内存就没有占用的必要了。你可以通过代码删除这些数据，但是如果用户马上切换到需要这块数据的功能上，你就必须重新从用户的磁盘上构建这个数据。弱引用为这种场景提供了一种简单有效的方案。
当用户切换到其他功能时，你可以为这个数据创建一个弱引用对象，并把对这个数据的强引用解除掉。这样如果程序占用的内存很低，垃圾回收操作就不会触发，弱引用对象就不会被回收掉；这样当程序需要使用这块数据时就可以通过一个强引用来获得数据，如果成功得到了对象引用，程序就没有必要再次读取用户的磁盘了。

WeakReference类型提供了两个构造函数：

WeakReference(object target);
WeakReference(object target, bool trackResurrection);

ログイン後にコピー

target参数显然就是弱引用要跟踪的对象了。trackResurrection参数表示当对象的Finalize方法执行之后是否还要跟踪这个对象。默认这个参数是false。有关对象的复活请参考这里。

便宜上、復活オブジェクトを追跡しない弱い参照を「短い弱参照」と呼び、復活オブジェクトを追跡したい弱い参照を「長い弱参照」と呼びます。オブジェクトが Finalize メソッドを実装していない場合、長い弱参照と短い弱い参照はまったく同じになります。長い弱参照の使用を避けることを強くお勧めします。長い弱参照を使用すると、動作が予測できない可能性がある復活したオブジェクトを使用できます。 WeakReference を使用してオブジェクトを参照した後は、このオブジェクトのすべての強参照を null に設定することをお勧めします。強参照が存在する場合、ガベージコレクターは弱参照が指すオブジェクトを再利用できなくなります。
ターゲットオブジェクトへの弱い参照を使用する場合は、ターゲットオブジェクトの強い参照を作成する必要があります。これは非常に簡単です。 object a = WeekRefer.Target; を使用して、 a が空か弱いかを判断する必要があります。空の場合のみ、引き続き使用できます。空の場合、オブジェクトはガベージコレクターによってリサイクルされており、他のメソッドを通じてオブジェクトを再取得する必要があることを意味します。

弱参照の内部実装前の説明から、弱参照オブジェクトは一般のオブジェクトとは明らかに異なる方法で処理されることが推測できます。一般に、オブジェクトが別のオブジェクトを参照している場合、それは強参照であるため、ガベージコレクターは参照先のオブジェクトをリサイクルできません。ただし、WeakReference オブジェクトの場合はこの限りではありません。
弱いオブジェクトがどのように機能するかを完全に理解するには、マネージドヒープも確認する必要があります。マネージドヒープには 2 つの内部データ構造があり、それらの唯一の役割は弱参照を管理することです。これらを長い弱参照テーブルと呼ぶことができ、これら 2 つのテーブルはマネージドヒープに弱参照ターゲットオブジェクトポインターを格納します。
プログラムの実行開始時は、両方のテーブルが空です。 WeakReference オブジェクトを作成すると、オブジェクトはマネージドヒープに割り当てられませんが、弱いオブジェクトテーブルに空のスロット (Empty Slot) が作成されます。短い弱参照オブジェクトは短い弱参照オブジェクトテーブルに配置され、長い弱参照オブジェクトは長い弱参照テーブルに配置されます。
空のスロットが見つかると、空のスロットの値が弱参照ターゲットオブジェクトのアドレスに設定されます。明らかに、長い弱オブジェクトテーブルと短い弱オブジェクトテーブル内のオブジェクトは、アプリケーションのルートオブジェクトとは見なされません。ガベージコレクターは、長い弱いオブジェクトテーブルと短い弱いオブジェクトテーブルのデータを収集しません。
ガベージコレクションが実行されると何が起こるかを見てみましょう:
1. ガベージコレクターは、到達可能なオブジェクトグラフを構築します。
2. ガベージコレクターは、弱いオブジェクトの場合にスキャンします。テーブルは、ポイントされたオブジェクトが到達可能なオブジェクトグラフ内にない場合、そのオブジェクトはガベージオブジェクトとしてマークされ、ショートオブジェクトテーブル内のオブジェクトポインタは null に設定されます
3。ガベージコレクターはファイナライズキューをスキャンします。上記)、キュー内のオブジェクトが到達可能なオブジェクトグラフにない場合、オブジェクトはファイナライゼーションキューから Feachable キューに移動され、この時点でオブジェクトは到達可能なオブジェクトとしてマークされ、ガベージではなくなります。ガベージコレクターは、長くて弱い参照テーブルをスキャンします。テーブル内のオブジェクトが到達可能オブジェクトグラフにない場合 (到達可能オブジェクトグラフには Feachable キュー内のオブジェクトが含まれます)、長い参照オブジェクトテーブル内の対応するオブジェクトポインターを null に設定します
5 ガベージコレクターは到達可能オブジェクトを移動します
。一度ガベージコレクターの動作プロセスを理解すると、弱参照がどのように機能するかを理解するのは簡単です。 WeakReference の Target プロパティにアクセスすると、システムは弱いオブジェクトテーブル内のターゲットオブジェクトポインターを返します。それが null の場合、オブジェクトがリサイクルされたことを意味します。
短い弱参照は復活を追跡しません。つまり、ガベージコレクターは、ファイナライゼーションキューをスキャンする前に、弱参照テーブルで指されているオブジェクトがガベージオブジェクトかどうかを確認できます。
長い弱参照は、復活したオブジェクトを追跡します。つまり、ガベージコレクターは、オブジェクトがリサイクルされたことを確認した後、弱参照テーブル内のポインターを null に設定する必要があります。

世代:
.Net ガベージコレクションに関して、C++ または C プログラマは、この方法でメモリを管理するとパフォーマンス上の問題が発生するのではないかと疑問に思うかもしれません。 GC 開発者は、パフォーマンスを向上させるためにガベージコレクターを常に調整しています。生成は、ガベージコレクションがパフォーマンスに与える影響を軽減するメカニズムです。ガベージコレクターは、次のステートメントが当てはまると想定します。 1. オブジェクトが新しいほど、オブジェクトのライフサイクルは短くなります。 2. オブジェクトが古いほど、オブジェクトのライフサイクルは長くなります。 3. 通常、新しいオブジェクトは相互に参照関係を持つ可能性が高くなります
4. ヒープ全体を圧縮するよりも、ヒープの一部を圧縮する方が高速です
もちろん、上記の仮定が当てはまることは、多数の研究で証明されています。たくさんのプログラム。それでは、これらの仮定がガベージコレクターの動作にどのような影響を与えるかについて話しましょう。
プログラムの初期化時には、マネージドヒープ上にオブジェクトはありません。このとき、マネージドヒープに新たに追加されるオブジェクトは世代 0 です。次の図に示すように、世代 0 のオブジェクトは最も若いオブジェクトであり、ガベージコレクターによってチェックされたことがありません。

図 1 マネージドヒープ上のジェネレーション 0 オブジェクト

さらにオブジェクトがヒープに追加されると、ヒープがいっぱいになるとガベージコレクションがトリガーされます。ガベージコレクターはマネージドヒープを分析するときに、ガベージオブジェクト (図 2 の薄紫色のブロック) と非ガベージオブジェクトのグラフを構築します。リサイクルされていないすべてのオブジェクトは、ヒープの一番下に移動され、圧縮されます。リサイクルされていないこれらのオブジェクトは、図 2 に示すように、ジェネレーション 1 オブジェクトになります

図 2 マネージドヒープ上のジェネレーション 0 および 1 オブジェクト

さらに多くのオブジェクトがヒープに割り当てられると、新しいオブジェクトは世代 0 領域に配置されます。ジェネレーション 0 ヒープがいっぱいになると、ガベージコレクションがトリガーされます。このとき、生き残ったオブジェクトは世代 1 のオブジェクトとなり、ヒープの最下位に移動されます。ガベージコレクションが発生した後、世代 1 のオブジェクトに残ったオブジェクトは世代 2 のオブジェクトに昇格され、移動および圧縮されます。図 3 に示すように:

図 3 マネージドヒープ上の生成 0、1、および 2 オブジェクト

2代对象是目前垃圾回收器的最高代，当再次垃圾回收时，没有回收的对象的代数依然保持2.
垃圾回收分代为什么可以优化性能
如前所述，分代回收可以提高性能。当堆填满之后会触发垃圾回收，垃圾回收器可以只选择0代上的对象进行回收，而忽略更高代堆上的对象。然而，由于越年轻的对象生命周期越短，因此，回收0代堆可以回收相当多的内存，而且回收所耗的性能也比回收所有代对象要少得多。
这是分代垃圾回收的最简单优化。分代回收不需要便利整个托管堆，如果一个根对象引用了一个高代对象，那么垃圾回收器可以忽略高代对象和其引用对象的遍历，这会大大减少构建可达对象图的时间。
如果回收0代对象没有释放出足够的内存，垃圾回收器会尝试回收1代和0代堆；如果仍然没有获得足够的内存，那么垃圾回收器会尝试回收2，1，0代堆。具体会回收那一代对象的算法不是确定的，微软会持续做算法优化。
多数堆（像c-runtime堆）只要找到足够的空闲内存就分配给对象。因此，如果我连续分配多个对象时，这些对象的地址空间可能会相差几M。然而在托管堆上，连续分配的对象的内存地址是连续的。
前面的假设中还提到，新对象之间更可能存在相互引用关系。因此新对象分配到连续的内存上，你可以获得就近引用的性能优化（you gain performance from locality of reference）。这样的话很可能你的对象都在CPU的缓存中，这样CPU的很多操作就不需要去存取内存了。
微软的性能测试显示托管堆的分配速度比标准的win32 HeapAlloc方法还要快。这些测试也显示了200MHz的Pentium的CPU做一次0代回收时间可以小于1毫秒。微软的优化目的是让垃圾回收耗用的时间小于一次普通的页面错误。
使用System.GC类控制垃圾回收
类型System.GC运行开发人员直接控制垃圾回收器。你可以通过GC.MaxGeneration属性获得GC的最高代数，目前最高代是定值2.

你可以调用GC.Collect()方法强制垃圾回收器做垃圾回收，Collect方法有两个重载：

void GC.Collect(Int32 generation)

void GC.Collect()

ログイン後にコピー

第一个方法允许你指定要回收那一代。你可以传0到GC.MaxGeneration的数字做参数，传0只做0代堆的回收，传1会回收1代和0代堆，而传2会回收整个托管堆。而无参数的方法调用GC.Collect(GC.MaxGeneration)相当于整个回收。

在通常情况下，不应该去调用GC.Collect方法；最好让垃圾回收器按照自己的算法判断什么时候该调用Collect方法。尽管如此，如果你确信比运行时更了解什么时候该做垃圾回收，你就可以调用Collect方法去做回收。比如说程序可以在保存数据文件之后做一次垃圾回收。比如你的程序刚刚用完一个长度为10000的大数组，你不再需要他了，就可以把它设置为null然后执行垃圾回收，缓解内存的压力。
GC还提供了WaitForPendingFinalizers方法。这个方法简单的挂起执行线程，知道Freachable队列中的清空之后，执行完所有队列中的Finalize方法之后才继续执行。
GC还提供了两个方法用来返回某个对象是几代对象，他们是

Int32 GC.GetGeneration(object o);

Int32 GC.GetGeneration(WeakReference wr)

ログイン後にコピー

第一个方法返回普通对象是几代，第二个方法返回弱引用对象的代数。

下面的代码可以帮助你理解代的意义：

private static void GenerationDemo() {
// Let's see how many generations the GCH supports (we know it's 2)
Display("Maximum GC generations: " + GC.MaxGeneration);

// Create a new BaseObj in the heap
GenObj obj = new GenObj("Generation");

// Since this object is newly created, it should be in generation 0
obj.DisplayGeneration(); // Displays 0

// Performing a garbage collection promotes the object's generation
GC.Collect();
obj.DisplayGeneration(); // Displays 1

GC.Collect();
obj.DisplayGeneration(); // Displays 2

GC.Collect();
obj.DisplayGeneration(); // Displays 2 (max generation)

obj = null; // Destroy the strong reference to this object

GC.Collect(0); // Collect objects in generation 0
GC.WaitForPendingFinalizers(); // We should see nothing

GC.Collect(1); // Collect objects in generation 1
GC.WaitForPendingFinalizers(); // We should see nothing

GC.Collect(2); // Same as Collect()
GC.WaitForPendingFinalizers(); // Now, we should see the Finalize 
// method run

Display(-1, "Demo stop: Understanding Generations.", 0);
}
class GenObj{
public void DisplayGeneration(){
Console.WriteLine(“my generation is ” + GC.GetGeneration(this));
}

~GenObj(){
Console.WriteLine(“My Finalize method called”);
}
}

ログイン後にコピー

垃圾回收机制的多线程性能优化

前編では、GCアルゴリズムと最適化について説明しましたが、議論の前提はシングルスレッドの状況でした。実際のプログラムでは、複数のスレッドが連携して動作し、複数のスレッドがマネージドヒープ上のオブジェクトを一緒に操作することがよくあります。スレッドがガベージコレクションをトリガーすると、ガベージコレクターがオブジェクトを移動し、オブジェクトのメモリアドレスを変更する可能性があるため、他のすべてのスレッドは参照されたオブジェクト (独自のスタックで参照されるオブジェクトを含む) へのアクセスを一時停止する必要があります。
そのため、ガベージコレクターがリサイクルを開始すると、マネージドコードを実行しているすべてのスレッドがハングする必要があります。ランタイムには、スレッドを安全に一時停止してガベージコレクションを実行するためのさまざまなメカニズムがいくつかあります。この作品の内部メカニズムについては詳しく説明しません。ただし、Microsoft は、ガベージコレクションによるパフォーマンスの低下を軽減するために、ガベージコレクションメカニズムの変更を継続する予定です。
次の段落では、マルチスレッド状況でガベージコレクターがどのように動作するかを説明します。
コードの実行を完全に中断します。ガベージコレクションの実行が開始されると、すべてのアプリケーションスレッドが一時停止されます。次に、ガベージコレクターは、スレッドの一時停止位置をジャストインタイム (JIT) コンパイラーによって生成されたテーブルに記録し、テーブル内でスレッドの一時停止位置を記録し、現在アクセスされているオブジェクトとその場所を記録します。オブジェクトが格納されている場所 (変数、CPU レジスタなど)
ハイジャック: ガベージコレクターはスレッドのスタックを変更して、戻りアドレスが特別なメソッドを指すようにすることができます。現在実行されているメソッドが戻ると、この特別なメソッドは実行されます。スレッドを一時停止するこのようにスレッドの実行パスを変更する方法をスレッドのハイジャックと呼びます。ガベージコレクションが完了すると、スレッドは以前に実行されたメソッドに戻ります。
安全性のポイント: JIT コンパイラーがメソッドをコンパイルするときに、特定のポイントにコードを挿入して、GC がハングしているかどうかを判断できます。ハングしている場合、スレッドはガベージコレクションが完了するのを待ってハングし、その後、スレッドは実行を再開します。。 JIT コンパイラーが GC コードのチェックを挿入する場所は、「セーフポイント」と呼ばれます
スレッドハイジャックにより、アンマネージコードを実行しているスレッドがガベージコレクション中に実行される可能性があることに注意してください。アンマネージコードがマネージヒープ上のオブジェクトにアクセスしない場合、これは問題になりません。このスレッドが現在アンマネージコードを実行しており、その後マネージコードの実行に戻ると、スレッドはハイジャックされ、ガベージコレクションが完了するまで実行を続行できません。
先ほど述べた集中化メカニズムに加えて、ガベージコレクターには、マルチスレッドプログラムでのオブジェクトメモリの割り当てとリサイクルを強化するためのその他の改良点があります。
同期不要の割り当て: マルチスレッドシステムでは、第 0 世代のヒープがいくつかの領域に分割され、1 つのスレッドが 1 つの領域を使用します。これにより、1 つのスレッドがヒープを排他的に所有する必要がなく、複数のスレッドがオブジェクトを同時に割り当てることができます。
スケーラブルなコレクション: マルチスレッドシステムでサーバーバージョンの実行エンジン (MXSorSvr.dll) を実行します。マネージドヒープは、CPU ごとに 1 つずつ、複数の異なる領域に分割されます。リサイクルが初期化されると、各 CPU はリサイクルスレッドを実行し、各スレッドは独自の領域を再利用します。ワークステーションバージョンの実行エンジン (MXCorWks.dll) は、この機能をサポートしていません。
ラージオブジェクトのリサイクル
このセクションは翻訳されません。これについては特別な記事があります
ガベージコレクションの監視
.Net Framework をインストールしている場合は、パフォーマンスカウンター ([スタート] メニュー - 管理ツール - パフォーマンス Enter) が表示されます。以下の図に示すように、インスタンスリストから監視するプログラムを選択できます。

これらのパフォーマンス指標の具体的な意味は次のとおりです。

パフォーマンスカウンター	説明
# すべてのヒープ内のバイト数	次のカウンター値の合計を表示します: "レベル 0 ヒープサイズカウンター、レベル 1ヒープサイズカウンタ、レベル 2 ヒープサイズカウンター、およびラージオブジェクトヒープサイズカウンター。このカウンターは、ガベージコレクションヒープに割り当てられている現在のメモリをバイト単位で示します。
# GC Handles (GC ハンドルの数)	現在使用されているガベージコレクションハンドルの数を表示します。ガベージコレクションは、共通言語ランタイムおよびホスティング環境の外部にあるリソースの処理です。
# Gen 0 Collections (Level 2 Collections)	アプリケーションの開始以来、Gen 0 オブジェクト (つまり、最も新しく、最も最近割り当てられたオブジェクト) がガベージコレクションされた回数を示します。レベル 0 のガベージコレクションは、割り当て要求を満たすためにレベル 0 で利用可能なメモリが不十分な場合に発生します。このカウンタは、レベル 0 のガベージコレクションの終了時に増加します。上位レベルのガベージコレクションには、下位レベルのすべてのガベージコレクションが含まれます。このカウンタは、より高いレベル (レベル 1 またはレベル 2) のガベージコレクションが発生すると、明示的にインクリメントされます。このカウンターは、最新の観測値を示します。 _Global_ カウンタ値は不正確なので、無視する必要があります。
# Gen 1 Collections	アプリケーションの開始以降のレベル 1 オブジェクトのガベージコレクションの数を表示します。このカウンターは、レベル 1 ガベージコレクションの終了時に増加します。上位レベルのガベージコレクションには、下位レベルのすべてのガベージコレクションが含まれます。このカウンタは、より高いレベル (レベル 2) のガベージコレクションが発生すると明示的にインクリメントされます。このカウンターは、最新の観測値を示します。 _Global_ カウンタ値は不正確なので、無視する必要があります。
# Gen 2 Collections	アプリケーションの起動以来、Gen 2 オブジェクトがガベージコレクションされた回数を示します。このカウンタは、レベル 2 ガベージコレクション (フルガベージコレクションとも呼ばれます) の終了時に増加します。このカウンターは、最新の観測値を示します。 _Global_ カウンタ値は不正確なので、無視する必要があります。
# Induced GC (誘発された GC の数)	GC.Collect への明示的な呼び出しにより実行されたガベージコレクションのピーク数を示します。ガベージコレクターにコレクションの頻度を微調整させるのが現実的です。
# of Pinned Objects	最後のガベージコレクションで検出された固定オブジェクトの数を表示します。ピン留めされたオブジェクトは、ガベージコレクターがメモリに移動できないオブジェクトです。このカウンターは、ガベージコレクションが行われているヒープ内の固定オブジェクトのみを追跡します。たとえば、レベル 0 のガベージコレクションでは、レベル 0 ヒープ内の固定オブジェクトのみが列挙されます。
# of Sink Blocks in use	現在使用中の同期ブロックの数を表示します。同期ブロックは、同期情報を格納するために割り当てられたオブジェクトベースのデータ構造です。同期ブロックは管理オブジェクトへの弱い参照を保持するため、ガベージコレクターによってスキャンする必要があります。同期ブロックは同期情報のみを保存することに限定されず、COM 相互運用メタデータも保存できます。このカウンタは、同期プリミティブの過剰使用に関連するパフォーマンスの問題を示します。
# Total Committed Bytes	ガベージコレクターによって現在コミットされている仮想メモリの量 (バイト単位) を示します。コミットされたメモリは、ディスクページングファイルに予約された領域の物理メモリです。
# Total Reserved Bytes	ガベージコレクターによって現在予約されている仮想メモリの量 (バイト単位) を示します。予約メモリは、アプリケーション用に予約されている仮想メモリ領域です (ただし、ディスクやメインメモリページはまだ使用されていません)。
% GC の時間 (GC の時間の %)	最後のガベージコレクションサイクル以降、ガベージコレクションの実行に費やされた実行時間の割合を示します。このカウンターは通常、アプリケーションに代わってガベージコレクターがメモリを収集して圧縮する作業を示します。このカウンタは、各ガベージコレクションの終了時にのみ更新されます。このカウンターは平均ではなく、その値は最新の観測値を反映しています。
Allocated Bytes/sec (割り当てられたバイト/秒)	1 秒あたりにガベージコレクションヒープに割り当てられたバイト数を表示します。このカウンタは、割り当てごとではなく、ガベージコレクションの終了時に更新されます。このカウンターは時間の経過に伴う平均ではなく、最近の 2 つのサンプルで観察された値の差をサンプル間の時間で割って表示します。
Finalization Survivors (完了時に残っているオブジェクトの数)	完了を待っているためにコレクションから保持されているガベージコレクションされたオブジェクトの数を表示します。これらのオブジェクトが他のオブジェクトへの参照を保持している場合、それらのオブジェクトは保持されますが、このカウンタではカウントされません。 Completion Memory Promoted from Level 0 および Completion Memory Promoted from Level 1 カウンターは、完了によって保持されたすべてのメモリを表します。このカウンターは累積的なカウンターではなく、各ガベージコレクションの終了時に、その特定のコレクション中にのみ生き残ったオブジェクトの数によって更新されます。このカウンタは、アプリケーションの完了により過剰なシステムオーバーヘッドが発生する可能性があることを示します。
Gen 0 ヒープサイズ (レベル 2 ヒープサイズ)	レベル 0 に割り当てられる最大バイト数を示します。レベル 0 に割り当てられている現在のバイト数を示すものではありません。レベル 0 のガベージコレクションは、最新のコレクション以降の割り当てがこのサイズを超えた場合に発生します。レベル 0 のサイズはガベージコレクターによって微調整され、アプリケーションの実行中に変更される可能性があります。レベル 0 のコレクションの終了時点では、レベル 0 のヒープのサイズは 0 バイトです。このカウンターは、次のレベル 0 ガベージコレクションを呼び出す割り当てのサイズをバイト単位で示します。このカウンタは、ガベージコレクションの終了時に更新されます (割り当てごとではありません)。
Gen 0 Promoted Bytes/Sec (レベル 1 からプロモートされたバイト数/秒)	レベル 0 からレベル 1 にプロモートされた 1 秒あたりのバイト数を表示します。メモリはガベージコレクションから保持された後に昇格されます。このカウンタは、1 秒あたりに作成され、長期間保持されているオブジェクトの数を示します。このカウンターは、最後の 2 つのサンプルで観察された値の差をサンプリング間隔の期間で割った値を示します。
Gen 1 ヒープサイズ (レベル 2 ヒープサイズ)	レベル 1 の現在のバイト数を示します。このカウンターはレベル 1 の最大サイズを示しません。この世代では、オブジェクトは直接割り当てられません。これらのオブジェクトは、以前のレベル 0 ガベージコレクションから昇格されます。このカウンタは、ガベージコレクションの終了時に (割り当てごとではなく) 更新されます。
Gen 1 Promoted Bytes/Sec (レベル 1 から昇格されたバイト数/秒)	レベル 1 からレベル 2 に昇格された 1 秒あたりのバイト数を示します。単に完了を待っているという理由で昇格されたオブジェクトは、このカウンタには含まれません。メモリはガベージコレクションから保存された後に昇格されます。レベル 2 は最も古いレベルであるため、レベル 2 からの昇格はありません。このカウンタは、1 秒あたりに作成される非常に寿命の長いオブジェクトの指標です。このカウンターは、最後の 2 つのサンプルで観察された値の差をサンプリング間隔の期間で割った値を示します。
Gen 2 ヒープサイズ	レベル 2 の現在のバイト数を示します。オブジェクトはこの世代では直接割り当てられません。これらのオブジェクトは、前のレベル 1 ガベージコレクション中にレベル 1 から昇格されました。このカウンタは、ガベージコレクションの終了時に (割り当てごとではなく) 更新されます。
ラージオブジェクトヒープサイズ	ラージオブジェクトヒープの現在のサイズをバイト単位で表示します。ガベージコレクターは、20 KB を超えるオブジェクトをラージオブジェクトとして扱い、これらのレベルを介して昇格されないラージオブジェクトを特別なヒープに直接割り当てます。このカウンタは、ガベージコレクションの終了時に (割り当てごとではなく) 更新されます。
Gen 0 から昇格した Finalization-Memory (レベル 1 から昇格した完了メモリ)	完了を待機しているためだけにレベル 0 からレベル 1 に昇格したメモリのバイト数を示します。このカウンタは累積カウンタではなく、最後のガベージコレクションの終了時に観測された値を示します。
プロモートされたファイナライゼーション - 第 1 世代からのメモリ	単に完了を待っているためにレベル 1 からレベル 2 に昇格したメモリのバイト数を示します。このカウンタは累積カウンタではなく、最後のガベージコレクションの終了時に観測された値を示します。最後のガベージコレクションがレベル 0 コレクションだった場合、このカウンターは 0 にリセットされます。
Gen 0 からプロモートされたメモリ (Gen 1 からプロモートされたメモリ)	ガベージコレクション後に保持され、Gen 0 から Gen 1 にプロモートされたメモリのバイト数を示します。完了を待っている間にのみ発生するオブジェクトは、このカウンタから除外されます。このカウンタは累積カウンタではなく、最後のガベージコレクションの終了時に観測された値を示します。
Gen 1 からプロモートされたメモリ (Gen 1 からプロモートされたメモリ)	ガベージコレクション後に保持され、Gen 1 から Gen 2 にプロモートされたメモリのバイト数を示します。完了を待っている間にのみ発生するオブジェクトは、このカウンタから除外されます。このカウンタは累積カウンタではなく、最後のガベージコレクションの終了時に観測された値を示します。最後のガベージコレクションがレベル 0 コレクションだった場合、このカウンターは 0 にリセットされます。