Javascript 在谷歌浏览器中强制垃圾收集
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/13950394/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Forcing garbage collection in Google Chrome
提问by Paulius K.
We are developing a single-page web app with ZKwhich constantly communicates with server and updates parts of its screens. Updating can be as frequent as 1s. During these updates, references to large ammounts of JSobjects are lost and those objects have to be cleaned by garbage collector eventually.
我们正在使用ZK开发一个单页 Web 应用程序，它不断与服务器通信并更新其屏幕的一部分。更新频率可以达到 1 秒。在这些更新过程中，对大量JS对象的引用丢失，这些对象最终必须由垃圾收集器清理。
As far as we've figured out, Chrome only runs its garbage collector on inactive tabs. This is a problem for us, because the app's tab is usually active and almost never refreshed, thus JSobjects never get collected. If left active for enough time, the tab eventually crashes (Aww Snapmessage).
据我们所知，Chrome 仅在非活动选项卡上运行其垃圾收集器。这对我们来说是个问题，因为应用程序的选项卡通常处于活动状态并且几乎从不刷新，因此永远不会收集JS对象。如果保持活动状态足够长，选项卡最终会崩溃（Aww Snap消息）。
We need to initiate garbage collection manually. So far we've tried running Chrome with --js-flags="--expose-gc"and running gc(), but it throws an exception:
我们需要手动启动垃圾收集。到目前为止，我们已经尝试使用--js-flags="--expose-gc"和 running运行 Chrome gc()，但它抛出了一个异常：
ReferenceError: gc is not defined
This doesn't happen on Firefox -- memory usage is more or less a constant.
这在 Firefox 上不会发生——内存使用或多或少是一个常数。
Force refreshing the page is not an option.
强制刷新页面不是一个选项。
We would be grateful for any and all suggestions.
我们将不胜感激任何和所有建议。
EDIT: we've tried running window.gc()and gc()both on Chrome versions 23.0.1271.97 mand 25.0.1364.2 dev-m
编辑：我们已经尝试运行window.gc()和gc()双方在Chrome版本23.0.1271.97 m和25.0.1364.2 dev-m
采纳答案by Konrad Dzwinel
You can fetch code of Chrome Dev Tools, modify it so that ProfilerAgent.collectGarbage();is called every now and then (it's a code that is called when you click 'Collect Garbage' button on the Timeline panel) and run Chrome with your version of DevTools using --debug-devtools-frontendflag.
您可以获取 Chrome Dev Tools 的代码，对其进行修改，以便ProfilerAgent.collectGarbage();不时调用它（这是当您单击“时间轴”面板上的“收集垃圾”按钮时调用的代码），并使用--debug-devtools-frontend标志运行带有您的 DevTools 版本的 Chrome 。
However, this solution is quite extreme, try it only when you get really desperate. Till then, I propose profiling your application and checking out why v8 decides not to clean the garbage (or can't clean the garbage). Timeline panel of DevTools will help you out with this. Start with checking if 'Collect Garbage' button at the bottom of this panel really does its job, if not - you probably have a memory leak (at least, according to v8). If so, try leak-finder-for-javascript.
然而，这个解决方案非常极端，只有当你真的很绝望时才尝试。到那时，我建议分析您的应用程序并检查为什么 v8 决定不清理垃圾（或无法清理垃圾）。DevTools 的 Timeline 面板将帮助您解决这个问题。首先检查此面板底部的“收集垃圾”按钮是否真的起作用，如果没有 - 您可能有内存泄漏（至少，根据 v8）。如果是这样，请尝试leak-finder-for-javascript。
[EDIT] I removed info about chrome extension, as it turns out that gc()can be called from webpage code when --js-flags="--expose-gc"is used. At least on my 23.0.1271.64.
[编辑] 我删除了有关 chrome 扩展的信息，因为它gc()可以在--js-flags="--expose-gc"使用时从网页代码中调用。至少在我的 23.0.1271.64 上。
回答by Nisim Joseph
In Chrome Developer Tools you have "Timeline" section, from around Chrome 53. you have there button looks like Garbage Can. clicking on it and it forcing the garbage collector to run.
在 Chrome 开发人员工具中，您有“时间轴”部分，从 Chrome 53 左右开始。您有按钮看起来像垃圾桶。单击它并强制垃圾收集器运行。
Update:
更新：
The GC button moved to Performance Tab in more recent versions of Chrome.
在较新版本的 Chrome 中，GC 按钮移至性能选项卡。
回答by Partap Davis
I found a solution. Apparently Chrome leaks DOM nodes, at least in the current version (26.0.1410.65 right now)
我找到了解决方案。显然 Chrome 泄漏了 DOM 节点，至少在当前版本中（现在是 26.0.1410.65）
I recorded dev tools timeline in my app and it showed the Event Listeners count going up and down rhythmically along with my app screen's contents, but the DOM Node count was steadily increasing over time, until the tab crashed.
我在我的应用程序中记录了开发工具时间线，它显示事件侦听器计数随着我的应用程序屏幕的内容有节奏地上升和下降，但 DOM 节点数随着时间的推移稳步增加，直到选项卡崩溃。
I tried the latest Chrome Canary (28.0.1500.3) and they seem to have fixed the problem. DOM Node count graph now follows the same rhythmic pattern as the Event Listeners.
我尝试了最新的 Chrome Canary (28.0.1500.3)，他们似乎已经解决了这个问题。DOM 节点计数图现在遵循与事件侦听器相同的节奏模式。
The thing that gets me is...why doesn't gmail ever crash? I usually keep a tab open for weeks at a time...
让我感到困惑的是……为什么 gmail 永远不会崩溃？我通常一次打开一个标签数周...
