JavaScriptのメモリリークとクロージャ - その理由とその理由

Question

JavaScriptを使用してクロージャを使用すると、メモリリークが発生することがよくあります。ほとんどの場合、これらの記事は、スクリプトコードとDOMイベントを混在させることを指しています。スクリプトはDOMを指し、逆もまた同様です。

私はクロージャがそこで問題になる可能性があることを理解します。

しかし、Node.jsはどうですか？ここでは、当然DOMを持っていないので、ブラウザのようにメモリに副作用が漏れることはありません。

閉鎖には他にどのような問題がありますか？誰かがこれについての詳細なチュートリアルを手がけてくれますか？

この質問は、ブラウザではなくNode.jsを明示的に対象としています。

Answer 1

This questionについて尋ねます。基本的には、コールバックでクロージャを使用する場合は、コールバックを終了したときにコールバックを解除して、GCが再度呼び出すことができないことを知る必要があります。これは私には意味があります。クロージャーが呼び出されるのを待っているだけの場合、GCは終了したことを知るのに苦労します。コールバックメカニズムからクロージャを手動で削除することにより、クロージャは参照されずに収集されます。

また、Mozillaはa great article on finding memory leaks in Node.jsコードを公開しています。私は、あなたの戦略のいくつかを試してみると、漏れのある行動を表すコードの部分を見つけることができると思います。ベストプラクティスは素晴らしく、すべてですが、私はプログラムのニーズを理解し、経験的に観察できるものに基づいていくつかのパーソナライズされたベストプラクティスを考え出す方がより効果的だと思います。 GCC mtraceユーティリティを使用しています

• Jimb Esser氏のnode-mtraceは、ヒープ使用量をプロファイルする：

  はここで、Mozillaの記事からの迅速な抜粋です。

• Dave Pachecoのnode-heap-dumpは、V8ヒープのスナップショットを取り、巨大なJSONファイルですべてを直列化します。結果スナップショットをトラバースしてJavaScriptで調査するツールが含まれています。
• Danny Coatesのv8-profilerおよびnode-inspectorは、WebKit Webインスペクタを使用して、V8プロファイラおよびノー​​ドデバッグインターフェイスのノードバインディングを提供します。
• リテーナーが
• フェリックスGeisendörferのノードのメモリリークのチュートリアルがv8-profilerとnode-debuggerを使用する方法の短いと甘いの説明で、現在最先端のザ・あるをグラフ非無効のと同じのフェリックスGnassのフォークほとんどのNode.jsメモリリークのデバッグのための技術です。 Node.jsのメモリをデバッグするためにあなたの処分でツールの兵器庫を供給する
• ジョエントのSmartOSプラットフォームは、

---

をリークthis questionへの回答は基本的にあなたがnullを割り当てることにより、GCを助けることができると言います変数を閉じる。

var closureVar = {}; 
doWork(function callback() { 
    var data = closureVar.usefulData; 
    // Do a bunch of work 
    closureVar = null; 
}); 

すべての変数は、関数が消えます内を宣言した関数が戻るとき、他の閉鎖に使用されているものを除き、。この例では、callback()が呼び出されるまでclosureVarをメモリに格納する必要がありますが、そのときはいつ知っていますか？コールバックが呼び出されると、クロージャ変数をnullに設定してGCにヒントを与えることができます。

免責事項：以下のコメントからわかるように、この情報はNode.jsには致命的ではないと言っているSOユーザーがいます。私はまだそれに決定的な答えはありません。私はちょうど私がウェブ上で見つけたものを投稿しています。

Answer 2

私は閉鎖がメモリリークの原因であることに同意しなければなりません。これは、古いバージョンのIEではあまりにも厄介なガベージコレクションのために当てはまります。 Douglas Crockfordのthisの記事を読んでください。これはメモリリークが何であるかを明確に述べています。

再生されていないメモリがリークしていると言われています。

リークは問題ではなく、効率的なガベージコレクションです。リークは、ブラウザとサーバーの両方のJavaScriptアプリケーションで発生する可能性があります。 V8を例に取る。ブラウザでは、別のウィンドウ/タブに切り替えると、タブでガベージコレクションが行われます。アイドリング時にリークが塞がれます。タブはアイドル状態になることがあります。

サーバー上での操作は簡単ではありません。漏れが発生する可能性がありますが、GCはコスト効率に優れていません。サーバはGCを頻繁に使用する余裕がないか、その性能に影響を与えます。ノードプロセスが特定のメモリ使用量に達すると、ノードプロセスはGCで起動します。リークは定期的に取り除かれます。しかし、リークは依然として速いスピードで起こり、プログラムがクラッシュする可能性があります。

Answer 3

this blog postには、David Glasserの良い例と説明があります。

さて、ここでは（私はいくつかのコメントを追加しました）です：

var theThing = null; 
var cnt = 0; // helps us to differentiate the leaked objects in the debugger 
var replaceThing = function() { 
    var originalThing = theThing; 
    var unused = function() { 
     if (originalThing) // originalThing is used in the closure and hence ends up in the lexical environment shared by all closures in that scope 
      console.log("hi"); 
     }; 
     // originalThing = null; // <- nulling originalThing here tells V8 gc to collect it 
     theThing = { 
      longStr: (++cnt) + '_' + (new Array(1000000).join('*')), 
      someMethod: function() { // if not nulled, original thing is now attached to someMethod -> <function scope> -> Closure 
       console.log(someMessage); 
      } 
     }; 
    }; 
setInterval(replaceThing, 1000); 

でそれを試してみるとChromeのDevツールでoriginalThingをゼロにすることなく、（タイムライン]タブ、メモリビュー、レコードをクリック）してください。上記の例は、ブラウザおよびNode.js環境に適用されることに注意してください。

クレジットとも特にVyacheslav Egorovです。