node.js には非常に大きなオブジェクトのコレクション (数百万) があり、キャッシュのためにメモリに保持する必要があります (それらはいくつかのグローバル ハッシュ オブジェクトで保持されます)。各ハッシュ コレクションには、約 75 万個のキーが格納されます。
GCを最小限に抑えるために、これらのアイテムを保管する最良の方法を見つけたい. これらのアイテムを数十万のハッシュに分割したほうがよいでしょうか? ハッシュをまったく使用しないでください。それらを完全にヒープから外して、GC によって検査されないようにする方法はありますか (もしそうなら、どうすればよいでしょうか)。
JavaScript からのガベージ コレクションを制御するパブリック API はありません。
しかし、GC は長年にわたって長い道のりを歩んできました。最新の GC 実装では、一部のオブジェクトが長生きし、めったに収集されない特別な「領域」にそれらを配置することに気付くでしょう。
これが正確にどのように機能するかは、完全に実装に依存します。すべてのブラウザには独自の機能があり、通常、新しいブラウザ バージョンがリリースされると、これも変更されることがよくあります。
編集メモリ上のレイアウトと編成はまったく関係ありません。最新の GC を詳細に理解するには、実際のコードを読むのに数週間費やす必要があります。ここで説明するのは、非常に単純化した図です。実際のコードは異なる動作をします (また、一部の GC はまったく異なるトリックを使用して同じ目標を達成します)。
GC には、過去にどのくらいの頻度でオブジェクトを参照したかをカウントする各オブジェクトのカウンターがあると想像してください。さらに、カウンターが特定のしきい値を超えたオブジェクトを含む、さまざまな年齢のオブジェクトを保持するいくつかのリストがあります。したがって、カウンターが制限に達すると、オブジェクトは次のリストに移動します。
最初のリストは、GC が実行されるたびにアクセスされます。2 番目のリストは、N 回目の GC 実行ごとにのみ考慮されます。
別の実装では、「GC リスト」の先頭に新しいオブジェクトを追加し、GC の実行ごとに N 個の要素のみをチェックします。そのため、長く生きているオブジェクトはリストの下に移動し、しばらくすると、毎回チェックされるわけではありません。
これが意味することは、何もする必要がないということです。GC は、巨大なマップが長期間有効であることを認識し (マップ内のすべてのオブジェクトについても同様です)、しばらくすると、このデータ構造を無視し始めます。