JetBrains Rider 2026.1 Help

自動インスペクション

dotMemory は、メモリに関する最も一般的な種類の問題について、スナップショットを自動的にチェックして作業を軽減します。 どこから始めればよいかわからない場合は、これらのインスペクションがスナップショットの分析の優れた出発点になります。 インスペクション ビューを開くには、スナップショット分析タブの対応するタブをクリックします。 自動インスペクションとともに、このビューには、メモリ使用量と管理対象ヒープセグメントの断片化を示すダイアグラムが表示されます。

メモリ使用量のダイアグラム

メモリ使用量のダイアグラム

このビューには、スナップショットのメモリ使用量を示す 2 つのダイアグラムが表示されます。

  • 最大サイズダイアグラム

    この図は「アプリでメモリの大部分を占めているオブジェクトは何か?」という質問に答えます。特定の型のオブジェクトがどれだけメモリを占有しているかを示しています。 図の項目をクリックすると、それが分析対象となり、 型別グループビューに移動します。

  • 最大保持サイズダイアグラム

    この図は「アプリケーションの主要なオブジェクトは何か?」という質問に答えます。ドミネーター、つまり他のすべてのアプリオブジェクトをメモリに保持している主なオブジェクトのリストを示しています。 図の項目をクリックすると、それが分析対象となり、 ドミネーター別グループビューに移動します。

自動インスペクション

自動メモリインスペクション

文字列重複

既存のものを再利用するのではなく、同じ値を持つ文字列を繰り返し作成することは、メモリを無駄にします。 dotMemory は重複した文字列を検出し、無駄なメモリ量を示します。

オブジェクトを分析するには

  • インスペクションヘッダーのリンクをクリックするか、リスト内の特定のオブジェクトセットをダブルクリックします。

問題を解決するには

  • 同じ値を持つ文字列が大量のメモリを浪費したり、大量のトラフィックを生成したりする場合 (たとえば、アプリがテキスト入力を解析する場合) は、 文字列インターン(英語)を実装することを検討してください。

スパース配列

スパース配列は、ほとんどがゼロ要素で埋められた配列です。 スパース配列は、パフォーマンスとメモリ使用量の観点からは非効率的です。 dotMemory は、スパース配列を自動的に検出し、スパース配列によってどれだけのメモリが失われているか (ゼロ値で占められているか) を表示します。

スパース配列を解析するには

  • インスペクションヘッダーのリンクをクリックするか、リスト内の特定のオブジェクトをダブルクリックします。

ファイナライズ可能オブジェクト

ファイナライズ可能オブジェクトは、 Finalize() メソッドを使用してアンマネージリソースを解放するオブジェクトです。 このパターンを使用する問題は、まず、ファイナライズ可能なオブジェクトの寿命が少なくとももう 1 回 GC サイクルだけ延長され、2 番目に、 Finalize() メソッドを実行するファイナライズスレッドが予期せず実行されることです。 これにより、解放されたリソースをできるだけ早く回収したい場合や、突然パフォーマンスが低下する可能性がある場合には、問題が発生する可能性があります。 dotMemory は、ファイナライズのためにキューに入れられたすべてのオブジェクトと、 前のスナップショット以降にファイナライズされたオブジェクトを検出して表示します。

ファイナライズ可能オブジェクトを分析するには

  1. インスペクションヘッダーのリンクをクリックするか、リスト内の任意のタイプをダブルクリックします。

  2. IDisposable を実装する型だけを残すには、 フィルターフィールドに #d と入力します。 すべての使い捨てタイプは Disposable アイコンでマークされています。

  3. IDisposable を実装してい ない型だけを残すには、 フィルターフィールドに !d と入力します。

問題を解決するには

  • 問題を引き起こすタイプの IDisposable インターフェースを実装し、その Dispose() メソッドを介してすべてのアンマネージリソースを解放します。 破棄パターンの詳細については、「マイクロソフトラーン 」を参照してください。

イベントハンドラーのリーク

このようなリークは、オブジェクト (リスナーと呼びます) を他のオブジェクト (ソースと呼びます) のイベントにサブスクライブするときに発生します。 例: Timer1.Tick += OnTimer; サブスクリプション中に、ソースオブジェクトはリスナーオブジェクトのイベントハンドラーへの参照を取得します。 リスナーを削除すると、この参照によりガベージコレクションが実行されなくなります。 dotMemory は、イベントハンドラーで参照されているが、対応するイベントからサブスクライブ解除されていないオブジェクトを自動的に検索します。

オブジェクトを分析するには

  • インスペクションヘッダーのリンクをクリックするか、リスト内の特定のオブジェクトをダブルクリックします。

問題を解決するには

  • リスナーが不要になったときに、そのイベントからリスナーの登録を解除します。 次に例を示します: Timer1.Tick -= OnTimer;

WPF バインディングリーク

WPF データバインディングパターンに違反すると、メモリリークが発生することもあります。 ソースオブジェクトのプロパティにデータバインディングを実行すると、バインディングターゲットオブジェクトはプロパティ変更通知のリッスンを開始します。 プロパティが DependencyProperty オブジェクトではなく、ターゲットオブジェクトが INotifyPropertyChanged インターフェースを実装していない場合、ソースオブジェクトと、ソースオブジェクトが参照するすべてのオブジェクトでメモリリークが発生する可能性があります。 dotMemory は、このようなバインディングパターン違反を検出し、この種類のリークを引き起こす可能性のあるオブジェクトのリストを表示します。

オブジェクトを分析するには

  • インスペクションヘッダーのリンクをクリックするか、リスト内の特定のオブジェクトをダブルクリックします。

問題を解決するには

  • ソースオブジェクトに INotifyPropertyChanged インターフェースを実装させるか、 ClearBinding メソッドを使用してバインディングを削除します。

WPF コレクションバインディングリーク

このリークは、上で説明した WPF バインディングリークに似ています。 INotifyCollectionChanged インターフェースを実装していないコレクションへのバインディングがある場合、WPF はこのコレクションへの強い参照を作成します。 その結果、アプリケーションの存続期間中、メモリ内に残ります。 dotMemory は、このようなオブジェクトを検出して表示します。

オブジェクトを分析するには

  • インスペクションヘッダーのリンクをクリックするか、リスト内の特定のオブジェクトをダブルクリックします。

問題を解決するには

  • ソースコレクションが INotifyCollectionChanged インターフェースを実装するようにします。 別の方法は、すでに INotifyCollectionChanged インターフェースを実装しているため、 ObservableCollection コレクションを使用することです。

依存関係プロパティのリーク

このようなリークは、イベントハンドラーのリークと同じ理由で発生します。 ガベージコレクターは、 RemoveValueChanged メソッドを使用してサブスクライブ解除されるまで、 AddValueChanged メソッドを通じて DependencyProperty の変更でサブスクライブされたオブジェクトを収集しません。 dotMemory は、このようなオブジェクトをすべて検出して表示します。

オブジェクトを分析するには

  • インスペクションヘッダーのリンクをクリックするか、リスト内の特定のオブジェクトをダブルクリックします。

問題を解決するには

  • サブスクライブされたオブジェクトの存続期間が終了したら、 RemoveValueChanged メソッドを使用してサブスクライブ解除を処理します。

x:Name WPF メモリリーク

このようなリークは、次のような WPF の特性によって発生します。WPF は、XAML で宣言されており x:Name ディレクティブが使用されている UI 要素への強力なグローバル参照を作成します。 例えば:

<XNameTest:UserControl1 Grid.Row="0" x:Name="myControl1"/>

そのように宣言された要素を動的に削除しても、その要素はメモリ内に残ります。

オブジェクトを分析するには

  • インスペクションヘッダーのリンクをクリックするか、リスト内の特定のオブジェクトをダブルクリックします。

問題を解決するには

  • リークを解消する方法の 1 つは、XAML の代わりに C# コードで UI 要素を宣言することです。 別の方法は、UI 要素を削除するときに、親コントロールの UnregisterName メソッドを呼び出すことです。 例: this.UnregisterName("myControl1");

ヒープの断片化

ヒープ フラグメンテーション ダイアグラムを使用して、管理対象ヒープセグメントの断片化を評価します。

  • 第 1 世代および第 2 世代のヒープセグメント。

  • ラージオブジェクトヒープ (LOH) – 大きなオブジェクト (85,000 バイト以上) 用の個別のヒープ。 LOH の断片化は深刻な問題になる可能性があります。

  • 固定オブジェクトヒープ - ヒープ内での移動が禁止されているオブジェクト用の別のヒープ。 固定オブジェクトを別のオブジェクトセットとして開くことができます。

  • 凍結オブジェクトヒープ (FOH) – 不変オブジェクト用の個別のヒープ。

ダイアグラムのヘッダーをクリックすると、スナップショット内のすべてのオブジェクトの 世代別グループビューが開きます。

ヒープの断片化
  1. ヒープセグメント名。

  2. セグメント内のヒープの数。

    ダイアグラムの各バーは、特定のヒープを表しています。

  3. GC によって定義された合計ヒープセグメントサイズ。

    図のバーの長さは、セグメント内の特定のヒープの合計サイズに対応しています。 合計 のサイズは、 サイズは、固定固定解除空き の合計より少し大きい場合があります。 合計 のサイズには、位置合わせやパディング、その他の日的用途で使われるメモリブロックも含まれています。

  4. 固定されたオブジェクトの合計サイズ。

    固定されたオブジェクトは、ヒープ内で移動できません。 通常、このようなオブジェクトは、管理されていないコードによって使用されるか、 fixed ステートメントを使用した結果である可能性があります。

  5. ヒープセグメントに割り当てられているすべてのオブジェクト(固定オブジェクトを除く)の合計サイズ。

  6. ヒープセグメント内の空きメモリの合計サイズ。

ヒープ フラグメンテーション では、特定のオブジェクトセット (固定されたオブジェクト) を開くこともできます。

2026 年 6 月 12 日