.NETランタイムでのオブジェクトの配置に関する真実の一部

ご存じのとおり、.NETメモリでは、スタック（スタック）とマネージヒープ（マネージヒープ、次にヒープ）の2つのカテゴリに分類されます。 スタック上には、オブジェクト（ObjectInstance）へのリンク（ObjectRef）があり、これはヒープ上にあります。

この記事では、ヒープ上のオブジェクトの場所に焦点を当てます。

読者は次の知識を持っていると想定されます。
1.スタック
2.マネージヒープ
3. GC
4.弱い参照

ObjectInstance

ObjectInstance -ObjectRefが指すアドレスにあるデータ構造（オブジェクト）。
重要なタイプのインスタンスが保存される場合があります。
1.スレッドスタック内
2. GCヒープ内。
サイズに応じて、参照タイプのインスタンスを保存できます。
1.ガベージコレクターヒープ（サイズが最大85000バイトのオブジェクト）
2.ラージオブジェクトヒープ（85,000バイトを超えるオブジェクト）



図1.オブジェクトのインスタンスの構造の例

図1からわかるように、ObjectInstanceには次のフィールドが含まれています。
1.オブジェクトヘッダー
2.タイプハンドル（このフィールドの検討は記事の範囲外です）
3.オブジェクトのインスタンスのフィールド
4.文字列リテラルへのリンク

オブジェクトヘッダー

図1をもう一度見てみましょう。ご覧のように、ObjectRefは、ObjectInstanceの先頭から4バイトのアドレスオフセットを指します。 これは最適化のために行われます-オブジェクトヘッダーには、オブジェクトインスタンスの残りのフィールドほど頻繁には使用されない情報が含まれます。
このフィールドには、同期ブロックエントリテーブルのセル番号が含まれます。 数は1からカウントされます。 ロックステートメントまたはGetHashCode（）メソッドがObjectInstanceに使用されたことがない場合、オブジェクトヘッダーセルに0が格納されます。
同期ブロックエントリテーブルとObjectInstanceはインデックスによってリンクされているため、CLRはメモリ内でこのテーブルのサイズを自由に変更できます。
インデックスがオブジェクトヘッダーに含まれる同期ブロックエントリテーブルのセルには、同じObjectInstanceへの弱いリンクが含まれます。これは、CLRがこのセルの所有者を追跡できるようにするためです（たとえば、スレッドを同期するため）。
また、このセルには、SyncBlock List構造内のSyncBlockオブジェクトへの参照が含まれています。 SyncBlockには、有用ではあるがめったに使用されない情報が含まれています。
1.サンク情報
2. AppDomainインデックス
3.オブジェクトロックデータ
4.ハッシュコード

例を考えてみましょう。 ダンコード：

class Sample { TestClass sync = new TestClass (); void Main() { lock (sync) { //, } sync.GetHashCode(); } } * This source code was highlighted with Source Code Highlighter .

1. class Sample { TestClass sync = new TestClass (); void Main() { lock (sync) { //, } sync.GetHashCode(); } } * This source code was highlighted with Source Code Highlighter .
2. class Sample { TestClass sync = new TestClass (); void Main() { lock (sync) { //, } sync.GetHashCode(); } } * This source code was highlighted with Source Code Highlighter .
3. class Sample { TestClass sync = new TestClass (); void Main() { lock (sync) { //, } sync.GetHashCode(); } } * This source code was highlighted with Source Code Highlighter .
5. class Sample { TestClass sync = new TestClass (); void Main() { lock (sync) { //, } sync.GetHashCode(); } } * This source code was highlighted with Source Code Highlighter .
6. class Sample { TestClass sync = new TestClass (); void Main() { lock (sync) { //, } sync.GetHashCode(); } } * This source code was highlighted with Source Code Highlighter .
7. class Sample { TestClass sync = new TestClass (); void Main() { lock (sync) { //, } sync.GetHashCode(); } } * This source code was highlighted with Source Code Highlighter .
8. class Sample { TestClass sync = new TestClass (); void Main() { lock (sync) { //, } sync.GetHashCode(); } } * This source code was highlighted with Source Code Highlighter .
9. class Sample { TestClass sync = new TestClass (); void Main() { lock (sync) { //, } sync.GetHashCode(); } } * This source code was highlighted with Source Code Highlighter .
10. class Sample { TestClass sync = new TestClass (); void Main() { lock (sync) { //, } sync.GetHashCode(); } } * This source code was highlighted with Source Code Highlighter .
11. class Sample { TestClass sync = new TestClass (); void Main() { lock (sync) { //, } sync.GetHashCode(); } } * This source code was highlighted with Source Code Highlighter .
12. class Sample { TestClass sync = new TestClass (); void Main() { lock (sync) { //, } sync.GetHashCode(); } } * This source code was highlighted with Source Code Highlighter .
13. class Sample { TestClass sync = new TestClass (); void Main() { lock (sync) { //, } sync.GetHashCode(); } } * This source code was highlighted with Source Code Highlighter .

class Sample { TestClass sync = new TestClass (); void Main() { lock (sync) { //, } sync.GetHashCode(); } } * This source code was highlighted with Source Code Highlighter .

3行目では、同期オブジェクトのObject Headerフィールドに値0が含まれていますが、次に7行目では、フィールド値が変化してゼロ以外になります。 これは、CLRがSyncBlockリストにSyncBlockオブジェクトを作成し、オブジェクトヘッダーにレコードインデックスを配置するためです。 11行目では、ハッシュ値がSyncBlockオブジェクトに配置されています。
SyncBlockオブジェクトの残りのフィールドについては、この記事の範囲外です。

オブジェクトインスタンスフィールドと文字列リテラル

Type Handleの背後には、インスタンスフィールドのリストがあり、その長さは異なります。 デフォルトでは、メモリが効率的に使用され、フィールド間のギャップが最小になるように、インスタンスフィールドが配置されます。
リスト1はSimpleClassクラスを示しています。このクラスでは、サイズの異なるいくつかのインスタンス変数が宣言されています。

リスト1

クラス SimpleClass { プライベート バイト b1 = 1; // 1バイト プライベート バイト b2 = 2; // 1バイト プライベート バイト b3 = 3; // 1バイト プライベート バイト b4 = 4; // 1バイト private char c1 = 'A' ; // 2バイト private char c2 = 'B' ; // 2バイト プライベート ショート s1 = 11; // 2バイト プライベート ショート s2 = 12; // 2バイト private int i1 = 21; // 4バイト private long l1 = 31; // 8バイト プライベート 文字列 str = "MyString" ; // 4バイト（これは単なるOBJECTREFです） //インスタンスフィールドの合計サイズは28バイトです 静的 ボイドメイン（） { SimpleClass simpleObject = new SimpleClass （）; 帰る } } *このソースコードは、 ソースコードハイライターで強調表示されました。

図2. SimpleClassオブジェクトインスタンスの[メモリ]ウィンドウ

図 図2は、SimpleClassオブジェクトのインスタンスがメモリの内容を表示するウィンドウでどのように見えるかを示しています。
デバッガメモリウィンドウを開く前に（デバッグ-> Windows->メモリ-> Memory1）、returnステートメントにブレークポイントが設定されていました。 次に、ECXレジスタに含まれるsimpleObjectアドレスで、メモリダンプを表示する必要があるオブジェクトのインスタンスのアドレスを決定しました。
1.最初の4バイトブロックはsyncblk番号です。 このオブジェクトの同期コードを記述しなかったため（そしてそのハッシュコードにアクセスしなかったため）、この数は0です。
2.スタックに配置されたsimpleObject変数に格納されたオブジェクトへの参照は、4バイトを示し、その先頭はオフセット4です。
3.次に、変数l1の8バイト値のメモリ内への配置です。
4. String型のstr変数は、GCヒープでホストされる文字列のインスタンスを指す4バイトのObjectRef参照によって表されます。
5.次に、int型の変数i1が8バイトを占有して配置されます。
6. char型の2つの変数-c1およびc2-が並んで配置されています。
7.短いタイプの2つの変数-s1およびs2-も「並んで」配置されます。
8.タイプByteの変数b1、b2、b3、b4はDWORDにパックされ、「サイドバイサイド」に配置されます。
デフォルトでは、オブジェクトのメンバーは、ソースコードで宣言されている順序で必ずしもメモリに配置されるとは限りません。
メモリにフィールドを配置するときに字句シーケンスを観察するには、StructLayoutAttribute属性を使用する必要があります。 この属性は、次の値を持つLayoutKind列挙を入力値として受け入れます。
1.シーケンシャル-オブジェクトのメンバーは、アンマネージメモリにエクスポートされたときの外観の順序で順番に配置されます。
2.明示的-管理されていないメモリ内のオブジェクトの各メンバーの正確な位置は明示的に制御されます。 各メンバーは、FieldOffsetAttribute属性を使用して、タイプ内のこのフィールドの位置を示す必要があります。
3.自動-CLRは、アンマネージメモリ内のオブジェクトのメンバーに適切な場所を自動的に選択します。 この列挙メンバーを使用して定義されたオブジェクトへのアクセスは、マネージコードの外部では許可できません。 このような操作を実行しようとすると、例外がスローされます。

メモリの非構造化コンテンツを調べた後、Son of Strike（SOS）ユーティリティを使用してオブジェクトのインスタンスを調べます。
プロジェクトをアンマネージデバッグモードにし（プロパティ->デバッグ->アンマネージコードデバッグを有効にする）、イミディエイトウィンドウ（ctrl + alt + I）を開き、次のコマンドを実行します。

1. .load sos
2. ！DumpHeapタイプのSimpleClass

*このソースコードは、 ソースコードハイライターで強調表示されました。

出力の結果として、特定のタイプのすべてのヒープとすべてのインスタンスのコンテンツを取得します。



図3.「！DumpHeap -type SimpleClass」コマンドの結果

図3からわかるように、オブジェクトのサイズは36バイトです。 これらの36バイトには次のものが含まれます。
1. SimpleClassインスタンスのフィールドは28バイトを占有します（SimpleClassインスタンスにはサイズが4バイトのリテラルテーブルへの参照のみが含まれるため、文字列の長さは関係ありません）。
2.残りの8バイトは、オブジェクトヘッダー（4バイト）およびタイプハンドル（4バイト）に含まれています。

simpleObjectインスタンスのアドレスを見つけました。コマンド "！DumpObj 0x0214ba30"を使用して、このインスタンスの内容をダンプしましょう。



図4.「！DumpObj 0x0214ba30」コマンドの結果

C＃コンパイラは、デフォルトで、クラスメンバーにLayoutType.Autoレイアウトを使用するため、クラスローダーは、フィールド間のギャップを最小化するために適切と思われるようにフィールドを配置できます。

材料：
MSDN