1。ゴミリサイクルメカニズム-GC
JavaScriptには、自動ガベージコレクションメカニズム（GC：ガベージコレクション）があります。つまり、実行環境は、コード実行中に使用されるメモリの管理を担当します。
原則：ガベージコレクターは定期的に（周期的）使用されていない変数を見つけて、メモリを解放します。
JavaScript Garbage Collectionのメカニズムは非常に単純です。使用されなくなった変数を見つけてから、それが占めるメモリを解放します。ただし、オーバーヘッドが比較的大きいため、このプロセスはリアルタイムではないため、ガベージコレクターは固定時間間隔で定期的に実行されます。
使用されなくなった変数は、ライフサイクルを終了する変数です。もちろん、それらはローカル変数のみになることができます。グローバル変数のライフサイクルは、ブラウザがページをアンインストールするまで終了しません。ローカル変数は関数の実行中にのみ存在し、このプロセスでは、対応するスペースがスタックまたはヒープのローカル変数に割り当てられて値を保存し、これらの変数は関数の終了まで関数で使用されます。ただし、閉鎖内の内部機能により、外部関数を終了と見なすことはできません。
コードを説明しましょう：
関数fn1（）{var obj = {name： 'hanzichi'、age：10};} function fn2（）{var obj = {name： 'hanzichi'、age：10}; return obj;} var a = fn1（）; var b = fn2（）;コードの実行方法を見てみましょう。まず、FN1とFN2と呼ばれる2つの関数が定義されています。 FN1が呼び出されると、FN1環境を入力すると、メモリストレージオブジェクトが開きます{name： 'Hanzichi'、age：10}。通話が終了し、FN1環境が発生すると、JSエンジンのガベージコレクターによってメモリブロックが自動的にリリースされます。 FN2が呼び出されるプロセス中に、返されたオブジェクトはグローバル変数Bによって指されているため、メモリのブロックはリリースされません。
ここで疑問が生じます：どの変数が役に立たないのですか？したがって、ガベージコレクターは、どの変数が役に立たないかを追跡する必要があり、将来のメモリを取り戻すためにもはや役に立たない変数をマークする必要があります。タグ付けに使用される役に立たない変数の戦略は、実装によって異なる場合があり、通常、これを行うには2つの方法があります：マーククリアランスと参照カウント。見積カウントはあまり一般的ではありません。マーククリアリングはより一般的に使用されます。
2。クリアマーク
JSで最も一般的に使用されるゴミ収集方法は、マーク除去です。たとえば、変数が環境に入ると、関数の変数を宣言すると、変数を「環境に入る」とマークします。論理的に言えば、実行フローが対応する環境に入る限り使用できるため、環境に入る変数で占めるメモリはリリースできません。そして、変数が環境を離れると、それは「環境外」としてマークされます。
function test（）{var a = 10; //マークされている、環境を入力するvar b = 20; //マークが付けられている、環境を入力} test（）; //実行後、AとBがマークされ、環境を離れてリサイクルされます。ガベージコレクターが実行されると、メモリに保存されているすべての変数をマークします（もちろん、マーキング方法を使用できます）。次に、環境内の変数のタグ（閉鎖）と環境の変数によって参照される変数を削除します。環境内の変数がこれらの変数にアクセスできなくなるため、この後にマークされた変数は削除できる変数と見なされます。最後に、ゴミコレクターはメモリクリア作業を完了し、それらの顕著な値を破壊し、占有するメモリスペースを取り戻します。
これまでのところ、IE、Firefox、Opera、Chrome、およびSafariのJS実装では、マーククリアリングガベージコレクション戦略または同様の戦略が使用されていますが、ゴミ収集の時間間隔は互いに異なります。
3。見積カウント
参照カウントの意味は、各値が参照される回数を追跡することです。変数が宣言され、参照タイプの値が変数に割り当てられる場合、この値への参照数は1です。同じ値が別の変数に割り当てられている場合、値への参照数は1増加します。反対に、この値への参照を含む変数が別の値を取ります。占領することができます。このようにして、Garbage Collectorが次回再び実行されると、0の参照で値を解放します。
function test（）{var a = {}; // Aの参照の数は0 var b = aです。 // Aの参照の数は1 var c = aです。 // Aの参照の数は1、Aの参照の数は1、Aの参照の数は1、Aの参照数は2 var b = {}です。 // aの参照の数は1で、aの参照数は1}}Netscape Navigator3は、リファレンスカウント戦略を使用した最初のブラウザでしたが、すぐに深刻な問題が発生しました：Circular References。循環参照は、オブジェクトBへのポインターを含むオブジェクトAを指し、オブジェクトBにはオブジェクトAへの参照も含まれています。
function fn（）{var a = {}; var b = {}; A.pro = b; b.pro = a;} fn（）;上記のAとBの参照時間は2です。Fn（）が実行された後、両方のオブジェクトが環境を離れました。マーククリアモードに問題はありません。ただし、参照カウント戦略では、AとBの参照時間は0ではないため、メモリはガベージコレクターによって収集されません。 FN関数が大量に呼び出されると、メモリの漏れが発生します。 IE7およびIE8では、メモリは急激に上昇します。
IEの一部のオブジェクトはネイティブJSオブジェクトではないことを知っています。たとえば、DOMとBOMのオブジェクトは、C ++を使用してCOMオブジェクトの形で実装され、COMオブジェクトのガベージコレクションメカニズムは参照カウント戦略を採用しています。したがって、IE JSエンジンがタグクリアング戦略を採用している場合でも、JSがアクセスするCOMオブジェクトは、参照カウント戦略に基づいています。言い換えれば、COMオブジェクトがIEに関与している限り、循環参照の問題があります。
var element = document.getElementById（ "some_element"）; var myobject = new object（）; myobject.e = element; element.o = myobject;
この例では、DOM要素とネイティブJSオブジェクトの間に循環参照を作成します。その中で、可変Myobjectには、要素オブジェクトを指す要素という名前の属性があります。また、変数要素には、back back backという名前の属性があります。この円形の参照により、例のDOMがページから削除されたとしても、リサイクルされることはありません。
上記の例を見ると、一部の学生はそれが弱すぎると思っていました。誰がそのような退屈なことをするでしょうか？実際、私たちはそれをやっていますか？
window.onload = function outourfunction（）{var obj = document.getElementById（ "要素"）; obj.onclick = function innerfunction（）{};};このコードは問題ないようですが、OBJはdocument.getElementByID（ "要素"）を指し、document.getElementbyIdのonclickメソッド（ "要素"）は、自然にOBJを含む外部環境のドイツ語変数を指します。とても隠されていませんか？
解決
最も簡単な方法は、ループを手動で再参照することです。たとえば、この関数は今これを行うことができます。
myobject.element = null; element.o = null;
window.onload = function outourfunction（）{var obj = document.getElementById（ "要素"）; obj.onclick = function innerfunction（）{}; obj = null;};変数をnullに設定するということは、変数と以前に参照した値との間の接続を遮断することを意味します。ゴミコレクターが次回実行されると、これらの値が削除され、それらが占有するメモリがリサイクルされます。
IE9+には、DOMメモリリークを引き起こすための円形の参照がないことに注意する必要があります。 Microsoftが最適化したか、DOMのリサイクル方法が変更された可能性があります。
4。メモリ管理
1.ゴミコレクションはいつトリガーされますか？
ゴミコレクターは定期的に実行されます。割り当てられたメモリが非常に大きい場合、リサイクル作業は非常に困難になります。ごみ収集時間間隔を決定することは、考える価値のある質問になります。 IE6のゴミコレクションは、メモリの割り当てに従って実行されます。環境に256の変数、4096オブジェクト、64K文字列がある場合、ガベージコレクターがトリガーされます。それは非常に科学的に見え、しばらく呼び出す必要はありません。時々それは不要です。このようにオンデマンドに電話するのは良いことではありませんか？しかし、環境に非常に多くの変数があり、スクリプトが非常に複雑で正常である場合、その結果、ガベージコレクターは常に動作しているため、ブラウザが再生できません。
MicrosoftはIE7で調整を行っています。トリガー条件は固定されなくなりましたが、動的に変更されます。初期値はIE6と同じです。ゴミコレクターによって収集されたメモリ割り当てがプログラムで占められているメモリの15％未満である場合、ほとんどのメモリをリサイクルできないことを意味します。セットガベージコレクションのトリガー条件は敏感すぎます。現時点では、路上条件を2倍にします。収集されたメモリが85％を超えている場合、それはずっと前にほとんどのメモリをクリーニングする必要があることを意味します。この時点で、トリガー条件が後退します。これにより、ゴミリサイクルはより多くの機能を機能させます
2。合理的なGCソリューション
1）JavaScriptエンジンの基本的なGCソリューションは（単純なGC）：マークとスイープ、つまり、：
2）GC欠陥
他の言語と同様に、JavaScriptのGCポリシーは1つの問題を回避できません。GCが他の操作に応答するのを停止する場合、これはセキュリティ上の理由です。 JavaScriptのGCは100ms以下であり、これは一般的なアプリケーションに適していますが、JSゲームでは、高い一貫性を必要とするアプリケーションは面倒です。これは、新しいエンジンが最適化するために必要なものです。GCによって引き起こされる長期停止応答を避けてください。
3）GC最適化戦略
デイビッドおじさんは主に2つの最適化ソリューションを導入しましたが、これらは最も重要な2つの最適化ソリューションでもあります。
（1）世代GC）
これは、Javaリサイクル戦略のアイデアと一致しています。目的は、「一時的な」オブジェクトと「永続的な」オブジェクトを区別することです。より多くの「一時的なオブジェクト」領域とより少ない「終身オブジェクト」領域をリサイクルし、毎回通過する必要があるオブジェクトを減らして、GCSに費やされる時間を毎回短縮します。写真に示されているように：
ここに追加する必要があるのは、終身在庫オブジェクトに追加のオーバーヘッドがあるということです。若い世代から終身系の世代に移行し、参照されている場合、参照ポインティングも変更する必要があります。
（2）増分GC
この計画のアイデアは非常に簡単です。これは、「毎回少し扱い、次回は少し対処するなど」です。写真に示されているように：
このソリューションには時間がかかりますが、多くの中断があり、頻繁なコンテキストの切り替えの問題が発生します。
各ソリューションには適用可能なシナリオと欠点があるため、実際のアプリケーションでは、実際の状況に従ってソリューションが選択されます。
たとえば、（オブジェクト/s）比が低い場合、GCの実行頻度が中断され、単純なGCが低くなります。多数のオブジェクトが長い間「生き残った」場合、世代処理の利点は大きくありません。
上記の記事は、JavascirpのGarbage Collection Recyclingメカニズムが私があなたと共有するすべてのコンテンツであることを包括的に理解しています。私はそれがあなたに参照を与えることができることを願っています、そしてあなたがwulin.comをもっとサポートできることを願っています。