我们正在使用ZK开发一个单页 Web 应用程序，该应用程序不断与服务器通信并更新其部分屏幕。更新频率可达 1 秒。在这些更新期间，对大量JS对象的引用会丢失，这些对象最终必须由垃圾收集器清理。
据我们所知，Chrome 只在非活动标签上运行其垃圾收集器。这对我们来说是个问题，因为应用程序的选项卡通常是活动的并且几乎从不刷新，因此JS对象永远不会被收集。如果保持活动状态足够长的时间，该选项卡最终会崩溃（Aww Snap消息）。
我们需要手动启动垃圾收集。到目前为止，我们已经尝试使用--js-flags="--expose-gc"和 running运行 Chrome gc()，但它会引发异常：
ReferenceError: gc is not defined
这不会在 Firefox 上发生——内存使用或多或少是一个常数。
强制刷新页面不是一种选择。
我们将不胜感激任何和所有的建议。
编辑：我们已经尝试在 Chrome版本window.gc()和gc()23.0.1271.97 m25.0.1364.2 dev-m
您可以获取 Chrome 开发工具的代码，对其进行修改以便ProfilerAgent.collectGarbage();不时调用它（这是在您单击时间轴面板上的“收集垃圾”按钮时调用的代码）并使用您的开发工具版本使用--debug-devtools-frontend标志运行 Chrome。
然而，这个解决方案是相当极端的，只有当你真的绝望时才尝试。到那时，我建议分析您的应用程序并检查为什么 v8 决定不清理垃圾（或无法清理垃圾）。DevTools 的时间线面板将帮助您解决这个问题。首先检查此面板底部的“收集垃圾”按钮是否真的有效，如果没有 - 你可能有内存泄漏（至少，根据 v8）。如果是这样，请尝试leak-finder-for-javascript。
[编辑] 我删除了有关 chrome 扩展的信息，因为在使用gc()时可以从网页代码中调用--js-flags="--expose-gc"。至少在我的 23.0.1271.64 上。
在 Chrome 开发者工具中，你有“时间轴”部分，从 Chrome 53 开始。你有按钮看起来像垃圾桶。单击它并强制垃圾收集器运行。
更新：
在较新版本的 Chrome 中，GC 按钮移至性能选项卡。
我找到了解决方案。显然 Chrome 会泄漏 DOM 节点，至少在当前版本中（现在是 26.0.1410.65）
我在我的应用程序中记录了开发工具时间线，它显示事件侦听器计数随着我的应用程序屏幕内容有节奏地上下波动，但 DOM 节点计数随着时间的推移稳步增加，直到选项卡崩溃。
我尝试了最新的 Chrome Canary (28.0.1500.3)，他们似乎已经解决了这个问题。DOM 节点计数图现在遵循与事件侦听器相同的节奏模式。
让我感动的是……为什么 gmail 从来没有崩溃过？我通常一次打开一个标签好几个星期...