グローバル変数に null を代入して、積極的に逆参照してメモリを解放する場合、これは参照カウント戦略ですか? JSのガベージコレクション機構はマークとクリアしか使っていないということではないでしょうか?マーククリア戦略には逆参照が含まれていませんか?
変数宣言はヒープ上にメモリを割り当てます。対応する参照を null としてマークすると、この変数に対応するメモリ空間を再利用できることがインタープリタに伝えられます。
ただし、これは JS の構文設計であり、インタープリターの実装におけるメモリ管理の詳細は含まれません。実際、ブラウザの GC 戦略も異なります。 Chrome/Firefox/Safari はマーク アンド スイープを使用しますが、IE の古いバージョンでは参照カウントを使用します。
また、逆参照は null を割り当てる形式だけではありません。インタプリタはスコープを通じて変数のライフサイクルを決定し、変数が変数スコープから出るときに変数のメモリ空間を再利用できます。
[Mark Clearance] と [Reference Counting] は 2 つの異なる GC アルゴリズムですが、[Dereference] は JS の文法機能です。この 2 つは直交する (無関係である) 場合があります。
jsの仕様ではマークとクリアを使用することになっていますが、実装すると必ずしもマークとクリアになるとは限りません。
ここであなたが混乱しているのは、リサイクルの見かけだけを見て、掃除の本質を見落としているからです。
参照カウントは、その名前が示すように、オブジェクトへの参照をカウントし、参照が 0 になるとリサイクルされます。
マーキングとクリアは 2 つのフェーズに分かれています。マーキング フェーズはルートから開始され、アクセス可能なオブジェクトが到達可能なオブジェクトと比較され、その後、クリア フェーズでマークされていないオブジェクトがリサイクルされます。
実際、ソースコードの実装を見ない限り、表面からどのような戦略が使用されているかを知ることは困難です。
変数宣言はヒープ上にメモリを割り当てます。対応する参照を null としてマークすると、この変数に対応するメモリ空間を再利用できることがインタープリタに伝えられます。
ただし、これは JS の構文設計であり、インタープリターの実装におけるメモリ管理の詳細は含まれません。実際、ブラウザの GC 戦略も異なります。 Chrome/Firefox/Safari はマーク アンド スイープを使用しますが、IE の古いバージョンでは参照カウントを使用します。
また、逆参照は null を割り当てる形式だけではありません。インタプリタはスコープを通じて変数のライフサイクルを決定し、変数が変数スコープから出るときに変数のメモリ空間を再利用できます。
[Mark Clearance] と [Reference Counting] は 2 つの異なる GC アルゴリズムですが、[Dereference] は JS の文法機能です。この 2 つは直交する (無関係である) 場合があります。
jsの仕様ではマークとクリアを使用することになっていますが、実装すると必ずしもマークとクリアになるとは限りません。
ここであなたが混乱しているのは、リサイクルの見かけだけを見て、掃除の本質を見落としているからです。
参照カウントは、その名前が示すように、オブジェクトへの参照をカウントし、参照が 0 になるとリサイクルされます。
マーキングとクリアは 2 つのフェーズに分かれています。マーキング フェーズはルートから開始され、アクセス可能なオブジェクトが到達可能なオブジェクトと比較され、その後、クリア フェーズでマークされていないオブジェクトがリサイクルされます。
実際、ソースコードの実装を見ない限り、表面からどのような戦略が使用されているかを知ることは困難です。