Chrome デベロッパーツールの JavaScript メモリ分析のグラフィカルな紹介-jsチュートリアル-php.cn

メモリリーク は、コンピュータの利用可能なメモリが徐々に減少することです。これは、プログラムが使用する一時メモリの解放に継続的に失敗する場合に発生します。 JavaScript Web アプリケーションでは、リーク やオーバーフローなど、ネイティブアプリケーションで発生するメモリ関連の問題が頻繁に発生します。Web アプリケーションは、 ガベージコレクションの一時停止 にも対処する必要があります。

JavaScript は自動メモリ管理のためにガベージコレクションを使用しますが、効果的なメモリ管理は依然として重要です。この記事では、JavaScript Web アプリケーションのメモリ問題の分析について説明します。機能について学習するときは、必ずサンプルを試して、これらのツールが実際にどのように機能するかについての理解を深めてください。この記事で使用されている用語を理解するには、「Memory 101」ページを読んでください。注: これから使用する機能の一部は、現在ブラウザの Chrome Canary バージョンでのみ利用可能です。アプリケーションのメモリ問題を分析するための最適なツールを入手するには、このバージョンを使用することをお勧めします。

考慮する必要がある質問

一般に、メモリリークの問題が発生したと思われる場合は、次の 3 つの質問について考える必要があります:

私のページはメモリを使いすぎていませんか? - 時間タイムラインメモリビューと Chrome タスクマネージャーは、メモリの使用量が多すぎるかどうかを確認するのに役立ちます。メモリビューは、ページレンダリング中に DOM ノード数、document のドキュメント数、および JS イベントリッスン数を追跡できます。経験則として: 不要になった DOM 要素への参照を避け、不要なイベントリスナーを削除し、使用しない可能性のある大きなデータの塊を保存するときは注意してください。
私のページにメモリリークはありますか? - ObjectAllocation Tracker (Object allocation Tracker) は、JS オブジェクトの割り当てをリアルタイムで表示することで、リークを特定するのに役立ちます。ヒープアナライザー (Heap Profiler) を使用して JS ヒープスナップショットを生成し、メモリマップを分析してスナップショット間の差異を比較することで、ガベージコレクションによってクリーンアップされていないオブジェクトを見つけることもできます。
ページのガベージコレクションはどのくらいの頻度で強制されますか? - ページのガベージコレクションが非常に頻繁に行われる場合は、ページにメモリが頻繁に割り当てられる可能性があることを意味します。タイムラインメモリビューは、関心のある一時停止を見つけるのに役立ちます。

用語と基本概念

このセクションでは、メモリ分析で使用される一般的な用語を紹介します。これらの用語は、他の言語のメモリ分析を行うツールにも適用されます。ここでの用語と概念は、ヒーププロファイラー UI ツールと関連ドキュメントで使用されます。

これらは、メモリ分析ツールを効果的に使用する方法に慣れるのに役立ちます。 Java、.NET などの言語のメモリ分析ツールを使用したことがある場合、これはレビューになります。

オブジェクトサイズ

メモリを、基本的な型 (数値や文字列など) とオブジェクト (連想配列) のグラフとして考えてください。一連の関連点をまとめた次の図のようになります。

オブジェクトにはメモリを使用する 2 つの方法があります:

オブジェクト自体が
を直接使用し、他のオブジェクトへの参照を暗黙的に維持します。この方法は、それらのオブジェクトのガベージコレクション (GC と呼ばれます) を防ぎます。オブジェクトの自動リサイクル。

DevTools のヒーププロファイラー (DevTools の [プロファイル] タブにあるメモリ問題の分析に使用されるツール、ヒーププロファイラー) を使用すると、さまざまな情報が表示される列がいくつかあることに驚くかもしれません。そのうちの 2 つは、直接占有メモリ (浅いサイズ) と 占有総メモリ (保持サイズ) です。では、これらは何を意味するのでしょうか?

メモリを直接占有（浅いサイズ、参照されるオブジェクトが占有するメモリを除く）

これはオブジェクト自体が占有するメモリです。

典型的な JavaScript オブジェクトは、オブジェクトを記述し、その直接値を保存するために予約されたメモリを持っています。一般に、直接メモリを大幅に占有するのは配列と文字列だけです (浅いサイズ)。ただし、文字列と配列は多くの場合、メインデータ部分をレンダラーメモリに保存し、JavaScript オブジェクトスタック内の小さなラッパーオブジェクトのみを公開します。

レンダラーメモリとは、分析するページのレンダリングプロセスで使用されるすべてのメモリを指します。ページ自体のメモリ + ページ内の JS ヒープによって使用されるメモリ + 関連するワーカープロセス (ワーカー) で使用される JS ヒープメモリへのページによってトリガーされます。ただし、小さなオブジェクトは、他のオブジェクトがガベージによって自動的に収集されないようにすることで、間接的に大量のメモリを占有する可能性があります。

占有される合計メモリ (参照オブジェクトによって占有されるメモリを含む保持サイズ)

オブジェクトが削除されると、そのオブジェクトが参照する依存オブジェクトは GC ルート (GC ルート) から参照できなくなり、占有されます。メモリは解放され、オブジェクトによって占有されるメモリの合計には、これらの依存オブジェクトによって占有されるメモリが含まれます。

GC rootはcontrollers(handles)で構成されており、これらのコントローラー(ローカルまたはグローバル)は、ビルトイン関数(ネイティブコード)によってV8に組み込まれています。エンジンの外にオブジェクトが作成されます。これらのコントローラーはすべて、ヒープスナップショットの GC ルート > ハンドルスコープ および GC ルート >グローバルハンドラーにあります。この記事でこれらのコントローラーを紹介する場合、ブラウザーの実装を深く理解していないと混乱する可能性があります。 GC ルートとコントローラーについてはあまり心配する必要はありません。

ユーザーにとって重要ではない内部 GC ルートが多数あります。アプリケーションの観点から見ると、次のような状況があります:

Window グローバルオブジェクト (すべて
iframe 内)。ヒープスナップショットには距離フィールドがあり、これは、ウィンドウオブジェクトから対応するオブジェクトまでの最短パス長です。
ドキュメントが通過できるすべての DOM ノードで構成されるドキュメント DOM ツリー。すべてのノードが対応する JS によって参照されるわけではありませんが、JS によって参照されるノードはドキュメントが存在する限り保持されます。
コードを
デバッグするとき、または DevTools コンソール内 (例: コンソール内のコードが実行された後) に作成される可能性のあるオブジェクトが多数あります。

注:

ヒープスナップショットの作成時に、コンソールでコードを実行したり、デバッグブレークポイントを有効にしたりしないことをお勧めします。メモリマップはルートから始まります。ルートはブラウザの window オブジェクトまたは Node.js

モジュールの Global オブジェクト。これらのオブジェクトがメモリからどのように再利用されるかは、ユーザーの制御下にはありません。

window对象或Node.js模块Global

GC ルートによってトラバースできないオブジェクトはメモリがリサイクルされます。

注:

直接占有メモリフィールドと総メモリ占有フィールドのデータはバイト単位で表されます。オブジェクトが占有するメモリツリーの合計

ヒープは、相互に関連するさまざまなオブジェクトで構成されるネットワーク構造であることを以前に学びました。デジタルの世界では、この構造は

グラフ

またはメモリグラフと呼ばれます。グラフはエッジで接続されたノードで構成されており、それらはすべてラベル付けされています。

ノード
(またはオブジェクト) ノードのラベル名は、ノードを作成したコンストラクター関数の名前によって決定されます
エッジ
ラベル名は属性Nameです

ドミネーター

各オブジェクトにはドミネーターがあるため、ドミネーターはツリー構造のようなものです。オブジェクトのコントローラは、それが支配するオブジェクトを直接参照することはできません。つまり、支配されるオブジェクトのツリー構造は、グラフ内のスパニングツリーではありません。

上の図:

ノード 1 がノード 2 を支配する
ノード 2 がノード 3、4、6 を支配する
ノード 3 がノード 5 を支配する
ノード 5 がノード 8 を支配
ノード 6 がノード 7 を支配します

以下の例では、ノード #3是#10的支配者，但#7也在每个从GC到#10 がパスに表示されます。このように、B オブジェクトがルートノードから A オブジェクトまでのすべてのパスに出現する場合、B オブジェクトは A オブジェクトの支配的なオブジェクトになります。

V8 の概要

このセクションでは、V8 JavaScript 仮想マシン (V8 VM または VM) に関連するいくつかのメモリ関連の概念について説明します。メモリを分析する場合、ヒープスナップショットを理解するためにこれらの概念を理解しておくと役立ちます。

JavaScript オブジェクトの説明

には 3 つのプリミティブ型があります:

数値 (3.14159.. など)
ブール値 (true または false)
文字型 (String s) ('Wer など)ナーハイゼンベルク')

それらは他の値を参照せず、葉ノードまたは終端ノードのみになります。

数値は、次の 2 つの方法のいずれかで保存されます:

31 ビットの整数直接値: 小さい整数 (小さい整数)(SMI)、または
ヒープオブジェクト。ヒープ値として参照されます。ヒープ値は、double などの SMI ストレージに適さないデータを保存するために、またはこの値の属性値を設定するなど、値をボックス化する必要がある場合に使用されます。
キャラクター

VMヒープ

外部
レンダラーメモリ
新しく作成された JavaScript オブジェクトには、JavaScript ヒープ (または
VM ヒープ

ローカルオブジェクト は、ヒープオブジェクトとは異なり、

ライフサイクル

中に V8 ガベージコレクターによって処理されず、JavaScript ラッピングオブジェクトによってのみ参照できます。連結文字列は、一対の文字列を結合することによって形成されるオブジェクトであり、結合の結果です。

接続文字列

は、必要な場合にのみマージされます。連結された文字列と同様に、部分文字列を構築する必要があります。例: a と

を連結すると、連結の結果を表すために使用される文字列 (a, b) が得られます。後でこの結果を d と連結すると、別の連結された文字列 ((a, b), d) が得られます。 配列 (Array

- 配列は数字キーを持つオブジェクトです。これらは、大量のデータを保存する場合に V8 エンジンで広く使用されています。辞書などのキーと値のペアを持つオブジェクトは、配列を使用して実装されます。 典型的な JavaScript オブジェクトは、2 つの配列タイプのいずれかに格納できます:

名前付きプロパティ、

数値要素
プロパティが少数しかない場合、それらは JavaScript オブジェクトに直接格納されます自体。

Map

- オブジェクトタイプとその構造を記述するために使用されるオブジェクト。たとえば、マップを使用してオブジェクトの構造を記述し、オブジェクトのプロパティにすばやくアクセスできるようにしますオブジェクトグループ 各ローカルオブジェクトグループは、相互に関連するオブジェクトのセットで構成されます。たとえば、DOM サブツリーでは、各ノードは、関連付けグラフを形成する親要素、次の子要素、および次の兄弟要素にアクセスできます。ネイティブ要素は JavaScript ヒープ内で表されないことに注意してください。そのため、ラッピングオブジェクトの作成中にネイティブ要素のサイズは 0 になります。

各ラッパーオブジェクトにはローカルオブジェクトへの参照があり、これらのローカルオブジェクトに対する操作を渡すために使用されます。これらのローカルオブジェクトには、ラッピングオブジェクトへの参照もあります。ただし、これによって回復不能なループが作成されるわけではありません。GC は、ラップされたオブジェクトへの参照を持たなくなったローカルオブジェクトを識別して解放するのに十分な機能を備えています。ただし、ラッパーオブジェクトが解放されない場合は、すべてのオブジェクトグループと関連するラッパーオブジェクトが保持されます。

前提条件と役立つヒント

Chrome タスクマネージャー

注:メモリ分析に Chrome を使用する場合は、クリーンなテスト環境をセットアップするのが最善です

Chrome のメモリマネージャーを開き、関連する操作を実行してメモリフィールドを観察しますページ上でをクリックすると、この操作によってページが大量のメモリを占有するかどうかをすぐに判断できます。メモリマネージャーは、Chrome メニュー > [ツール] から、または Shift + Esc キーを押すことで見つけることができます。

開いたら、ヘッダーを右クリックし、[JavaScript で使用されるメモリ] オプションを選択します。

DevTools タイムラインを通じてメモリの問題を特定します

問題を解決するための最初のステップは、問題が存在することを証明できるようにすることです。これには、問題のベースライン測定として機能する再現可能なテストを作成する必要があります。再現可能な手順がなければ、問題を確実に測定することはできません。言い換えれば、比較のためのベースラインがなければ、どのような変更が問題の原因となったのかを知る方法はありません。

タイムラインパネルは、プログラムに問題がある場合にそれを見つけるのに非常に役立ちます。 Web アプリケーションまたは Web サイトがロードされ、対話している瞬間が表示されます。すべてのイベント: リソースの読み込みから JavaScript のデコード、スタイル計算、ガベージコレクションの一時停止、ページの再描画まで。すべてがタイムライン上に表示されます。

メモリの問題を分析する場合、タイムラインパネルのメモリビュー(メモリビュー)を使用して以下を観察できます:

合計メモリ使用量 – メモリ使用量は増加しましたか?
DOM ノード数
ドキュメントの数
登録されたイベントリスナーの数

メモリ分析中にメモリリークを特定する方法の詳細については、Zack Grossbart Chrome DevToolsを使用したメモリプロファイリングを参照してください

問題

まず最初に行うことは、メモリリークの原因となっている可能性があるアクションを特定することです。これは、ページ上で発生するマウスオーバー、クリック、またはページ上のパフォーマンス低下を引き起こす可能性のあるその他のインタラクションなどのあらゆるイベントです。

タイムラインパネル (Ctrl+E または Cmd+E) で記録を開始し、テストするアクションを実行します。ガベージコレクションを強制するには、パネル上のゴミ箱アイコン (

) をクリックします。

ここでは、一部のポイントがガベージコレクションされないメモリリークの例を示します:

テストを繰り返した後、(メモリパネルの上に) ギザギザのグラフィックが表示された場合は、有効期間の短いオブジェクトが多数存在します。プログラム内で。また、一連のアクションによってメモリが一定の範囲内に収まらず、DOM ノードの数が最初の数に戻らない場合は、メモリリークが疑われる可能性があります。

メモリに問題があると判断したら、

プロファイルパネルのヒーププロファイラーを使用して問題の原因を特定できます。

例: タイムラインを通じてメモリの問題を効果的に

練習分析するのに役立つ、メモリ増加の例を試してください。

Memory Recycler

Memory Collector (V8 のものなど) は、どのオブジェクトが live(live) であるかを特定できる必要がありますが、dead(garbage) とみなされるオブジェクトは 不可能です(unreachable)を参照。

JavaScript 実行時のロジックエラーにより、

ガベージコレクション (GC) がガベージオブジェクトの収集に失敗した場合、これらのガベージオブジェクトはリサイクルできなくなります。このような状況では、最終的にアプリケーションの速度がどんどん遅くなります。

たとえば、コードを作成するときに、一部の

変数とイベントリスナーは使用されなくなりますが、一部のコードでは引き続き参照されます。参照がまだ存在する限り、参照されたオブジェクトは GC によって正しくリサイクルできません。

アプリケーションの実行中に、一部の DOM オブジェクトが更新削除された可能性があります。DOM オブジェクトを参照する変数を必ずチェックし、それらを null に設定してください。他のオブジェクト (または他の DOM 要素) を参照している可能性があるオブジェクトのプロパティを確認してください。成長する可能性のある変数キャッシュに注目してください。

ヒープアナライザー

スナップショットを取得します

プロファイルパネルで、ヒープスナップショットを取得を選択し、開始をクリックするか、Cmd + EまたはCtrl + Eを押します:

スナップショットは最初にレンダリングに保存されます。サーバープロセスのメモリ内。これらはオンデマンドで DevTools にインポートされ、スナップショットボタンをクリックすると表示されます。スナップショットが DevTools にロードされて表示されると、スナップショットタイトルの下の数字は、到達可能な JavaScript オブジェクトによって占有されるメモリの合計量を示します。

例: action でガベージコレクションの例を試し、タイムラインパネルでメモリ使用量を監視します。

スナップショットをクリア

すべてのスナップショットをクリアするには、すべてクリアボタンアイコン()をクリックします:

注: DevToolsウィンドウを閉じると、収集されたスナップショットをレンダリングメモリ。 DevTools を再度開くと、以前のスナップショットリストがまだ残っています。

前に述べたことを思い出してください。スナップショットを生成するときに、DevTools で GC を強制できます。スナップショットを取得すると、GC が自動的に実行されます。タイムラインのゴミ箱（ガベージコレクション）ボタン（

）をクリックすると簡単にガベージコレクションを行うことができます。

例: 分散オブジェクトを試し、ヒーププロファイラーで分析します。アイテム（オブジェクト）のコレクションをご覧いただけます。

スナップショットビューの切り替え

スナップショットでは、さまざまなタスクに応じてビューを切り替えることができます。図のように選択ボックスを切り替えることができます。

以下は 3 つのデフォルトのビューです:

Summary (要約) - コンストラクター 名の分類ごとにオブジェクトを表示します。
比較 (コントラスト) )
- 2 つのスナップショット間のオブジェクト間の差異を表示します。
Containment (コントロール)
- ヒープの内容を検出するために使用できます。

ビューは

Set で開くことができます。 tings パネル – ドミネーターツリーを表示し、メモリの成長ポイントを見つけるために使用できます。 さまざまな色でオブジェクトを区別する

オブジェクトの属性と属性値にはさまざまな種類があり、色によって自動的に区別されます。各プロパティは、次の 4 つのいずれかです:

- 名前
でインデックス付けされた通常のプロパティ。 . (ドット) 演算子 、または [] (角かっこ) によって参照されます。 "foo bar"];
0:element
a:system prop
という名前のオブジェクトには、対応する JavaScript タイプがありません。これらは JavaScript VM オブジェクトシステムに組み込まれています。 V8 では、ほとんどの組み込みオブジェクトとユーザー JS オブジェクトが同じヒープに配置されます。しかし、それらは単なる V8 の
です。
詳細を表示
概要ビュー (概要ビュー)

スナップショットを開きます。デフォルトで概要ビューに表示され、オブジェクトの総数が表示されます。また、展開して特定のコンテンツを表示することもできます。最初は、スナップショットが開きます。概要ビュー: オブジェクトの合計を

表示Systemし、展開してインスタンスを表示できます:

最初のレベルは「全体」行で、以下が表示されます:

Constructor (コンストラクター) このコンストラクターによって生成されたすべてのオブジェクトを表します

オブジェクト 内のオブジェクトのインスタンスの数Count 列は、対応するコンストラクターによって生成されたオブジェクトの浅いサイズ (直接占有されたメモリ) の合計数を示します。 Retained size 列は、対応するオブジェクトによって占有された最大メモリを示します。オブジェクトから GC ルートまでの最短距離
行全体を展開すると、すべてのオブジェクトインスタンスが表示されます。占有される直接メモリと、各インスタンスによって占有される合計メモリがそれに応じて表示されます。 @ 記号の後の数字はオブジェクトの一意の ID であり、これを使用して、オブジェクトごとに異なるスナップショットを比較できます。例: アウトラインビューの使用方法を学ぶには、この例 (新しいタブで開きます) を試してください。
比較ビューこのビューは、異なるスナップショットを比較してスナップショット間の違いを見つけたり、メモリリークのあるオブジェクトを見つけたりするために使用されます。アプリケーションの特定の操作にリークがないことを証明するには (たとえば、一般に、ドキュメントを開いて閉じるなど、操作と元に戻すアクションのペアではリークが発生しません)、次の手順を試すことができます。
操作の前にヒープスナップショットを作成します。

前の操作を元に戻します (前の操作の逆の操作を数回繰り返します)。 ;

2 番目のスナップショットを取得し、ビューを比較ビューに切り替えて、スナップショット 1 と比較します。

例: 比較ビューを使用してメモリリークを特定する方法を学習するには、例 (新しいタブで開きます) を試してください。
包含ビュー
コントロールビューは、アプリケーションのオブジェクト構造の「鳥瞰図」と呼ぶことができます。これにより、JavaScript オブジェクトと同様に、VM オブジェクト内の関数の内部を確認できるため、アプリケーションのメモリ使用量を非常に低レベルで把握できます。
このビューには、いくつかのエントリポイントが用意されています:

- これらのオブジェクトは JavaScript コードの「グローバル」オブジェクトです。

GC Root

- VM のガベージコレクターの実際の GC ルートです。

ネイティブオブジェクト

- ブラウザオブジェクトは JavaScript 仮想マシンに「プッシュ」され、DOM ノード、CSS ルールなどの自動操作を実行します (詳細は次のセクションで説明します)。以下は典型的なコントロールビューです:

例: コントロールビューを使用して クロージャー と
イベント処理
クロージャに関するヒント

function createLargeClosure() {
  var largeStr = new Array(1000000).join(&#39;x&#39;);

  var lC = function() { // this is NOT a named function
    return largeStr;
  };

  return lC;
}

ログイン後にコピー

そして次の例では関数に名前を付けています:

function createLargeClosure() {
  var largeStr = new Array(1000000).join(&#39;x&#39;);

  var lC = function lC() { // this IS a named function
    return largeStr;
  };

  return lC;
}

ログイン後にコピー

例: メモリ内のクロージャの影響を分析するために eval が悪である理由をこの例で試してください。ヒープ割り当てをログに記録する次の例を試してみることにも興味があるかもしれません。

DOM メモリリークを公開する

このツールのユニークな点は、ブラウザーのネイティブオブジェクト (DOM ノード、CSS ルール) と JavaScript オブジェクト間の双方向参照を表示することです。これは、空き DOM 子ノードの逆参照を忘れることによって引き起こされる微妙なメモリリークを見つけるのに役立ちます。

DOM メモリリークは想像を超えて発生する可能性があります。次の例を見てください – #tree オブジェクトはいつ GC されますか?

var select = document.querySelector;
  var treeRef = select("#tree");
  var leafRef = select("#leaf");
  var body = select("body");

  body.removeChild(treeRef);

  //#tree can&#39;t be GC yet due to treeRef
  treeRef = null;

  //#tree can&#39;t be GC yet due to indirect
  //reference from leafRef

  leafRef = null;
  //#NOW can be #tree GC

ログイン後にコピー

#leaf は、親ノード (parentNode) への参照を表します。再帰は #tree を参照するため、#tree で表されるツリー構造全体は、leafRef が無効化された場合にのみ GC によってリサイクルされます。

例: DOM ノードがメモリをリークする場所とその場所を特定する方法を理解するために、DOM ノードをリークしてみてください。次の例も見ることができます: DOM リークが予想よりも大きい。

DOM メモリリークとメモリ分析の基本について詳しくは、Gonzalo Ruiz de Villa の記事「Chrome DevTools を使用したメモリリークの検索とデバッグ」を参照してください。

ネイティブオブジェクトは、概要ビューと包含ビューで見つけやすくなっています - 独自のカテゴリがあります:

例: DOM ツリーを分離する方法を学ぶには、この例 (新しいタブで開く) を試してください。

ドミネータービュー

ドミネータービューには、スタックグラフのドミネーターツリーが表示されます。 Dominator ビューは Containment ビューに似ていますが、プロパティ名がありません。これは、ルーラーが直接参照を持たないオブジェクトである可能性があるためです。これは、ルーラーツリーがヒープグラフのスパニングツリーではないことを意味します。ただし、これはメモリ増加ポイントをすばやく特定するのに役立つ便利なビューです。

注: Chrome Canary では、DevTools の [設定] > [高度なヒープスナップショットプロパティを表示] でドミネータービューをオンにできます。これは、DevTools を再起動した後に有効になります。

例: この例 (新しいタブで開きます) を試して、メモリ増加ポイントを見つける方法を練習してください。パスとドミネーターを保持する次の例をさらに試してみることができます。

オブジェクト割り当てトラッカー

オブジェクトトラッカーは、ヒーププロファイラーのスナップショット増分更新分析とタイムラインパネルの記録を統合します。他のツールと同様に、オブジェクトのヒープ構成を記録するには、記録を開始し、一連の操作を実行し、記録を停止して分析する必要があります。

オブジェクトトラッカーはヒープスナップショットを継続的に記録し (頻度は 50 ミリ秒ごとに達します!)、最後に最後のスナップショットを記録します。このヒープ割り当てアナライザーは、オブジェクトが作成された場所とその予約されたパスを示します。

オブジェクトアナライザーを開いて使用します

オブジェクトアナライザーの使用を開始するには: 1. 最新バージョンの Chrome Canary を使用していることを確認します。

DeveTools を開き、歯車アイコンをクリックします (翻訳者: このステップの使用法がわかりません)。
ここで、プロファイラーパネルを開くと、「ヒープ割り当ての記録」オプションが表示されます。

上のバーは、ヒープ内に生成された新しいオブジェクトを表します。高さは対応するオブジェクトのサイズに対応し、その色はそのオブジェクトが最後に撮影されたスナップショットにまだ存在しているかどうかを示します。青い列はオブジェクトがタイムラインの最後にまだ存在していることを示し、灰色の列はそのオブジェクトがまだ存在していることを示します。オブジェクトはタイムラインで生成されましたが、終了する前にメモリが再利用されました。

上記の例では、アクションが 10 回実行されます。同じプログラムは 5 つのオブジェクトを保持するため、最後の 5 つの青いバーが保持されます。しかし、最後に残った列には潜在的な問題があります。タイムライン上のスライダーを使用して、特定のスナップショットを拡大し、割り当てられたオブジェクトを見つけることができます。

ヒープ内のオブジェクトをクリックすると、ヒープスナップショットの下部に予約済みメモリツリーの合計が表示されます。このオブジェクトの予約済みメモリツリーの合計を調べると、このオブジェクトがリサイクルされなかった理由を理解するのに十分な情報が得られるため、コードに適切な変更を加えて不要な参照を削除できます。

メモリ分析 FAQ

Q: オブジェクトのすべてのプロパティが表示されません。文字列以外の値も表示されます。なぜ？

すべてのプロパティが JavaScript ヒープに完全に保存されるわけではありません。それらの一部は、ネイティブコードのゲッターメソッドを実行することによって取得されます。これらのプロパティは、ゲッターが「純粋な」関数でない場合にゲッターの呼び出しを防止し、プログラムの状態への変更を回避するために、ヒープスナップショットにはキャプチャされません。同様に、数値などの非文字列値は、スナップショットのサイズを削減するためにキャプチャされません。

@ 記号の後の数字は何を意味しますか?アドレスですか、それとも ID ですか?この ID 値は本当に一意ですか? これはオブジェクトIDです。オブジェクトはガベージコレクション中に削除されるため、オブジェクトのアドレスを表示しても意味がありません。これらのオブジェクト ID は実際の ID です。つまり、異なるスナップショット間で一意に表されます。これにより、ヒープ状態間の正確な比較が可能になります。これらの ID を維持すると、GC プロセスに追加のオーバーヘッドが追加されますが、これは最初のヒープスナップショットが記録されるときにのみ割り当てられます。ヒープアナライザーが使用されない場合、追加のオーバーヘッドはありません。

Q: 「死んだ」(参照されていない) オブジェクトはスナップショットに含まれますか?

いいえ、参照できるオブジェクトのみがスナップショットに表示されます。さらに、スナップショットを作成する前に、GC 操作が自動的に実行されます。

注: この記事の執筆時点では、ヒープサイズの削減を防ぐために、スナップショットを取得するときに GC を実行しない予定です。これは現在では当てはまりますが、ガベージオブジェクトは依然としてスナップショットの外側に表示されます。

Q: GC ルートは何で構成されていますか?

は、

タイムラインパネルは、ページを初めて使用して速度が低下した場合に、過剰なメモリ使用量を診断するために使用されます。 Web サイトが遅いのはメモリリークの典型的な兆候ですが、他の理由による場合もあります。レンダリングやネットワークのボトルネックがある可能性があるため、ページの実際の問題に必ず対処してください。

メモリの問題かどうかを判断するには、タイムラインパネルとメモリタブを開きます。記録ボタンをクリックし、メモリリークを引き起こす可能性があると思われるアプリケーションの操作を数回繰り返します。録音を停止します。アプリケーションのメモリ使用量グラフが生成されます。メモリ使用量が (対応する減少なしに) 増加し続ける場合、これはアプリケーションにメモリリークが発生している可能性があることを示しています。一般に、通常のアプリケーションのメモリ使用量グラフはギザギザになります。これは、メモリが使用後にガベージコレクターによって再利用されるためです。このエイリアスについては心配する必要はありません。JavaScript によるメモリ消費が常にあり、空の requestAnimationFrame であってもこのエイリアスが発生しますが、これは避けられません。大量のメモリを継続的に割り当てる形状でない限り、メモリのゴミが大量に発生することになります。

写真の中の成長上記のラインには注意が必要です。 Memory タグの DOM ノードカウンター、ドキュメントカウンター、およびイベントリスナーの数も、診断分析中に非常に役立ちます。 DOM ノードの数は使用されるネイティブメモリであり、JavaScript メモリマップには影響しません。

requestAnimationFrame也会造成这种锯齿形，这是无法避免的。只要不是那种分配了持续很多内存的形状，那就表明生成了很多内存垃圾。

上图的增长线是需要你警惕的。在诊断分析的时候Memory标签中的DOM node counter，Document counter和Event listener count也是很有用的。DOM节点数是使用的原生内存不会影响JavaScript内存图。

一旦你确认你的应用有内存泄漏，堆分析仪就可以用来找到内存泄漏的地方。

问：我发现堆快照中有的DOM节点的数字是用红色标记为”Detached DOM tree”，而其它的是黄色的，这是什么意思呢？

你会发现有不同的颜色。红色的节点(有着深色的背景)没有从JavaScript到它们的直接的引用，但它们是分离出来的DOM结构的一部分，所以他们还是在内存中保留了。有可能有一个节点被JavaScript引用到了(可能是在闭包中或者一个变量)，这个引用会阻止整个DOM树被内存回收。

黄色节点(黄色背景)有JavaScript的直接引用。在同一个分离的DOM树中查看一个黄色的节点来定位你的JavaScript的引用。就可能看到从DOM window到那个节点的属性引用链(如：window.foo.bar[2].baz

確認したらアプリケーションにメモリリークがある場合は、ヒープアナライザを使用してメモリリークを見つけることができます。

質問: ヒープスナップショット内の一部の DOM ノードの番号が「分離された DOM ツリー」として赤色でマークされ、他のものは黄色でマークされていることがわかりました。これは何を意味しますか?

さまざまな色があることがわかります。赤いノード (背景が暗い) は JavaScript から直接参照されていませんが、別の DOM 構造の一部であるため、メモリ内に残ります。ノードが JavaScript によって (おそらくクロージャまたは変数内で) 参照されている可能性があり、この参照により DOM ツリー全体が再利用されなくなります。

黄色ノード (黄色)背景) には JavaScript への直接参照があります。同じ分離された DOM ツリー内で黄色のノードを探して、JavaScript 参照を見つけます。 DOM ウィンドウからそのノードへの属性参照チェーン (window.foo.bar[2].baz など) を確認できます。次の動的図は、切り離されたノードのプロセスを示しています:

例🎜: この例の切り離されたノードを試してください。タイムラインでノードのライフサイクルを表示し、ヒープスナップショットを取得して切り離されたノードを見つけることができます。ノード。 🎜🎜🎜Q: 直接占有メモリ (浅いサイズ) と占有合計メモリ (保持サイズ) はそれぞれ何を意味しますか?また、それらの違いは何ですか? 🎜🎜🎜これがケースです。オブジェクトは 2 つの方法 (生きている状態) でメモリ内に存在できます - 別のアクセス可能な (生きている) オブジェクトによって直接保持される (ウィンドウオブジェクトやドキュメントオブジェクトは常にアクセス可能)、またはネイティブオブジェクト (DOM オブジェクトのような) 暗黙的な包含によって保持されます。参考文献。後者の方法では、オブジェクトが GC によって自動的にリサイクルされなくなるため、メモリリークが発生する可能性があります。オブジェクト自体が占有するメモリはダイレクトメモリと呼ばれます (一般的に、配列と文字列はより多くのダイレクトメモリ (浅いサイズ) を予約します)。 🎜🎜🎜🎜

他のオブジェクトが再利用されるのを防ぐことで、任意のサイズのオブジェクトで大量のメモリ使用量を維持できます。オブジェクトが削除されると (オブジェクトが作成する依存関係の一部は参照できなくなります)、解放できるメモリの量は、占有メモリの合計 (保持サイズ) と呼ばれます。

Q: コンストラクターと保持フィールドの下に大量のデータがあります。メモリリークが発生しているかどうかを調査するにはどこから始めればよいですか?

一般的に、リテイナーでソートされた最初のオブジェクトから開始するのが最善です。リテイナーは距離 (ウィンドウオブジェクトまでの距離を参照) でソートされます。

距離が最も短いオブジェクトが、メモリリークを引き起こす可能性がある優先オブジェクトである可能性があります。

Q: ビューの概要、比較、ドミネーター、および包含の違いは何ですか?

ビューを切り替えることで違いを体験できます。

[概要] ビューは、コンストラクターごとにグループ化されたオブジェクト (およびそのメモリ使用量) を見つけるのに役立ちます。このビューは、DOM メモリリークを見つけるのに役立ちます。
比較ビューでは、どのオブジェクトメモリが正しく再利用されたかを示すことで、メモリリークを検索できます。通常、操作の前後で 2 つ (またはそれ以上) のメモリ使用量のスナップショットが記録されます。解放されたメモリと参照数の差を見てメモリリークが発生しているかどうかを確認し、原因を見つけます。
Containment (Control) ビューでは、オブジェクト構造がより適切に表示され、グローバルスコープ (ウィンドウなど) 内のオブジェクト参照を分析して、これらのオブジェクトが保持されているものを見つけるのに役立ちます。これにより、クロージャを分析し、オブジェクトをより深く掘り下げることができます。
ドミネータービューは、特定の場所 (参照されているオブジェクトなど) に冗長なオブジェクトがまだぶら下がっていないことを確認し、オブジェクトの削除/ガベージコレクションが実際に機能することを確認するのに役立ちます。

Q: ヒープアナライザーのコンストラクター (グループ) の内容は何を表しますか?