我正在分析我编写的 javascript 库，寻找内存泄漏。该库为后端提供 API 和服务。它不做任何 html 或 dom 操作。它不加载任何资源（图像等）。它唯一做的就是发出 xhr 请求（使用 jquery），包括一个长轮询，它通过事件（使用 Backbone 事件总线）向 UI 传递和接收数据。
我已经测试了这个库在一夜之间运行了 16 个小时。加载它的页面只加载库并发送登录请求以启动服务。在测试过程中没有 html、css 或其他 dom 更改。
在测试过程中发生的所有事情是库每 15 秒向服务器发送一次心跳（xhr 请求），并每 30 秒通过长轮询接收一次心跳。
我在打开 chrome 任务管理器和打开 chrome 调试器的情况下运行了测试，以便从时间线强制 GC。
在测试开始时，在我强制执行初始 GC 之后 - 这些是来自 chrome 任务管理器的统计信息：内存 - 11.7mb
Javascript 内存 - 6.9 mb / 2.6mb 实时
共享内存 - 21.4 mb
私人内存 19mb
16 小时后，我强制执行 GC - 这些是新的统计数据：内存 - 53.8mb
Javascript 内存 - 6.9 mb / 2.8mb 实时
共享内存 - 21.7 mb
私有内存 60.9mb
如您所见，JS 堆仅增长了 200k。
私有内存增长了 42mb！
任何人都可以提供导致私人内存增长的原因的可能解释吗？打开 chrome 调试器会导致或影响内存增长吗？
我的另一个想法是，从时间线调试器中强制 GC 只会从 JS 堆中回收内存——因此其他内存不会被回收。因此，这本身可能不是“泄漏”，因为它最终可能会被收集——尽管我不确定如何确认这一点。尤其是在不知道这段记忆代表什么的情况下。
最后，我确实读到 xhr 结果也存储在私有内存中。有没有人知道这是不是真的？如果是这样，该应用程序在此时间范围内确实执行了大约 5700 个 xhr 请求。如果 42mb 的大部分是由于这个原因，那意味着大约分配了 7k - 这似乎很高，考虑到有效载荷非常小。如果是这种情况；何时释放此内存，我能做些什么来释放它，并且打开 chrome 调试器会对此产生影响吗？